DLL naming conventions

DLL naming conventions

[Paul Sokolovsky]

Hello cygwin,

  Existance of several GNU targets based on incompatible underlying
libraries brings (or will bring soon) problem of clashes between their
components. Mere installing software build with each of them into
separate directory and setting PATH to one of the in per-session
manner is not flexible since often one piece of software absent in
that or another distribution. Of particular importance here is
clashing of DLLs which is espicially hard to detect for end users. It
would be nice if there were some convention for naming DLLs build for
particular target. Cygwin did that for a some time, for example,
native builds of Tcl/Tk, etc. used to have 'cyg' prefix. However,
latest additions seem not to follow this practise.

  Will it be possible to re-consider this matter and if it applies,
recommend to follow it? More importantly, it can be automatically
supported on appropriate level (in libtool).

--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Chris Faylor]

On Wed, Aug 30, 2000 at 01:24:11PM +0300, Paul Sokolovsky wrote:
>Existance of several GNU targets based on incompatible underlying
>libraries brings (or will bring soon) problem of clashes between their
>components.  Mere installing software build with each of them into
>separate directory and setting PATH to one of the in per-session manner
>is not flexible since often one piece of software absent in that or
>another distribution.  Of particular importance here is clashing of
>DLLs which is espicially hard to detect for end users.  It would be
>nice if there were some convention for naming DLLs build for particular
>target.  Cygwin did that for a some time, for example, native builds of
>Tcl/Tk, etc.  used to have 'cyg' prefix.  However, latest additions
>seem not to follow this practise.
>
>Will it be possible to re-consider this matter and if it applies,
>recommend to follow it?  More importantly, it can be automatically
>supported on appropriate level (in libtool).

Nope.  Sorry.

If "end users" are using "incompatible" libraries then they'll really
have to deal with this themselves.  It's too late to change now.

Of course, on reflection, the cygwin project doesn't really have to
change at all.  All of these other "GNU targets" which came along after
cygwin was well established, and benefitted from years of cygwin
development, should probably be making naming concessions if it is a
problem.  Expecting cygwin to change its conventions is just a tad
bit arrogant, don't you think?

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: DLL naming conventions

[Paul Sokolovsky]

Hello Chris,

Chris Faylor <cgf@cygnus.com> wrote:

>>Will it be possible to re-consider this matter and if it applies,
>>recommend to follow it?  More importantly, it can be automatically
>>supported on appropriate level (in libtool).

CF> Nope.  Sorry.

CF> If "end users" are using "incompatible" libraries then they'll really
CF> have to deal with this themselves.  It's too late to change now.

CF> Of course, on reflection, the cygwin project doesn't really have to
CF> change at all.

    Yes! Who here proposes to change something? Blame him, beat him,
cut him! But we, as cicvilized people, let's talk about conventions,
*not* about changing anything, ok?

CF> All of these other "GNU targets" which came along after
CF> cygwin was well established, and benefitted from years of cygwin
CF> development, should probably be making naming concessions if it is a
CF> problem.

    Exactly! I knew you'll recommend that, so I'm going to submit
patch to libtool which will use different naming convention for
GNU/Win32 target I maintain. But not everyone so reflective as me, and
there're at least two other targets cygwin and mingw32. Ok, we'll
leave rock-solid cygwin aside. But what about poor mingw32? Chris, I
understand your position: that's not cygwin problem. But what if you,
maintainer of Cygwin, mother of all GNU-Win32 targets, considered that
it is problem of - not Cygwin - whole GNU-Win32? Then, you might
consider doing something. If you'd consider it, you might come with
following thought: "Hey, but we already using 'cyg' prefix for some libs.
At the same time, GNU has convention of prefixing libraries with
'lib'. Let's recommend for cygwin use prefix 'cyg' instead (for *dlls
only*) - it is consistent with existing practise. As for mingw32,
we'll leave it 'lib' - after all, it's the most native GNU-Win32
target, let it use defualt conventions. All other, being
superstructures on win32, to use distinguishable naming scheme".


================= Specific proposal ================
I'm going to submit patch to libtool which (supposing it will be
accepted) will make it use other naming scheme for PW32,
posix-on-win32 layer I maintain. If it is in favor of Cygwin,
community, I may do the same for cygwin too.

Proposed naming conventions [only pertinent one shown]

 For some library 'foo', libtool will procude on

Cygwin:
libfoo.la - standard libtool wrapper
libfoo.a  - import library, thing against which objects are linked
            ("developer" part)
cygfoo.<release>.dll - dll, this is what gets loaded in runtime
                       ("user" part)

Note that <release> is standard part of name of shared libraries
produced by libtool. While it sequency of three arbitrary numbers,
there's strictly recommended policy to using them - in two words, they
should reflect interface version, never version of library itself. And
yes, there's a way to disable putting it in name. Most packages don't do
that, however.

For mingw32, those will be:
libfoo.la
libfoo.a
libfoo.<release>.dll


Note - no efforts or changes will be required from programmer's or
maintainer's side to support different names of run-time DLLs, their
different version or whatever - it will be completely hidden in implib
the wondeful thing.

====================================


CF> Expecting cygwin to change its conventions is just a tad
CF> bit arrogant, don't you think?

    Chris, you often ask strange questions. If, I say - if, someone
would propose to change its conventions, I'd first listen one's
reasoning before making my opinion whether it is arrogant or not. But
what relation this has to our present conversation?

CF> cgf



--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Chris Faylor]

On Thu, Aug 31, 2000 at 02:14:56PM +0300, Paul Sokolovsky wrote:
>From: Paul Sokolovsky <paul-ml@is.lg.ua>
>Chris Faylor <cgf@cygnus.com> wrote:
>CF> Of course, on reflection, the cygwin project doesn't really have to
>CF> change at all.
>
>Yes! Who here proposes to change something?  Blame him, beat him, cut
>him! But we, as cicvilized people, let's talk about conventions, *not*
>about changing anything, ok?

If we're going to talk about technical issues, how about leaving out
incomprehensible hyperbole?

>CF> All of these other "GNU targets" which came along after
>CF> cygwin was well established, and benefitted from years of cygwin
>CF> development, should probably be making naming concessions if it is a
>CF> problem.
>
>    Exactly! I knew you'll recommend that, so I'm going to submit
>patch to libtool which will use different naming convention for
>GNU/Win32 target I maintain. But not everyone so reflective as me, and
>there're at least two other targets cygwin and mingw32. Ok, we'll
>leave rock-solid cygwin aside. But what about poor mingw32? Chris, I
>understand your position: that's not cygwin problem. But what if you,
>maintainer of Cygwin, mother of all GNU-Win32 targets, considered that
>it is problem of - not Cygwin - whole GNU-Win32? Then, you might
>consider doing something. If you'd consider it, you might come with
>following thought: "Hey, but we already using 'cyg' prefix for some libs.

The reason that we use "cyg" on the tcl libs is that they contain local
cygwin mods, making those DLLs different from the ones already
distributed by Scriptics.

I think it is unlikely that a person will be attempting to use both the
cygwin and mingw libpng DLLs at the same time and have absolutely no
desire to engage in a massive DLL renaming campaign, especially given
the attendant confusion that will be a guaranteed result.

>At the same time, GNU has convention of prefixing libraries with
>'lib'.

This is a longstanding *UNIX* convention.  It's not a GNU convention.

>Let's recommend for cygwin use prefix 'cyg' instead (for *dlls
>only*) - it is consistent with existing practise. As for mingw32,
>we'll leave it 'lib' - after all, it's the most native GNU-Win32
>target, let it use defualt conventions. All other, being
>superstructures on win32, to use distinguishable naming scheme".

If every package maintainer wants to follow this (to me) ill-considered
plan, that's fine.  Just as long as I don't have to support it.

IMO, cygwin is supposed to be UNIX for Windows.  If people are looking
for libraries, they don't look for 'cygreadline.dll' they look for
'libreadline.dll'.

>CF> Expecting cygwin to change its conventions is just a tad
>CF> bit arrogant, don't you think?
>
>Chris, you often ask strange questions.  If, I say - if, someone would
>propose to change its conventions, I'd first listen one's reasoning
>before making my opinion whether it is arrogant or not.  But what
>relation this has to our present conversation?

I was under the impression that you'd already submitted your reasoning.
Apparently you're having some kind of problems with library versioning
with your own project so your solution is to change cygwin's usages.
I'm sure that it must have occurred to you that cygwin has been using
the same conventions for years and that suddenly changing things now
will lead to confusion.  I don't see any plan for dealing with the
confusion, however.

I assume that if your plan is implemented you'll just disappear from
this mailing list and leave others to deal with the fallout.

Perhaps this assumption is invalid, but I don't see you answering any
questions here on a day-to-day basis.

However, it's all moot.  The base cygwin release that I control is
not going to change any of its naming conventions.  If all of the
other contributors want to adopt a new plan, that's fine with me.
Isn't free software wonderful?

However, I will again state that I don't think that any change is
necessary.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: DLL naming conventions

[Paul Sokolovsky]

Hello Chris,

Chris Faylor <cgf@cygnus.com> wrote:

CF> I think it is unlikely that a person will be attempting to use both the
CF> cygwin and mingw libpng DLLs at the same time and have absolutely no
CF> desire to engage in a massive DLL renaming campaign, especially given
CF> the attendant confusion that will be a guaranteed result.

    Yes, you or me or other developer hardly will come to such
situation, simply because we know what installed where. But you know
those users - they always find their way to confusion.

>>At the same time, GNU has convention of prefixing libraries with
>>'lib'.

CF> This is a longstanding *UNIX* convention.  It's not a GNU convention.

    In this context, it matters that it is *GNU* convention. For
example, mingw32 hardly have something to do with Unix, still it's
Minimalist *GNU* target, so I do not consider dropping 'lib' prefix
for it (and thus, protect it from problems with compiler ABI differences
between msvc and gcc).

CF> I was under the impression that you'd already submitted your reasoning.
CF> Apparently you're having some kind of problems with library versioning
CF> with your own project so your solution is to change cygwin's usages.
CF> I'm sure that it must have occurred to you that cygwin has been using
CF> the same conventions for years and that suddenly changing things now
CF> will lead to confusion.  I don't see any plan for dealing with the
CF> confusion, however.

    Nope, my own project is under my control and I'll find way to make
*it* not to clutter with others. The same true for Cygwin - there's
authority to whom request can be made and either rejected or accepted
(or recommended or not). Unfortunately, there's noone to ask same
about Mingw32. Neither I myself could come to some decision concerning
it. For example, prefix for mingw32 could be changed, but to what?
Long names like 'mingw32' just too long. Short like "m32", "w32" are
missleading. Fairy understood like "gnu" is simply unright...

CF> I assume that if your plan is implemented you'll just disappear from
CF> this mailing list and leave others to deal with the fallout.

CF> Perhaps this assumption is invalid, but I don't see you answering any
CF> questions here on a day-to-day basis.

    Sorry, I do not plan any fallout. Neither there're any "my" plan.
Instead, I asked do you have one. As for answering questions, I
decided that I'd better do something now, I somewhat better at hacking
than at PR.

CF> However, it's all moot.  The base cygwin release that I control is
CF> not going to change any of its naming conventions.  If all of the
CF> other contributors want to adopt a new plan, that's fine with me.
CF> Isn't free software wonderful?

CF> However, I will again state that I don't think that any change is
CF> necessary.

    Ok. Thanks for discussion. I tried that and glad that it caught
some attention and it came that it's not all so bad (I'm about keeping
dll in the same dir as binaries, what is already done - sounds good for
me). Also, I'm glad that discussion catch attention of Gary Vaughan -
after all, he'd assessed my patch if I did it. So, if someone thinks that
*libtool* on cygwin should produce *dlls* with 'cyg' prefix, consider
dropping note to libtool@gnu.org , maybe it will be discussed there.

CF> cgf



--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Re[2]: DLL naming conventions

[Gary V. Vaughan]

On Thu, Aug 31, 2000 at 02:14:56PM +0300, Paul Sokolovsky wrote:
> [[snip]]
> I'm going to submit patch to libtool which (supposing it will be
> accepted) will make it use other naming scheme for PW32,
> posix-on-win32 layer I maintain. If it is in favor of Cygwin,
> community, I may do the same for cygwin too.
> 
> Proposed naming conventions [only pertinent one shown]
> 
>  For some library 'foo', libtool will procude on
> 
> Cygwin:
> libfoo.la - standard libtool wrapper
> libfoo.a  - import library, thing against which objects are linked
>             ("developer" part)
> cygfoo.<release>.dll - dll, this is what gets loaded in runtime
>                        ("user" part)
> 
> Note that <release> is standard part of name of shared libraries
> produced by libtool. While it sequency of three arbitrary numbers,
> there's strictly recommended policy to using them - in two words, they
> should reflect interface version, never version of library itself. And
> yes, there's a way to disable putting it in name. Most packages don't do
> that, however.
> [[snip]

That's not how libtool works on cygwin -- remember that libtool only
want's you to see (and thus link against) the libfoo.la file.  Behind
the scenes it maintains a static library, libfoo.a, and a dynamic
library, libfoo-<release>.dll.  When you link against libfoo.la and
libtool decides you want dynamic linkage, it will generate an import
library from libfoo-<release>.dll *on the fly*.

I have no objections to using cyg instead of lib as the default prefix
for libtool built dlls on cygwin, but installing an import library
would be a step backwards IMHO.  If you do want to install it (for
people who don't like libtool perhaps), I would suggest naming it
cygfoo.dll.a.

Cheers,
	Gary.
-- 
  ___              _   ___   __              _         mailto: gvv@techie.com
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       gary@gnu.org 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Charles Wilson]

Paul Sokolovsky wrote:
> 
> Hello cygwin,
> 
>   Existance of several GNU targets based on incompatible underlying
> libraries brings (or will bring soon) problem of clashes between their
> components. Mere installing software build with each of them into
> separate directory and setting PATH to one of the in per-session
> manner is not flexible since often one piece of software absent in
> that or another distribution. Of particular importance here is
> clashing of DLLs which is espicially hard to detect for end users. It
> would be nice if there were some convention for naming DLLs build for
> particular target. Cygwin did that for a some time, for example,
> native builds of Tcl/Tk, etc. used to have 'cyg' prefix. However,
> latest additions seem not to follow this practise.

Yup, I know.  Most the latest additions which have dll's were ones that
I ported.  I did not want dependent packages to be required to modify
their makefiles to use '-lcygtiff' or worse yet, '-lcygtiff35' when a
plain '-ltiff' is already there and works.  The tcl/tk stuff is a
special case, I believe, since it's a wierd half-native/half-cygwin
build...

So far, the only problems I have seen are zlib (cygwin version clashing
with Suhaib's cygwin-XFree version), and it is conceivable that windows
versions of zlib/libpng can clash with the cygwin versions of same.
However, the cygwin-zlib works with XFree, so you can just delete the
cygwin-xfree zlib.dll.  I haven't seen too many reports of actual
problems with windows dlls clashing with cygwin dlls; several folks have
mentioned that 'it could happen, we should fix it before it does' but
nobody has *actually* had it happen to them. 

I've no interest in fixing a problem (and causing many many more
problems) when the initial problem has not been demonstrated to affect
real users.

> 
>   Will it be possible to re-consider this matter and if it applies,
> recommend to follow it? 

Maybe.  But I won't even accept patches to do that to the packages I
maintain until the dependency problems are resolved, or folks on the
list agree that the inevitable hassles and constant FAQs: 'you need to
change -ltiff to -lcygtiff in the makefile...' are worth it.

One less intrusive possibility I have thought of is: 
  import lib:  libtiff{ver?}.dll.a (built with
--dllname=cyglibtiff{ver?}.dll)
  dll       :  cyglibtiff{ver?}.dll

If this is done, then you no longer can link directly to the dll
(without changing the makefile to say '-lcyglibtiff{ver}',  but
ordinarily you'd link using the import lib so everything would be ok,
and you can still use '-ltiff' in the makefile.

I'm not really in favor of using version numbers on shared libs,  since
you'd also have to version the import libs also and then use symlinks a
la unix....but this should be discussed on the list.
   libtiff.dll.a -> libtiff{latest-ver}.dll.a

> More importantly, it can be automatically
> supported on appropriate level (in libtool).

No, it can't.  Currently, libtool itself doesn't support *building*
dlls.  Also, you are assuming that every package that depends on
dll-ized libraries uses libtool in its build process.  While that would
be great, it is not true.  Unfortunately, *very* few packages use
libtool, in my experience.

Comments, anyone?

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Chris Faylor]

On Wed, Aug 30, 2000 at 10:51:36AM -0400, Charles Wilson wrote:
>Comments, anyone?

"I am trying to find the libz.dll file but it doesn't exist anywhere
on my system!  I've tried to download this three times!  I've wiped
out my whole cygwin installation, reformatted my hard drive and flushed
the toilet repeatedly!  What gives????"

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: DLL naming conventions

[Norman Vine]

>"I am trying to find the libz.dll file 

ftp://sourceware.cygnus.com/pub/cygwin/contrib/zlib/



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Charles Wilson]

Norman, you missed the point...

  If we change the name of libz.dll to 'cyglibz.dll' or somesuch, then
it would *not* be in pub/cygwin/contrib/zlib/.  Chris is pointing out
that this would confuse people (*), and the answer is 
  'The name was changed. The file is cyglibz.dll (or whatever)'
not
  go download the package again from ftp://.....

--Chuck

(*) the people that never read documentation...

Norman Vine wrote:
> 
> >"I am trying to find the libz.dll file
> 
> ftp://sourceware.cygnus.com/pub/cygwin/contrib/zlib/
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Charles Wilson]

Charles Wilson wrote:
> 
> Norman, you missed the point...
> 
>   If we change the name of libz.dll to 'cyglibz.dll' or somesuch, then
> it would *not* be in pub/cygwin/contrib/zlib/.  Chris is pointing out
  ^^
libz.dll

> that this would confuse people (*), and the answer is
>   'The name was changed. The file is cyglibz.dll (or whatever)'
> not
>   go download the package again from ftp://.....
> 
> --Chuck
> 
> (*) the people that never read documentation...
> 
> Norman Vine wrote:
> >
> > >"I am trying to find the libz.dll file
> >
> > ftp://sourceware.cygnus.com/pub/cygwin/contrib/zlib/
> >
> > --
> > Want to unsubscribe from this list?
> > Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Chris Faylor]

On Wed, Aug 30, 2000 at 11:20:29AM -0400, Charles Wilson wrote:
>Norman, you missed the point...
>
>  If we change the name of libz.dll to 'cyglibz.dll' or somesuch, then
>it would *not* be in pub/cygwin/contrib/zlib/.  Chris is pointing out
>that this would confuse people (*), and the answer is 
>  'The name was changed. The file is cyglibz.dll (or whatever)'
>not
>  go download the package again from ftp://.....

Let's put it another way, then:  How many complaints have we seen about
incompatible DLLs?

The original query was in regard to the fact that vast number of "GNU on
Windows" systems could step on each others' toes.  If Cygwin was here
first, I'm not sure why it should have to change to accomodate other
packages.  In fact, if all of the myriad systems out there just agree on
their own naming convention, that should leave cygwin with no problems.

Here's the convention that makes sense to me "Cygwin's DLLs are named
similarly to their counterparts on UNIX so that a library named libz.so
on UNIX is named libz.dll under Cygwin.  Under the bushwah GNU porting
layer, similar libraries are named bushwalibz.dll."

Works for me.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: DLL naming conventions

[Paul Sokolovsky]

Hello Chris,

Chris Faylor <cgf@cygnus.com> wrote:

CF> Here's the convention that makes sense to me "Cygwin's DLLs are named
CF> similarly to their counterparts on UNIX so that a library named libz.so
CF> on UNIX is named libz.dll under Cygwin.  Under the bushwah GNU porting
CF> layer, similar libraries are named bushwalibz.dll."

    You missed it! You missed it! "Bushwah GNU porting layer" uses
'libfoo.so' as the name for its DLLs! Well, but now I think: wasn't it
too arrogant? ;-)

CF> Works for me.

    Great!

CF> cgf

--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Charles Wilson]

Chris Faylor wrote:
> 
> On Wed, Aug 30, 2000 at 10:51:36AM -0400, Charles Wilson wrote:
> >Comments, anyone?
> 
> "I am trying to find the libz.dll file but it doesn't exist anywhere
> on my system!  I've tried to download this three times!  I've wiped
> out my whole cygwin installation, reformatted my hard drive and flushed
> the toilet repeatedly!  What gives????"
> 
  Answer: 'read the f@#$*("& zlib-1.1.3.README file in /usr/doc/Cygwin'

I'm not arguing for changing dll names (it would be a *HELL* of a lot of
work for me, and I really don't want to do it) but we just can't be
timid about changes because folks don't read documentation.  Perhaps we
should resurrect the actual meaning of 'RTFM' and stop using the nice,
clean, acronym....

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: DLL naming conventions

[Paul Sokolovsky]

Hello Charles,

Charles Wilson <cwilson@ece.gatech.edu> wrote:

CW> Paul Sokolovsky wrote:
>>
>> Hello cygwin,
>>
>>   Existance of several GNU targets based on incompatible underlying
>> libraries brings (or will bring soon) problem of clashes between their
>> components. Mere installing software build with each of them into
>> separate directory and setting PATH to one of the in per-session
>> manner is not flexible since often one piece of software absent in
>> that or another distribution. Of particular importance here is
>> clashing of DLLs which is espicially hard to detect for end users. It
>> would be nice if there were some convention for naming DLLs build for
>> particular target. Cygwin did that for a some time, for example,
>> native builds of Tcl/Tk, etc. used to have 'cyg' prefix. However,
>> latest additions seem not to follow this practise.

CW> Yup, I know.  Most the latest additions which have dll's were ones that
CW> I ported.

    Exactly contemplating your releases, as well as my own activity of
doing same for mingw32, made me to raise this question.

CW>   I did not want dependent packages to be required to modify
CW> their makefiles to use '-lcygtiff' or worse yet, '-lcygtiff35' when a
CW> plain '-ltiff' is already there and works.

    Neither I even consider possibility to changes like that. If
something uses -ltiff on any other system, it will use -ltiff on
cygwin, mingw32, whatever. Period. I'm surprised that you considered
such possibility to the end of your mail, not from the very
beginning.

CW>   I haven't seen too many reports of actual
CW> problems with windows dlls clashing with cygwin dlls; several folks have
CW> mentioned that 'it could happen, we should fix it before it does' but
CW> nobody has *actually* had it happen to them.

    I'm yet another such person with cassandristic attitudes. However,
I can point the problem spot more precisely: just as you provide
zlib/libjpeg/libpng/libtiff for cygwin, I'm doing that for mingw32
( http://mingwrep.sourceforge.net )

CW> I've no interest in fixing a problem (and causing many many more
CW> problems) when the initial problem has not been demonstrated to affect
CW> real users.

    Depending on different objective and subjective reasons, Tor
Lillqvist might use my builds in his GIMP-win32 distribution. I tried
to use versioned names for my libpng.2.1.dll (2.1 is *interface* name,
from README) and libjpeg.6.dll (I can point you where libjpeg.dll
already used: in Netscape Nav.). However, for libz.dll and libtiff.dll
it is not. Zlib has rock-solid API and I don't want to clutter dll
with any numbers. For libtiff, there's that stupid LZW problem. I
would like to have LZW-less dll to drop-in-replacable by LZW-contating
one, so they'd better not to have versioning numbers.

    Ok, now suppose you installed some cygwin-hosted tool on computer
of secretary in your firm. Also, she's cool enough to prefer GIMP to
PhotoShop and she installed it. Suppose both dlls get on PATH (for
example, cygwin's was put by you, and GIMP's stupid shrink-wrapped
installer drop its to windows/system). Poor user.

CW> One less intrusive possibility I have thought of is:
CW>   import lib:  libtiff{ver?}.dll.a (built with
CW> --dllname=cyglibtiff{ver?}.dll)
CW>   dll       :  cyglibtiff{ver?}.dll

CW> If this is done, then you no longer can link directly to the dll
CW> (without changing the makefile to say '-lcyglibtiff{ver}',  but
CW> ordinarily you'd link using the import lib so everything would be ok,
CW> and you can still use '-ltiff' in the makefile.

    Note, that my very question is about whether Cygwin people want
that to be automatically supported by libtool. I appreciate you
attention and comprehensive discussion, but I'll understand if you'll
simply say "I won't do that". But returning back to libtool, you wan't
be able to link directly to libtool-generated dll that way since it's by
default includes versioning info. And as you understand, FAQ entry
with "you've got to use --no-versioning switch to libtool when
building DLLs with cygwin" won't help. So, staying with implibs for
linking is only feasible alternative.

CW> I'm not really in favor of using version numbers on shared libs,  since
CW> you'd also have to version the import libs also

    As you know, you wouldn't and shouldn't.

>> More importantly, it can be automatically
>> supported on appropriate level (in libtool).

CW> No, it can't.

   ???

CW>  Currently, libtool itself doesn't support *building* dlls.

     Well, to be precise it *does*. In rather ungroundly complicated
way. But - it's currently. My port of libtool for pw32 does it
far more seamlessly. And, before going for inclusion these changes
into official distribution, I'd like it to work for all GNU/Win32
targets, not only mine.

CW>   Also, you are assuming that every package that depends on
CW> dll-ized libraries uses libtool in its build process.  While that would
CW> be great, it is not true.  Unfortunately, *very* few packages use
CW> libtool, in my experience.

    Once again, I have no ambition to force maintainers of not
configure-enabled libs to change namings of their dlls - that's up to
their own consideration, reasons was presented and discussed.

CW> Comments, anyone?

CW> --Chuck


--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Charles S. Wilson]

Paul Sokolovsky wrote:
> CW> I've no interest in fixing a problem (and causing many many more
> CW> problems) when the initial problem has not been demonstrated to affect
> CW> real users.
> 
>     Depending on different objective and subjective reasons, Tor
> Lillqvist might use my builds in his GIMP-win32 distribution. I tried
> to use versioned names for my libpng.2.1.dll (2.1 is *interface* name,
> from README) and libjpeg.6.dll (I can point you where libjpeg.dll
> already used: in Netscape Nav.). However, for libz.dll and libtiff.dll
> it is not. Zlib has rock-solid API and I don't want to clutter dll
> with any numbers. For libtiff, there's that stupid LZW problem. I
> would like to have LZW-less dll to drop-in-replacable by LZW-contating
> one, so they'd better not to have versioning numbers.

Well, Netscape Communicator actually uses 'jpeg3240.dll', but your point
about the GIMP is well taken.

> 
>     Ok, now suppose you installed some cygwin-hosted tool on computer
> of secretary in your firm. Also, she's cool enough to prefer GIMP to
> PhotoShop and she installed it. Suppose both dlls get on PATH (for
> example, cygwin's was put by you, and GIMP's stupid shrink-wrapped
> installer drop its to windows/system). Poor user.

Okay, a demonstrated problem.

>     Note, that my very question is about whether Cygwin people want
> that to be automatically supported by libtool. I appreciate you
> attention and comprehensive discussion, but I'll understand if you'll
> simply say "I won't do that". But returning back to libtool, you wan't
> be able to link directly to libtool-generated dll that way since it's by
> default includes versioning info. And as you understand, FAQ entry
> with "you've got to use --no-versioning switch to libtool when
> building DLLs with cygwin" won't help. So, staying with implibs for
> linking is only feasible alternative.
> 
> CW> I'm not really in favor of using version numbers on shared libs,  since
> CW> you'd also have to version the import libs also
> 
>     As you know, you wouldn't and shouldn't.

Hmmm....actually, you would if you truly wanted to support different
versions of a library that are incompatible at the source level (major
version number changes).  'Course, you'd also need to keep around
multiple versions of the header files....just too much work for me to
contemplate.

Nope. No version numbers on import libs. Not ever.

> 
> >> More importantly, it can be automatically
> >> supported on appropriate level (in libtool).
> 
> CW> No, it can't.
> 
>    ???
> 
> CW>  Currently, libtool itself doesn't support *building* dlls.
> 
>      Well, to be precise it *does*. In rather ungroundly complicated
> way. But - it's currently. My port of libtool for pw32 does it
> far more seamlessly. And, before going for inclusion these changes
> into official distribution, I'd like it to work for all GNU/Win32
> targets, not only mine.

Well, the problem with libtool is that it's a developer's tool.  Take
the gettext package, for instance.  It uses some version of libtool that
does not understand cygwin/dlls.  The only way to 'fix' it is to replace
the libtool that is distributed WITH gettext, with a newer version.

See, libtool isn't a tool that lives on the end-user's system. It's a
couple of scripts that are distributed with each package that uses
libtool.  So, you've probably got 27 versions of libtool on your system
right now.

Perhaps the current version of libtool groks cygwin dlls. (In the 'old'
dlltool way; I'm positive it doesn't use 'gcc -shared').  But none of
the commonly-used libraries or applications out there USE the most
current libtool.

Should libtool support dlls on cygwin?  Yes, absolutely.  

Should it version the dll's with the major and minor version numbers,
but not the micro or pico version numbers?  Sure, as long as you can use
--no-versioning.  

Should it create dlls with a 'cyg' prefix when running on CYGWIN instead
of a 'lib' prefix?  Ummm...maybe, IMO.

See my other response in this thread, to Earnie Boyd (posted at 11:30am
EDT)

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: DLL naming conventions

[Tor Lillqvist]

Paul Sokolovsky writes:
 > GIMP's stupid shrink-wrapped installer drop its to
 > windows/system).

No it doesn't. (It did at some point, a long time ago.) Currently it
puts the DLLs in \Program Files\Common Files\GNU.

Currently the GIMP for Windows does not use DLLs for the JPEG, Zlib or
TIFF libraries, precisely because of the lack of consensus in naming
etc. And if there is anything to learn from this discussion, it is
that it is best to stick to static libraries in the future, too...

One point that has not been brought up here is that it is not enough
that some library's API is stable, like for instance zlib. The ABI
must also be identical in order to be able to share the same DLL
between applications from different sources. With this I am thinking
of struct packing issues, i.e. whether gcc compilations use
-fnative-struct (MSVC-compatible bitfield packing) or not.

Sorry that this is mostly off-topic to the cygwin list.

--tml


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Chris Faylor]

On Thu, Aug 31, 2000 at 09:25:34PM +0300, Tor Lillqvist wrote:
>Paul Sokolovsky writes:
> > GIMP's stupid shrink-wrapped installer drop its to
> > windows/system).
>
>No it doesn't. (It did at some point, a long time ago.) Currently it
>puts the DLLs in \Program Files\Common Files\GNU.
>
>Currently the GIMP for Windows does not use DLLs for the JPEG, Zlib or
>TIFF libraries, precisely because of the lack of consensus in naming
>etc. And if there is anything to learn from this discussion, it is
>that it is best to stick to static libraries in the future, too...
>
>One point that has not been brought up here is that it is not enough
>that some library's API is stable, like for instance zlib. The ABI
>must also be identical in order to be able to share the same DLL
>between applications from different sources. With this I am thinking
>of struct packing issues, i.e. whether gcc compilations use
>-fnative-struct (MSVC-compatible bitfield packing) or not.
>
>Sorry that this is mostly off-topic to the cygwin list.

I actually think that this is quite on topic for this discussion.

I guess the one thing that reading this mailing list for three
years has showed me is that any change is expensive.  I never would
have thought that something like having the installer default to
putting cygwin stuff in its own directory would have caused
people's heads to explode but I was obviously naive.

This reaction to change has made me very reluctant to consider
user visible changes to cygwin since I can easily imagine the
onslaught of "newbies" looking for libz.dll.

Maybe you're right and we are starting to rely too much on DLLs for
things that are clearly established and relatively static (no pun
intended) like zlib.  The benefit to shared libraries is that
you're sharing a common code base among many applications, making
upgrading due to bugs easier.  Also, if multiple programs are
using shared libraries then there should be a reduction in load
times.

I'm not sure that these benefits outweigh the difficulties that
are being raised.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Larry Hall (RFK Partners, Inc)]

At 02:46 PM 8/31/2000, you wrote:
>On Thu, Aug 31, 2000 at 09:25:34PM +0300, Tor Lillqvist wrote:
> >Paul Sokolovsky writes:
> > > GIMP's stupid shrink-wrapped installer drop its to
> > > windows/system).
> >
> >No it doesn't. (It did at some point, a long time ago.) Currently it
> >puts the DLLs in \Program Files\Common Files\GNU.
> >
> >Currently the GIMP for Windows does not use DLLs for the JPEG, Zlib or
> >TIFF libraries, precisely because of the lack of consensus in naming
> >etc. And if there is anything to learn from this discussion, it is
> >that it is best to stick to static libraries in the future, too...
> >
> >One point that has not been brought up here is that it is not enough
> >that some library's API is stable, like for instance zlib. The ABI
> >must also be identical in order to be able to share the same DLL
> >between applications from different sources. With this I am thinking
> >of struct packing issues, i.e. whether gcc compilations use
> >-fnative-struct (MSVC-compatible bitfield packing) or not.
> >
> >Sorry that this is mostly off-topic to the cygwin list.
>
>I actually think that this is quite on topic for this discussion.
>
>I guess the one thing that reading this mailing list for three
>years has showed me is that any change is expensive.  I never would
>have thought that something like having the installer default to
>putting cygwin stuff in its own directory would have caused
>people's heads to explode but I was obviously naive.
>
>This reaction to change has made me very reluctant to consider
>user visible changes to cygwin since I can easily imagine the
>onslaught of "newbies" looking for libz.dll.
>
>Maybe you're right and we are starting to rely too much on DLLs for
>things that are clearly established and relatively static (no pun
>intended) like zlib.  The benefit to shared libraries is that
>you're sharing a common code base among many applications, making
>upgrading due to bugs easier.  Also, if multiple programs are
>using shared libraries then there should be a reduction in load
>times.
>
>I'm not sure that these benefits outweigh the difficulties that
>are being raised.
>
>cgf



Quite true.  Microsoft (a bad word I know!;-)) calls this all "DLL Hell"
and has plans to address it with their ".NET" initiative (interesting that
at their web site you find information about this under "Products"!;-))
Anyway, they plan to address the issue by grouping all dependencies (DLLs
in this case) together so that an application runs the DLLs it was shipped
with and not any others that exist on the system.  This gets us back very
close to the idea of static libs, which I find an interesting turn of 
events.  In any case, I'm not advocating that people need to follow what
Microsoft does but it does point out that this is an issue, others have 
thought about it, and at least one group has decided to mostly punt on the
idea of DLLs!

Those interested can look at:

http://msdn.microsoft.com/msdnmag/nettop.asp?page=/msdnmag/issues/0900/Framework/Framework.asp&ad=ads.ddj.com/msdnmag/premium.htm

http://msdn.microsoft.com/msdnmag/nettop.asp?page=/msdnmag/issues/1000/Framework2/Framework2.asp&ad=ads.ddj.com/msdnmag/premium.htm

but let's not let this discussion degrade into an analysis of whether 
Microsoft is doing the right thing or not!;-)




Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Charles S. Wilson]

"Gary V. Vaughan" wrote:
> 
> On Wed, Aug 30, 2000 at 10:51:36AM -0400, Charles Wilson wrote:
> > No, it can't.  Currently, libtool itself doesn't support *building*
> > dlls.
> 
> Ouch.  Yes it does.  I added support around Christmas 1998, and have
> been maintaining it ever since.

Thanks for the correction.

> 
> Yes it does.  And provided your libraries don't trip over the stupid
> dll limitation of "to export a non-function symbol you must edit your
> sources", it works easily.  Even if you do export data symbols,
> libtool woll build and link against a dll for you (even generating an
> import lib along the way).
> 
> Unfortunately libtool was developed for Unix and assumes a featureful
> shared library architecture, which doesn't map very easily onto win32
> dll's.
> 
> I will be able to simplify the dll build process a little when DJ's
> patches to binutils arrive in a cygwin release (did this happen in
> 1.1? I have been so busy with m4 that I only upgraded from b20.1 a few
> weeks ago).

They landed in binutils-20000625, and were finetuned/tweaked to a fairly
stable point by binutils-20000722 (the current version in /latest).

Also, there were a few additions that changed ld's default search order
for libraries:
  -Bstatic -lfoo  : 
    looks for libfoo.a
  -Bdynamic -lfoo : 
    looks for libfoo.dll.a (default name for an import lib)
         then foo.dll.a    (alt. name for an import lib)
         then libfoo.dll   (link directly to a dll)
         then foo.dll      (ditto, alt. name)
     finally, libfoo.a     (fall back to static lib)

The spec file for gcc (as of 2.95.2-2) changed so that:
   gcc -static   calls 'ld -Bstatic'
   gcc           calls 'ld -Bdynamic'

Finally, 'gcc -shared' will build a dll, but you need to pass linker
options like '-Wl,--out-implib=libfoo.dll.a' explicitly. 

FWIW, all of the (non-libtool) libraries I've dll-ized do not use
dlltool at all, and rely only on gcc (and ld, indirectly).

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Gary V. Vaughan]

On Thu, Aug 31, 2000 at 09:58:24PM -0400, Charles S. Wilson wrote:
> FWIW, all of the (non-libtool) libraries I've dll-ized do not use
> dlltool at all, and rely only on gcc (and ld, indirectly).

It's worth its weight in gold!  Thanks.  I'll try and get rid of the
dlltool dependency before I release libtool-1.4.

Thanks for the info!
	Gary.
-- 
  ___              _   ___   __              _         mailto: gvv@techie.com
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       gary@gnu.org 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Charles S. Wilson]

I just want to announce that I don't know what I'm talking about when it
comes to the 'standards' for versioning shared libraries.  I just did
some research, and the following assumptions of mine were completely
wrong:

given package name "foo-X.Y.Z"

I stated that
 1) "X" was incremented due to source-level incompatibilities (API
changes)
 2) "Y" was incremented due to binary-level incompatibilities (ABI
changes)

wrong on both counts. Package name versions have NOTHING to do with
API/ABI changes -- unless the maintainers are 'nice'.  Sometimes they
are.  But assertion #2 is almost certainly wrong.  Anyway, maintainers
are perfectly free to bump X because their dog died.  They can bump Z to
indicate a complete rewrite from the ground up.  Whatever.

So, API/ABI interface compatibility can be orthogonal to package
versioning.  (*)

See the following two documents, but don't draw any conclusions until
you've read both

1) on shared libary naming conventions
  http://www.debian.org/Lists-Archives/lsb-spec-9905/msg00011.html

2) on interface (API/ABI) versioning
  http://www.gnu.org/software/libtool/manual.html#Versioning
  http://www.gnu.org/software/libtool/manual.html#Release%20numbers

(*) This explains Chris's suggestion earlier in this thread: 

> In your case, though, I don't see that there will be a problem until
> there actually is an API change.  When that happens you can add a
> '1' to whatever DLL changed.

e.g. maintain API/ABI version numbers orthogonal to package versions,
just like cygnus does for the cygwin dll.

This makes me happy. I like this answer to the versioning question. The
'cyg' prefix question is still up in the air -- but only for 'my'
/contrib libraries, not the official /latest libraries. (Chris has
already said he's sticking with libfoo.dll for the official cygnus
packages).  However, I'm leaning against 'cyg' too, given the solution
presented earlier in this thread:

> That means that the (so far hypothetical) DLL problems should be
> solvable by keeping the DLLs in the same directory as the executables.

Since all /contrib and /latest dll's & executables go into /usr/bin (==
/bin), the only problems -- within the cygwin sandbox -- imposed by this
solution are other cygwin packages that are installed into /usr/local/
but depend on dll's in /usr/bin.  Those problems can be fixed by
  1) cp /usr/bin/*.dll /usr/local/bin  !! YUCK !!
  2) insure that the path gets /usr/bin before /windows/system or
whatever
This works -- in the sandbox (e.g. Michael Ring's User1: see
http://sources.redhat.com/ml/cygwin/2000-08/msg01241.html )

> User1 is happy with cygwin as as 'linux light' on his pc. He uses
> cygwin only in it's own environment (means he first starts bash with
> the cygwin-icon and then works from within bash), his path will only
> include applications that reside inside the cygwin-tree.

However, what of Michael's User2: ?

> User2 is a NT-User who has found out that the standard tools that come
> with Windows/NT are not powerfull enough to assist him in doing his
> daily job. This user will have the cygwin directories somewhere in his
> path. And here the fun begins. 

Still NOT a problem -- for the official cygwin programs -- since the
executables live in /usr/bin (== /bin) and the dll's are there, too. 
The only problems are those local cygwin apps that do not live in
/usr/bin.  User2 cannot play PATH games -- or his non-cygwin apps which
depend on dll's with names similar to cygwin's will get the cygwin dll's
by mistake. So, he must 
   1) cp /usr/bin/*.dll /usr/local/bin (yuck)
   2) on NT/2K: ln /usr/bin/*.dll /usr/local/bin/...  
          hardlinks will work, I think
   3) or put the non-cygwin app's dlls into its executable directory
(this applies as well to other Unix-on-windows systems; they're free to
use a 'pw' prefix or whatever instead of lib, or just insure that all
executables reside in the same directory with their dll's like cygwin is
trying to do.

So, it seems to me that changing the library prefix is not really
necessary -- since there are less intrusive ways to fix the problems.

Hasn't this discussion been fun?  &-P

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Re[2]: DLL naming conventions

[Earnie Boyd]

--- Paul Sokolovsky <paul-ml@is.lg.ua> wrote:
>     Note, that my very question is about whether Cygwin people want
> that to be automatically supported by libtool. 

Simple question, simple answer; *yes* libtool should support Cygwin.  Thank-you
for asking.

Cheers,

=====
---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://gw32.freeyellow.com/ >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com