RE: DLL naming conventions

RE: DLL naming conventions

[Bernard Dautrevaux]

> -----Original Message-----
> From: Gary V. Vaughan [ mailto:gvv@techie.com ]
> Sent: Sunday, September 03, 2000 2:05 PM
> To: Charles Wilson
> Cc: cygwin@sources.redhat.com; libtool@gnu.org
> Subject: Re: DLL naming conventions
> 

	<skipped>

> > It doesn't work for Michael's 'user 2' -- the guy who 
> normally runs in
> > cmd.exe/command.com, but relies on cygwin commands every once in a
> > while.  He doesn't use bash, but likes the cygwin-perl or grep every
> > once and a while.  User 2 will have the cygwin directories 
> somewhere in
> > her path -- but not necessarily first.
> 
> We could tell these people to put C:/cygwin/usr/bin at the front of
> their PATH...

This would not work, as user2 will be tell by cygwin to put
C:/cygwin/usr/bin at the front of their path, and by PW or Mingw32 to put
THEIR directory with DLLs in front of the path ;-(

> 
> > > Does cygwin ld use -rpath yet?  
> > 
> > I don't think so.  -rpath is something that ld.so uses; 
> Windows doesn't
> > have ld.so. Windows *always* loads dll's according to the following
> > search order:
> >    current directory
> >    app's load directory
> >    global executable search path
> > 
> > The only two exceptions I know of are:
> > 
> >   1) In Win2K, if there is a file called 'app.exe.local' in the same
> > directory as app.exe, then all dll's will be loaded from 
> the app's load
> > directory -- even if explicitly dlopened() with an absolute 
> path that
> > points elsewhere.  the .local. may also override the 
> 'current directory'
> > part of the search order listed above, but I'm not sure.
> 
> Holy cr@p! What happened to simplicity?  If Bill has decided that he
> can't understand how to write a decent shared library system, and
> want's to relegate dll's to LoadLibrary() objects, why doesn't he just
> say so?  Wouldn't it be easier to statically link a Win2k program that
> twiddle about with all this .local mess?

Anyway this would not work; th eproblem is not getting the DLLs that are in
the same directory as the EXE, but selecting th eright DLL when it is not
there :-)

> 
> >   2) You can put something called 'AppPath' in the 
> registry, which will
> > influence the directories that are searched. I don't know 
> where in the
> > list above that the directories listed in the 'AppPath' key are
> > inserted.
> 
> This sounds promising.  I'll see if I can find any details on it.

This could efefctively be the solution, if Bill didn't manage to render it
unusable :-).

> 
> > > I am prepared to work on having libtool do the right thing as far
> > > as possible. 
> > 
> > What was the right thing, again?  :-)
> 
> Based on our conversation so far:
> 
>   * When building a libtool (.la) library, create libfoo.la,
>     libfoo<iface>.dll, libfoo.dll.a and libfoo.a, where:
>       - <iface> is the earliest fully supported interface number
>       - libfoo.dll.a is the import library for libfoo<iface>.dll
>       
>   * When installing a libtool (.la) library:
>       - libfoo.la goes to $prefix/lib
>       - libfoo<iface>.dll goes to $prefix/bin
>       - libfoo.dll.a goes to $prefix/lib
>       - libfoo.a goes to $prefix/lib
>       
>   * When linking against libfoo.la
>       - use libfoo.dll.a unless -static or -all-static 
>       - otherwise use libfoo.a
> 
>   * When linking against -lfoo
>       - if libfoo.la is found, behave as above
>       - else let ld (or gcc) do its thing
> 
> Which is especially cool, because I don't think I need to worry about
> dealing with direct linkage to dlls (I can just punt and let gcc/ld do
> the hard work) which removes a whole pile of spaghetti where I had to
> cope with compiling the impgen code correctly in cross compilation
> environments!

This scheme seems to work for me also; the only think I would like to have,
when libtool is used to build a DLL, is the ability to say to libtool:
please name the DLL itself <something>foo.dll instead of the default
libfoo.dll; even if cygwin insists that there libraries should be named
libfoo.dll, so that they may conflict with others, I would be able to name
my own dlls with some unique name so that I can blame cygwin if my customers
have problems with conflicting libraries :-)

> 
> > > By default libtool always searches for a dll to link against and
> > > generates the implib on the fly if a suitable one is found.
> 
> This won't be necessary under the new scheme =)O|
> 
> > There are occaisions where you want to link to an import lib in
> > preference to a dll -- for instance, libcygwin.a is an 
> import lib, but
> > contains initializer code and actual function 
> implementations for some
> > functions that are not included in the dll itself.  If you 
> attempt to
> > link directly to cygwin1.dll, the link fails because those 
> things are
> > missing from the virtual on-the-fly implib.
> 
> I didn't know about that.  Thanks.

That a thing that I also have to do for some of my DLLs.

> 
> > But where do you put the dll?  It has to go into the 
> executable PATH so
> > that the windows loader can find it.  Do you copy it into 
> /usr/lib, so
> > that the default ld search path will find it?  Do you add 
> /usr/bin to
> > the linktime library search path (-L/usr/bin)?  Perhaps a symlink in
> > /usr/lib, pointing to /usr/bin/libfoo.dll is all you need. 
> > 
> > However!!! Ld uses the following library name search order 
> when hunting
> > for -lfoo:
> > 
> >   libfoo.dll.a
> >   foo.dll.a
> >   libfoo.a  <<<< NOTE!!
> >   libfoo.dll
> >   foo.dll
> 
> Or that.  Thanks again!  Libtool already provides --disable-static if
> the user wants to build and install only the dll parts of the library.

Why this should have to avoid generating and installing libfoo.dll.a ?

> 
> For this to work (that is, in order for me to be able to punt 
> to gcc/ld
> in the majority of cases) I must generate dll names that will be
> found, so the cygfoo.dll idea is out (Sorry Paul!).

Not sure; we are in development environment, so we may expect the user to
either have the import libraries fro DLL they want to link against (anyway
they will need proper include files, don't they) and if the package is
somewhat broken (i.e. not libtool-generated), and do not provide import
libraries, then it better have its libraries called libfoo.dll, or even just
foo.dll as this may be a native win32 library and no one of those even knows
of the "standard" lib prefix :-)

In fact IMHO the main cases where we must link directly against DLLs without
an import library is for native library that do NOT get a lib prefix. Cygwin
libtool-generated DLLs will have import libraries, so no problem at all.
 
> 
> Although this doesn't help ``User 2'' very much, he is no worse off
> than before if I change libtool's behaviour in this way.  Here's a
> thought:  For each dll using application linked, I could have libtool
> install a .bat script to C:/cygwin/launch (or similar) which would set
> the PATH environment correctly for that application.  As long as
> ``User 2'' has the launch directory higher in his PATH than the actual
> binary directory, this would guarantee correct dll selection.

Are you sure I can execve("xyz" ...) from mingw32 (or cygwin) and
effectively execute your BAT wrapper? even if I were to accept the
performance penalty in production code :-(

> 
> This would give ``User 1'' many of the advantages shared libraries
> offer on Unix, without sinking into DLL Hell.  Assuming that everyone
> buys into it.  The only reason shared libraries work properly on Unix
> is that everyone has to agree to conform to the runtime loader's
> versioning scheme -- so don't give some excuse about ``if we don't
> want to change the core cygwin dll's to conform this won't work''.  On
> my linux box, I can move my libc around or drop several incompatible
> versions of libc into my filesystem, and my applications will stop
> loading the intended libraries too.  No surprises there!

Some! I remember a lot of problems with people mixing libc5 and libc6, and
even some of my libc6 programs just crashing randomly till I discover that
glibc-2.0 and glibc-2.1 were incompatible, but were both considered as libc6
without any complain from the dynamic linker. And that do not seems too much
surprising t me as libc5 and libc6 could be seens as PW and CYGWIN, while
glibc-2.0/glibc-2.1 is cygwin-1.1.0/cygwin-1.1.4.

And anyway, as you say, the UNIX situation is a lot better than the WIN32
one because there IS some conventions that you MUST follow to have your code
work, while on WIN32 there is none; that's why I would like a lot to have
some convention defined to help solve this 'incompatible environment'
problem that is like the 'libc5/libc6' one, but worse because I do not think
PW is going to replace cygwin, nor the opposite, whereas libc6 has replaced
libc5.

Anyway, I could live with cygwin keeping the lib prefix, as I recompile most
of the libraries I use to add some local changes so anyway, as far as I'm
concerned, I would not use cygfoo.dll by my_foo.dll, as far as libtool
allows me to do so :-)

Regards,

	Bernard


--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

Re: DLL naming conventions

[David A. Cobb]

Bernard Dautrevaux wrote:

> > -----Original Message-----
> > From: Gary V. Vaughan [ mailto:gvv@techie.com ]
> > Subject: Re: DLL naming conventions
> >
>
>         <skipped>
>

<clip/>

> This scheme seems to work for me also; the only think I would like to have,
> when libtool is used to build a DLL, is the ability to say to libtool:
> please name the DLL itself <something>foo.dll instead of the default
> libfoo.dll; even if cygwin insists that there libraries should be named
> libfoo.dll, so that they may conflict with others, I would be able to name
> my own dlls with some unique name so that I can blame cygwin if my customers
> have problems with conflicting libraries :-)
>

We seem to have two whole categories of user mixed here.  Some of us have our
machines set up as development platforms and use the Cyg/Mng/Whatever packages
to build bigger packages.  Most of this thread appears to address that class of
user.

Some just want to /use/ the darn thing for some other effort!  For most of the
tools, all I want is a binary tarball and the simplest installation I can get.
We _need_ to deploy "products" that work for this class of user without stepping
on the other things she installed last week.

IMHO, this is why Windoz walked all over XNix; even tho' XNix was there first.
Windoz is /hard/ on developers, but several million "simple" /users/ never see
the difficulty -- except, of course, at the CompUSA cash register.
--
David A. Cobb, Software Engineer, Public Access Advocate
"Don't buy or use crappy software"
"By the grace of God I am a Christian man,
 by my actions a great sinner" -- The Way of a Pilgrim [R. M. French, tr.]



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

Re: DLL naming conventions

[Egor Duda]

Hi!

Tuesday, 05 September, 2000 Larry Hall (RFK Partners, Inc) lhall@rfk.com wrote:

LHRPI> At 10:31 AM 9/5/2000, Egor Duda wrote:
>>Tuesday, 05 September, 2000 Earnie Boyd earnie_boyd@yahoo.com wrote:
>>EB> --- Chris Faylor <cgf@cygnus.com> wrote:
>> >> 
>> >> Of course, if we ever write our "registry as a file system" module for
>> >> cygwin, you could have a tar file which extracted executables to /bin
>> >> and registry information to /registry/LocalMachine/Software/...
>> >> 
>>
>>EB> Hey, I like this.  So then, `ls /registry/LocalMachine/Software' should then
>>EB> list the registry.  Cool, just cool.
>>
>>not  so  cool  as  you  can think. i've implemented such "plugin" to
>>cygwin  somewhere  around 1998, and ls /registry/LocalMachine/Software
>>worked ok. and
>>
>>cat "/registry/CurrentUser/Software/Cygnus Solutions/Cygwin/mounts v2/cygdrive prefix"
>>
>>worked  ok  too. but when i dug into this, i couldn't find good mapping
>>from  registry  semantics  to  unix-stype  file  system semantics. for
>>example,  registry values can be of several different types -- string,
>>multistring,  binary,  dword, etc. what should this be looking like in
>>fs tree?
>>
>>putting  /registry/.../ into tar.gz should work, though, if only we'll
>>use string type values only.

LHRPI> Hm, just curious but did you look at what UWIN?  According to the 
LHRPI> documentation, they have such a file system.

i  looked at uwin, but on totally different subject. i wanted to know
how    they   implement  setuid(). yesterday i've installed it and see
that it has it's own quirks. for example,

=========================================================
$ mkdir /reg/current_user/Software/Foo
$ echo 123 >/reg/current_user/Software/Foo/bar
$ cat /reg/current_user/Software/Foo/bar
=0x7b
=========================================================

surprise!

you  had  to  write specially preformatted data to get what you really
need.    not    as    simple   as   in   plain   file   i/o,   where
what-you-put-is-what-you-get.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19



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

Re: DLL naming conventions

[Robert Collins]

----- Original Message -----
From: "David A. Cobb" <superbiskit@home.com>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <cygwin@sources.redhat.com>
Sent: Wednesday, September 06, 2000 8:51 AM
Subject: Re: DLL naming conventions


> Robert Collins wrote:
>
> > There a path trick used in system integration on *metaframe/ NT Terminal
> > Server* machines to keep dll hell to a minimum - I just remembered it...
> >
> > adding (windows path format) .\bin;..\bin;..\..\bin; to the front if
your
> > path allowed different applications to find different versions of dlls
with
> > the same name, the installer just moved the customised .dll to the
farthest
> > point in the path that did cause issues...
> >
> > maybe a similar trick could help? Although it doesn't get round the
> > in-mmeory issue for win9x/nt 4.0 workstation & server
> >
>
> And I responded enthusiastically, at first glance.  However, having "./"
at
> the front of the $PATH is also a well-known security trapdoor:  User
enters name
> of a "system" script X which uses command Y; user replaces Y with a script
in
> her local directory; Y runs in a context (say su) where it can do some
damage.

yes I recall that... what prevents a user writing a well know script to
c:\windows\system on win9x?

also I'm not suggestign "./", rather  "./bin" which may well introduce the
same issue... but ignoring 9x (as above) within a users directory on NT with
ntsec only that user or an admin should be placing new files.. So user knows
what is there unless they are downloading tars that put things in funny
locations, without checking the contents (which is a bigger risk IMHO).
Imagine putting a compromised bash 'upgrade' on your system...

I think given the platform, it's a minor issue. But anyway it doesnt tackle
in-memory .dll's so it's a moot point.


> --
> David A. Cobb, Software Engineer, Public Access Advocate
> "Don't buy or use crappy software"
> "By the grace of God I am a Christian man,
>  by my actions a great sinner" -- The Way of a Pilgrim [R. M. French, tr.]
>
>
>

Rob


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

Re: DLL naming conventions

[David A. Cobb]

Robert Collins wrote:

> There a path trick used in system integration on *metaframe/ NT Terminal
> Server* machines to keep dll hell to a minimum - I just remembered it...
>
> adding (windows path format) .\bin;..\bin;..\..\bin; to the front if your
> path allowed different applications to find different versions of dlls with
> the same name, the installer just moved the customised .dll to the farthest
> point in the path that did cause issues...
>
> maybe a similar trick could help? Although it doesn't get round the
> in-mmeory issue for win9x/nt 4.0 workstation & server
>

And I responded enthusiastically, at first glance.  However, having "./" at
the front of the $PATH is also a well-known security trapdoor:  User enters name
of a "system" script X which uses command Y; user replaces Y with a script in
her local directory; Y runs in a context (say su) where it can do some damage.
--
David A. Cobb, Software Engineer, Public Access Advocate
"Don't buy or use crappy software"
"By the grace of God I am a Christian man,
 by my actions a great sinner" -- The Way of a Pilgrim [R. M. French, tr.]



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

Re: DLL naming conventions

[David A. Cobb]

Robert Collins wrote:

> There a path trick used in system integration on *metaframe/ NT Terminal
> Server* machines to keep dll hell to a minimum - I just remembered it...
>
> adding (windows path format) .\bin;..\bin;..\..\bin; to the front if your
> path allowed different applications to find different versions of dlls with
> the same name, the installer just moved the customised .dll to the farthest
> point in the path that did cause issues...
>
> maybe a similar trick could help? Although it doesn't get round the
> in-mmeory issue for win9x/nt 4.0 workstation & server

That would also address the synaptic gap caused because XNix and Cygwin do not
scan "current" first, while Windoz does.  I boot it quite often by typing
"scriptname" when I want a script that is in the current directory.
--
David A. Cobb, Software Engineer, Public Access Advocate
"Don't buy or use crappy software"
"By the grace of God I am a Christian man,
 by my actions a great sinner" -- The Way of a Pilgrim [R. M. French, tr.]



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

Re: DLL naming conventions

[David A. Cobb]

[Responses interleaved]
"Charles S. Wilson" wrote:

> Robert Collins wrote:
> >
> > but this also means that mingw32 program won't use the cygwin compiled
> > libpng if it is there? is that acceptable?
>
> cygwin-libpng.dll depends on cygwin1.dll, which implements many of the
> runtime functions, such as printf(), startup code, etc.
>
> A mingw program (or mingw-libpng.dll, for that matter), depends on
> crt.dll (or msvcrt.dll, depending on which flavor of mingw you're
> using).  crt.dll (or msvcrt.dll) implement printf(), startup code, etc.

> Not necessarily, if the PATH settings (or insuring that all dll's and
> exe's go into the same directory) are sufficient to prevent problems.

Wouldn't that require launching every executable from a console shell where $PATH
can be manipulated?  Having built an Ap, might I not reasonably want to launch it
from a desktop icon?  Of course, the icon can be for a script - but I don't care
to see the extra DOS box, thanks.

> I don't think so, personally.  As distasteful and painful as renaming all
> the dll's is, it *may*, repeat *may*, be the best option.  I believe
> Chris is proactively doing some research; it is possible that we can do
> something else, and avoid the 'cyg' prefix -- like using the 'AppPath'
> registry or something.
>
> It's just that there is an ingrained desire to stay as unix-like as
> possible -- and that means, libraries start with 'lib', not 'cyg'.

What about "libpng2" for both IF AND ONLY IF they expose an interface identical to
the XNix equivalent, "libpng2-cyg" & "libpng2-mng" if not; from within the
library, reference "cygwin1" or "crt-mng" or whatever: different names because
those do not expose an identical interface.  The user of, say, "libpng2" should
not need to care at all what libraries his "server" lib uses.

> If AppPath can fix the problem, then I'd prefer that cygwin's install.exe
> set the appropriate registry entry whenever installing an executable.
> This won't catch *everything*, but dagnabbit, I'm tired of packages
> installing themselves with cp (which break on cygwin thanks to the .exe
> suffix).  They oughta use install.

Aha!  One more damn'd learning experience.  Can everything be installed?
F'rinstance, there are packages out there that say "just untar this into
/usr/local."  Should I be using "install" instead?
--
David A. Cobb, Software Engineer, Public Access Advocate
"Don't buy or use crappy software"
"By the grace of God I am a Christian man,
 by my actions a great sinner" -- The Way of a Pilgrim [R. M. French, tr.]



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

Re: DLL naming conventions

[Earnie Boyd]

--- Egor Duda <deo@logos-m.ru> wrote:
> Hi!
> 
> Tuesday, 05 September, 2000 Earnie Boyd earnie_boyd@yahoo.com wrote:
> 
> EB> --- Chris Faylor <cgf@cygnus.com> wrote:
> >> 
> >> Of course, if we ever write our "registry as a file system" module for
> >> cygwin, you could have a tar file which extracted executables to /bin
> >> and registry information to /registry/LocalMachine/Software/...
> >> 
> 
> EB> Hey, I like this.  So then, `ls /registry/LocalMachine/Software' should
> then
> EB> list the registry.  Cool, just cool.
> 
> not  so  cool  as  you  can think. i've implemented such "plugin" to
> cygwin  somewhere  around 1998, and ls /registry/LocalMachine/Software
> worked ok. and
> 
> cat "/registry/CurrentUser/Software/Cygnus Solutions/Cygwin/mounts
> v2/cygdrive prefix"
> 
> worked  ok  too. but when i dug into this, i couldn't find good mapping
> from  registry  semantics  to  unix-stype  file  system semantics. for
> example,  registry values can be of several different types -- string,
> multistring,  binary,  dword, etc. what should this be looking like in
> fs tree?
> 

Uhm, the data values would be ok to cat and tar but not ok to ls.  The registry
keys would be the fs tree and the registry data would be the what would be
read.

> putting  /registry/.../ into tar.gz should work, though, if only we'll
> use string type values only.
> 

It should even be ok with the other types of data as long is you ensured the
data was processed in binary mode.

Ok, sure I'm probably oversimplifying it.

=====
--- < http://earniesystems.safeshopper.com > ---
   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

Re: DLL naming conventions

[Larry Hall (RFK Partners, Inc)]

At 10:31 AM 9/5/2000, Egor Duda wrote:
>Hi!
>
>Tuesday, 05 September, 2000 Earnie Boyd earnie_boyd@yahoo.com wrote:
>
>EB> --- Chris Faylor <cgf@cygnus.com> wrote:
> >> 
> >> Of course, if we ever write our "registry as a file system" module for
> >> cygwin, you could have a tar file which extracted executables to /bin
> >> and registry information to /registry/LocalMachine/Software/...
> >> 
>
>EB> Hey, I like this.  So then, `ls /registry/LocalMachine/Software' should then
>EB> list the registry.  Cool, just cool.
>
>not  so  cool  as  you  can think. i've implemented such "plugin" to
>cygwin  somewhere  around 1998, and ls /registry/LocalMachine/Software
>worked ok. and
>
>cat "/registry/CurrentUser/Software/Cygnus Solutions/Cygwin/mounts v2/cygdrive prefix"
>
>worked  ok  too. but when i dug into this, i couldn't find good mapping
>from  registry  semantics  to  unix-stype  file  system semantics. for
>example,  registry values can be of several different types -- string,
>multistring,  binary,  dword, etc. what should this be looking like in
>fs tree?
>
>putting  /registry/.../ into tar.gz should work, though, if only we'll
>use string type values only.
>
>Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19



Hm, just curious but did you look at what UWIN?  According to the 
documentation, they have such a file system.





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

[Egor Duda]

Hi!

Tuesday, 05 September, 2000 Earnie Boyd earnie_boyd@yahoo.com wrote:

EB> --- Chris Faylor <cgf@cygnus.com> wrote:
>> 
>> Of course, if we ever write our "registry as a file system" module for
>> cygwin, you could have a tar file which extracted executables to /bin
>> and registry information to /registry/LocalMachine/Software/...
>> 

EB> Hey, I like this.  So then, `ls /registry/LocalMachine/Software' should then
EB> list the registry.  Cool, just cool.

not  so  cool  as  you  can think. i've implemented such "plugin" to
cygwin  somewhere  around 1998, and ls /registry/LocalMachine/Software
worked ok. and

cat "/registry/CurrentUser/Software/Cygnus Solutions/Cygwin/mounts v2/cygdrive prefix"

worked  ok  too. but when i dug into this, i couldn't find good mapping
from  registry  semantics  to  unix-stype  file  system semantics. for
example,  registry values can be of several different types -- string,
multistring,  binary,  dword, etc. what should this be looking like in
fs tree?

putting  /registry/.../ into tar.gz should work, though, if only we'll
use string type values only.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19



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

Re: DLL naming conventions

[Earnie Boyd]

--- Chris Faylor <cgf@cygnus.com> wrote:
> 
> Of course, if we ever write our "registry as a file system" module for
> cygwin, you could have a tar file which extracted executables to /bin
> and registry information to /registry/LocalMachine/Software/...
> 

Hey, I like this.  So then, `ls /registry/LocalMachine/Software' should then
list the registry.  Cool, just cool.

=====
--- < http://earniesystems.safeshopper.com > ---
   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

Re: DLL naming conventions

[Robert Collins]

...

> Robert Collins wrote:
> >
> > but this also means that mingw32 program won't use the cygwin compiled
> > libpng if it is there? is that acceptable?
>
> mingw programs can't use cygwin libraries. Period. This is due to
> library dependencies.
>
> cygwin-libpng.dll depends on cygwin1.dll, which implements many of the
> runtime functions, such as printf(), startup code, etc.
>
> A mingw program (or mingw-libpng.dll, for that matter), depends on
> crt.dll (or msvcrt.dll, depending on which flavor of mingw you're
> using).  crt.dll (or msvcrt.dll) implement printf(), startup code, etc.
>
> If you were to link a mingw-compiled .o with a cygwin-libpng.dll, using
> the mingw linker -- which printf() would get used? Which startup code?
> Well, actually the link would fail -- due to 'duplicate symbol'
> problems.

that answers that question :]

> And all this happens *without* mysterious mingw-libpng.dll /
> cygwin-libpng.dll DLL hell.
>
> > -> if we are looking to keep the sandbox's separate then yes.. but why
care
> > about running a (say) mingw32 program from cygwin bash...
>
> Okay, now this is a valid issue.  But, you are much too unspecific.  You
> can still call a generic mingw32 program from cygwin bash.  The
> assumption is, that while in bash, the PATH is set so that cygwin's
> /usr/bin,/bin is in the front.  But that doesn't mean that some mingw
> directory cannot be toward the back of the path.  Finally, recall that
> dll's will get loaded preferentially from the same directory that the
> executable is in.
>
> So, the *only* way you get in trouble is if ALL of the following are
> true:  You run bash.  cygwin's /usr/bin,/bin is in the front of the
> PATH.  You call 'mingw-program1', which depends on the mingw version of
> my-dll.dll.  mingw-program1 is in, say, c:\mingw\usr\local\bin.
> my-dll.dll is in c:\mingw\usr\bin -- e.g. a different directory that
> mingw-program1.  There is a cygwin-compiled version of my-dll.dll, in
> cygwin's /usr/bin.
>
> Pretty damn unlikely, IMO.

What about this then?
I start up bash, and then a cygwin X-server. it loads libXpm.dll into
memory.
from there I run, say Gimp for X11 on win32 (sorry Tor, it's just a good
example). it's been built with mingw32, and need libXpm.
it gets the cygwin libxpm. regardless of path, no questions asked. oops
crash oh well mail the support lists...

> > -> if we are looking to let things cross the sandbox we should decide
_what_
> > things, (ie bin/pipes, bin/pipes/libs, binaries only..) we are able to
> > support and then make it as flexable as possible.
>
> libraries cannot. pipes probably can (given the textmode/binmode
> issues...). Of course you can call programs from native- or
> other-unix-on-win platforms; as long as there is no confusion about
> dll's.
>
> All we're discussing is how to avoid dll hell between these platforms.

yes.. But we we going round the how much changes are needed questions with a
basic assumption - that we couldn't have libraries mixed, and we wanted
mixed executables on a given machine. I just wanted to understand clearly,
how much flexability we were trying to achieve.. which I've got now

Libraries: None. Not going to happen. End of story. Each 'environment' needs
to be partitioned - msvc, mingw32, cygwin, pw et al. they cannot use
libraries from each other

pipes: whatever the two exes support.

binaries from one environment to another... unknown at this point (ie in
cygwin X-term running a mingw32 ksh? (Ok I wouldn't do that but someone may
try).

> >
> > I think we need to make that decide first, and then the rest falls into
> > place....
> >
> > if we want full cross over from the sandboxes then the answer should
permit
> > only porting layer/method to use another libraries. So a port
layer/method
> > specific library naming convention is not acceptable.
>
> Can't use other-compiled versions of libraries anyway (okay, *maybe* you
> can mix mingw and msvc, but that's not at issue here. We're talking
> about cygwin.)
>
> > likewise if we want
> > sandboxes then porting layer/method specific library file names becomes
> > mandatory.
>
> Not necessarily, if the PATH settings (or insuring that all dll's and
> exe's go into the same directory) are sufficient to prevent problems.  I
> don't think so, personally.  As distasteful and painful as renaming all
> the dll's is, it *may*, repeat *may*, be the best option.  I believe
> Chris is proactively doing some research; it is possible that we can do
> something else, and avoid the 'cyg' prefix -- like using the 'AppPath'
> registry or something.

I think the in-memory issue is the critical problem... if we can't get two
different abc.dll files in memory then we much name all .dll's differently.

> It's just that there is an ingrained desire to stay as unix-like as
> possible -- and that means, libraries start with 'lib', not 'cyg'.  If
> AppPath can fix the problem, then I'd prefer that cygwin's install.exe
> set the appropriate registry entry whenever installing an executable.
> This won't catch *everything*, but dagnabbit, I'm tired of packages
> installing themselves with cp (which break on cygwin thanks to the .exe
> suffix).  They oughta use install.
>
> >
> > Personally I think that a mingw32 libpng should be useable by cygwin gcc
AND
> > cygwin distributed binaries, given that they are the same version...
(and
> > that should be part of the naming convention).
>
> Just cannot be done. Sorry.

Ah well.. worth asking. (Btw thanks Corinna and Bernard for your answers
too!)


(Shame they are both no!)

Rob



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

Re: DLL naming conventions

[Robert Collins]

There a path trick used in system integration on *metaframe/ NT Terminal
Server* machines to keep dll hell to a minimum - I just remembered it...

adding (windows path format) .\bin;..\bin;..\..\bin; to the front if your
path allowed different applications to find different versions of dlls with
the same name, the installer just moved the customised .dll to the farthest
point in the path that did cause issues...

maybe a similar trick could help? Although it doesn't get round the
in-mmeory issue for win9x/nt 4.0 workstation & server

Rob

----- Original Message -----
From: "Bernard Dautrevaux" <Dautrevaux@microprocess.com>
To: "'Charles S. Wilson'" <cwilson@ece.gatech.edu>; "Robert Collins"
<robert.collins@itdomain.com.au>; <cygwin@sources.redhat.com>
Sent: Tuesday, September 05, 2000 2:27 AM
Subject: RE: DLL naming conventions


> > -----Original Message-----
> > From: Charles S. Wilson [ mailto:cwilson@ece.gatech.edu ]
> > Sent: Monday, September 04, 2000 5:09 PM
> > To: Robert Collins; cygwin@sources.redhat.com
> > Subject: Re: DLL naming conventions
> >
> >
> ....
>
> >
> > Here's the search order for DLL's when an AppPath key is set for the
> > executable in the registry:
> >
> > 1.The directories listed in the App Path registry key
> >
> > 2.The directory where the executable module for the current process is
> > located.
> >
> > 3.The current directory.
> >
> > 4.The Windows system directory. The GetSystemDirectory function
> > retrieves the path of this directory.
> >
> > 5.The Windows directory. The GetWindowsDirectory function
> > retrieves the
> > path of this directory.
> >
> > 6.The directories listed in the PATH environment variable.
> >
> >
> > See http://codeguru.earthweb.com/dll/AppPath.shtml
> >
> > So, if all .exe's are installed using 'install.exe', and
> > install.exe is
> > made smart enough to create an AppPath key for each one -- the problem
> > is solved!
> >
> > (sotto voce: ermmm...three minor problems:
> >
> > 1. The AppPath entry must be in windows-format:
> > C:\cygwin\bin;C:\cygwin\usr\local\bin  NOT /bin:/usr/local/bin.  What
> > happens when you reinstall cygwin to a different location -- say
> > D:\cygwin -- and change the mount points?
> >
> > 2. The AppPath entry is keyed by the program name:
> >
> > HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\foo.exe
> >   default value is string   = "C:\cygwin\usr\local\bin\foo.exe"
> >   string value named "Path" = "C:\cygwin\bin;C:\cygwin\usr\local\bin"
> >
> > What if you have two foo.exe's -- one cygwin, and one mingw ?
>
> Or cygwin find/native find ? Gonna crash the find feature of Explorer?
>
> >
> > 3. It doesn't work if there is already a dll with the same
> > name, loaded
> > into memory (for Win95, Win98, and WinNT; the following
> > analysis doesn't
> > apply to Win98SE or W2K)
> >
> > e.g.
> >   c:\cygwin\usr\local\bin\app1.exe
> >     (app1.exe has AppPath key so that c:\cygwin\usr\bin is searched
> > first)
> >   c:\cygwin\usr\bin\my-dll.dll
> >
> >   c:\mingw\usr\local\bin\app2.exe
> >     (app2.exe has AppPath key so that c:\mingw\usr\bin is searched
> > first)
> >   c:\mingw\usr\bin\my-dll.dll
> >
> > Run app1.exe -- fine, c:\cygwin\usr\bin\my-dll.dll gets loaded.
> > Run app2.exe -- *will not load* c:\mingw\usr\bin\my-dll.dll
> > into memory.
> >
> > This analysis extrapolated from description in:
> > http://codeguru.earthweb.com/mfc/comments/6493.shtml
> >
> > Maybe the problem isn't solved by AppPath, after all.
> >
>
> This seems to say that DLLs are searched FIRST in memory, then on the disk
> (at least on NT and 95/98)... That was what I seems to understand while
> reading MSDN Library where they says that side-by-side libraries avoid
this
> preference given to already loaded libraries.
>
> If this proves true, then the only solution would be to change the name of
> the DLLs ;-(
>
> Note that the in-memory problem is particularly important giving the fact
> that a lot of windoze apps (cygwin or not) are usually long-lived
especially
> if they have a GUI. Thus if one starts a mingw GUI app that uses
libpng.dll
> (quite logical) then NO cygwin app using libpng will be able to run as it
> will always try to use the mingw-libpng.dll in memory.
>
> Does that mean that most ported unix apps were not interactive apps but
> short-lived ones or that people are so sued to PCs crashing when trying to
> do several things at once that they do not complain :-)
>
> Cheers,
>
> Bernard
>
> --------------------------------------------
> Bernard Dautrevaux
> Microprocess Ingenierie
> 97 bis, rue de Colombes
> 92400 COURBEVOIE
> FRANCE
> Tel: +33 (0) 1 47 68 80 80
> Fax: +33 (0) 1 47 88 97 85
> e-mail: dautrevaux@microprocess.com
> b.dautrevaux@usa.net
> --------------------------------------------
>


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

Re: DLL naming conventions

[Chris Faylor]

On Mon, Sep 04, 2000 at 11:09:23AM -0400, Charles S. Wilson wrote:
>Maybe the problem isn't solved by AppPath, after all.

From my reading of DejaNews and MSDN, I don't think that AppPath is a
solution at all.

It only seems to be invoked when you run something by double clicking on
it.  There were complaints that programs invoked from the command prompt
did not recognize it.

There is also the burden of installing this in the registry.  I don't
think that is solvable.  Not every cygwin package is going to have an
installer.

Of course, if we ever write our "registry as a file system" module for
cygwin, you could have a tar file which extracted executables to /bin
and registry information to /registry/LocalMachine/Software/...

I've spent a couple of hours rereading my various Windows Internals
books.  I had this (futile?) dream that binutils could somehow be
modified to allow cygwin to "do the right thing" as far as shared
libraries were concerned.

I don't see how that is possible though without essentially inventing
our own shared libraries.

The delayed loading stuff that is in VC 6 was sort of interesting.  I
actually use a technique very similar to VC's delayed loading in cygwin.
I thought briefly that this might be a solution but delayed loading
doesn't work with data elements, so that makes it unusable for generic
shared library support.

cgf

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

RE: DLL naming conventions

[Bernard Dautrevaux]

> -----Original Message-----
> From: Charles S. Wilson [ mailto:cwilson@ece.gatech.edu ]
> Sent: Monday, September 04, 2000 5:09 PM
> To: Robert Collins; cygwin@sources.redhat.com
> Subject: Re: DLL naming conventions
> 
> 
	....

> 
> Here's the search order for DLL's when an AppPath key is set for the
> executable in the registry:
> 
> 1.The directories listed in the App Path registry key 
> 
> 2.The directory where the executable module for the current process is
> located. 
> 
> 3.The current directory. 
> 
> 4.The Windows system directory. The GetSystemDirectory function
> retrieves the path of this directory. 
> 
> 5.The Windows directory. The GetWindowsDirectory function 
> retrieves the
> path of this directory. 
> 
> 6.The directories listed in the PATH environment variable.
> 
> 
> See http://codeguru.earthweb.com/dll/AppPath.shtml
> 
> So, if all .exe's are installed using 'install.exe', and 
> install.exe is
> made smart enough to create an AppPath key for each one -- the problem
> is solved!
> 
> (sotto voce: ermmm...three minor problems:
> 
> 1. The AppPath entry must be in windows-format:
> C:\cygwin\bin;C:\cygwin\usr\local\bin  NOT /bin:/usr/local/bin.  What
> happens when you reinstall cygwin to a different location -- say
> D:\cygwin -- and change the mount points?
> 
> 2. The AppPath entry is keyed by the program name:
> 
> HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\foo.exe
>   default value is string   = "C:\cygwin\usr\local\bin\foo.exe"
>   string value named "Path" = "C:\cygwin\bin;C:\cygwin\usr\local\bin"
> 
> What if you have two foo.exe's -- one cygwin, and one mingw ?

Or cygwin find/native find ? Gonna crash the find feature of Explorer?

> 
> 3. It doesn't work if there is already a dll with the same 
> name, loaded
> into memory (for Win95, Win98, and WinNT; the following 
> analysis doesn't
> apply to Win98SE or W2K)
> 
> e.g. 
>   c:\cygwin\usr\local\bin\app1.exe
>     (app1.exe has AppPath key so that c:\cygwin\usr\bin is searched
> first)
>   c:\cygwin\usr\bin\my-dll.dll
> 
>   c:\mingw\usr\local\bin\app2.exe
>     (app2.exe has AppPath key so that c:\mingw\usr\bin is searched
> first)
>   c:\mingw\usr\bin\my-dll.dll
> 
> Run app1.exe -- fine, c:\cygwin\usr\bin\my-dll.dll gets loaded.
> Run app2.exe -- *will not load* c:\mingw\usr\bin\my-dll.dll 
> into memory.
> 
> This analysis extrapolated from description in:
> http://codeguru.earthweb.com/mfc/comments/6493.shtml
> 
> Maybe the problem isn't solved by AppPath, after all.
> 

This seems to say that DLLs are searched FIRST in memory, then on the disk
(at least on NT and 95/98)... That was what I seems to understand while
reading MSDN Library where they says that side-by-side libraries avoid this
preference given to already loaded libraries.

If this proves true, then the only solution would be to change the name of
the DLLs ;-(

Note that the in-memory problem is particularly important giving the fact
that a lot of windoze apps (cygwin or not) are usually long-lived especially
if they have a GUI. Thus if one starts a mingw GUI app that uses libpng.dll
(quite logical) then NO cygwin app using libpng will be able to run as it
will always try to use the mingw-libpng.dll in memory.

Does that mean that most ported unix apps were not interactive apps but
short-lived ones or that people are so sued to PCs crashing when trying to
do several things at once that they do not complain :-)

Cheers,

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

RE: DLL naming conventions

[Bernard Dautrevaux]

> -----Original Message-----
> From: Charles S. Wilson [ mailto:cwilson@ece.gatech.edu ]
> Sent: Monday, September 04, 2000 4:23 PM
> To: Robert Collins
> Cc: cygwin@sources.redhat.com
> Subject: Re: DLL naming conventions
> 
> 
> Robert Collins wrote:
> > 
> > but this also means that mingw32 program won't use the 
> cygwin compiled
> > libpng if it is there? is that acceptable?
> 
> mingw programs can't use cygwin libraries. Period. This is due to
> library dependencies.
> 
> cygwin-libpng.dll depends on cygwin1.dll, which implements many of the
> runtime functions, such as printf(), startup code, etc.  
> 
> A mingw program (or mingw-libpng.dll, for that matter), depends on
> crt.dll (or msvcrt.dll, depending on which flavor of mingw you're
> using).  crt.dll (or msvcrt.dll) implement printf(), startup 
> code, etc.
> 
> If you were to link a mingw-compiled .o with a 
> cygwin-libpng.dll, using
> the mingw linker -- which printf() would get used? Which 
> startup code? 
> Well, actually the link would fail -- due to 'duplicate symbol'
> problems.
> 
> And all this happens *without* mysterious mingw-libpng.dll /
> cygwin-libpng.dll DLL hell.

Sure; it will also happen if linking a mingw-compiled foo.o with a
cygwin-compiled bar.o and this whatever the linker is (mingw or cygwin).

> 
> > -> if we are looking to keep the sandbox's separate then 
> yes.. but why care
> > about running a (say) mingw32 program from cygwin bash...
> 
> Okay, now this is a valid issue.  But, you are much too 
> unspecific.  You
> can still call a generic mingw32 program from cygwin bash.  The
> assumption is, that while in bash, the PATH is set so that cygwin's
> /usr/bin,/bin is in the front.  But that doesn't mean that some mingw
> directory cannot be toward the back of the path.  Finally, recall that
> dll's will get loaded preferentially from the same directory that the
> executable is in.
> 
> So, the *only* way you get in trouble is if ALL of the following are
> true:  You run bash.  cygwin's /usr/bin,/bin is in the front of the
> PATH.  You call 'mingw-program1', which depends on the mingw 
> version of
> my-dll.dll.  mingw-program1 is in, say, c:\mingw\usr\local\bin. 
> my-dll.dll is in c:\mingw\usr\bin -- e.g. a different directory that
> mingw-program1.  There is a cygwin-compiled version of my-dll.dll, in
> cygwin's /usr/bin. 
> 
> Pretty damn unlikely, IMO. 

Not so unlikely, if using libraries from contributed packages, that get
installed if following the standards, under /usr/local/package-x.y.z. I may
get one compiled for cygwin in C:\cygwin\usr\local\package-x.y.z and the
mingw32 one in c:\mingw\usr\local\package-x.y.z.

Now HOW could I set up my path?

I agree I can stash ALL cygwin stuff in C:\cygwin\usr\bin and ALL mingw32
stuff in C:\mingw\bin, but that seems even more hacky as having cygfoo.dll
and mgwfoo.dll located where I expect them :-)

> 
> > -> if we are looking to let things cross the sandbox we 
> should decide _what_
> > things, (ie bin/pipes, bin/pipes/libs, binaries only..) we 
> are able to
> > support and then make it as flexable as possible.
> 
> libraries cannot. pipes probably can (given the textmode/binmode
> issues...). Of course you can call programs from native- or
> other-unix-on-win platforms; as long as there is no confusion about
> dll's.
> 
> All we're discussing is how to avoid dll hell between these platforms.

100% agreed

> 
> > 
> > I think we need to make that decide first, and then the 
> rest falls into
> > place....
> > 
> > if we want full cross over from the sandboxes then the 
> answer should permit
> > only porting layer/method to use another libraries. So a 
> port layer/method
> > specific library naming convention is not acceptable. 
> 
> Can't use other-compiled versions of libraries anyway (okay, 
> *maybe* you
> can mix mingw and msvc, but that's not at issue here. We're talking
> about cygwin.)

In fact, under some conditions (mainly: no reference to msvcrt.dll nor
crtlib.dll) we should be able to use any native win32 DLL with either mingw
or cygwin or any other posix-on-windoze layer. In fact it is even almost a
requirement or we get in some kind of a closed sandbox like was Microsoft
POSIX subsystem.

> 
> > likewise if we want
> > sandboxes then porting layer/method specific library file 
> names becomes
> > mandatory.
> 
> Not necessarily, if the PATH settings (or insuring that all dll's and
> exe's go into the same directory) are sufficient to prevent 
> problems.  

Problem is that is a nightmare to manage a "stash everything in one dir"
installation method.

> I
> don't think so, personally.  As distasteful and painful as 
> renaming all
> the dll's is, it *may*, repeat *may*, be the best option.  

100% agreed; the fact that I don't *know* a better approach does not mean
there isn't one!

> I believe
> Chris is proactively doing some research; it is possible that 
> we can do
> something else, and avoid the 'cyg' prefix -- like using the 'AppPath'
> registry or something.

AppPath may be a solution, but with the problem that this puts the burden on
the package installer and expect *all* other package to be as clever as
mingw ?-) and I'm not sure of how to say when installing a package that DLLs
should be loaded ONLY from subdirectories of C:\cygwin or from standard
places even if the path contains directories where we can find a "matching"
DLL.

This may be a bit complicated, error prone and difficult to maintain (never
seen a dumb installer crashing the registry?)

> 
> It's just that there is an ingrained desire to stay as unix-like as
> possible -- and that means, libraries start with 'lib', not 'cyg'. 

And they end in .so.x.y, not .dll :-)

We had to change th esuffix, so changing the prefix will not break anything
more (i.e. almost nothing IIRC).

> If
> AppPath can fix the problem, then I'd prefer that cygwin's install.exe
> set the appropriate registry entry whenever installing an executable. 

This would mean that install.exe should analyze DLL dependencies when
installing an exe to list all the cygwin directories where to find DLLs;
however this will now add a dependency on the order of installation between
packages providing DLLs and the ones providing EXEs because this would not
be possible if the installed EXE reference a not-yet-installed DLL :-)

> This won't catch *everything*, but dagnabbit, I'm tired of packages
> installing themselves with cp (which break on cygwin thanks 
> to the .exe
> suffix).  They oughta use install.

Sure, but I'm not sure install.exe will be able to solve the problem without
being provided with a lot of other info. (BTW does setup.exe install things
by calling install.exe or just by untarring them at the proper place?)

Another problem is that people may use cygwin as their hosting UNIX-on-WIN
environment and use install.exe to install their application code that may
be mingw32 or natively compiled! here the install.exe magic (which is
definitely not expected by UNIX users) will broke everything :-)

The problem that install.exe is more a programming environment tool than an
end-user tool that is to be executed when one simply wants to use a package.
Even on UNIX, one rarely if ever execute "install" when installing a binary
distribution fo a package.

> 
> > 
> > Personally I think that a mingw32 libpng should be useable 
> by cygwin gcc AND
> > cygwin distributed binaries, given that they are the same 
> version... (and
> > that should be part of the naming convention).
> 
> Just cannot be done. Sorry.
> 

True!

Cheers

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

Re: DLL naming conventions

[Charles S. Wilson]

> Not necessarily, if the PATH settings (or insuring that all dll's and
> exe's go into the same directory) are sufficient to prevent problems.  I
> don't think so, personally.  As distasteful and painful as renaming all
> the dll's is, it *may*, repeat *may*, be the best option.  I believe
> Chris is proactively doing some research; it is possible that we can do
> something else, and avoid the 'cyg' prefix -- like using the 'AppPath'
> registry or something.
> 
> It's just that there is an ingrained desire to stay as unix-like as
> possible -- and that means, libraries start with 'lib', not 'cyg'.  If
> AppPath can fix the problem, then I'd prefer that cygwin's install.exe
> set the appropriate registry entry whenever installing an executable.
> This won't catch *everything*, but dagnabbit, I'm tired of packages
> installing themselves with cp (which break on cygwin thanks to the .exe
> suffix).  They oughta use install.

Here's the search order for DLL's when an AppPath key is set for the
executable in the registry:

1.The directories listed in the App Path registry key 

2.The directory where the executable module for the current process is
located. 

3.The current directory. 

4.The Windows system directory. The GetSystemDirectory function
retrieves the path of this directory. 

5.The Windows directory. The GetWindowsDirectory function retrieves the
path of this directory. 

6.The directories listed in the PATH environment variable.


See http://codeguru.earthweb.com/dll/AppPath.shtml

So, if all .exe's are installed using 'install.exe', and install.exe is
made smart enough to create an AppPath key for each one -- the problem
is solved!

(sotto voce: ermmm...three minor problems:

1. The AppPath entry must be in windows-format:
C:\cygwin\bin;C:\cygwin\usr\local\bin  NOT /bin:/usr/local/bin.  What
happens when you reinstall cygwin to a different location -- say
D:\cygwin -- and change the mount points?

2. The AppPath entry is keyed by the program name:

HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\foo.exe
  default value is string   = "C:\cygwin\usr\local\bin\foo.exe"
  string value named "Path" = "C:\cygwin\bin;C:\cygwin\usr\local\bin"

What if you have two foo.exe's -- one cygwin, and one mingw ?

3. It doesn't work if there is already a dll with the same name, loaded
into memory (for Win95, Win98, and WinNT; the following analysis doesn't
apply to Win98SE or W2K)

e.g. 
  c:\cygwin\usr\local\bin\app1.exe
    (app1.exe has AppPath key so that c:\cygwin\usr\bin is searched
first)
  c:\cygwin\usr\bin\my-dll.dll

  c:\mingw\usr\local\bin\app2.exe
    (app2.exe has AppPath key so that c:\mingw\usr\bin is searched
first)
  c:\mingw\usr\bin\my-dll.dll

Run app1.exe -- fine, c:\cygwin\usr\bin\my-dll.dll gets loaded.
Run app2.exe -- *will not load* c:\mingw\usr\bin\my-dll.dll into memory.

This analysis extrapolated from description in:
http://codeguru.earthweb.com/mfc/comments/6493.shtml

Maybe the problem isn't solved by AppPath, after all.

--Chuck

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

Re: DLL naming conventions

[Charles S. Wilson]

Robert Collins wrote:
> 
> but this also means that mingw32 program won't use the cygwin compiled
> libpng if it is there? is that acceptable?

mingw programs can't use cygwin libraries. Period. This is due to
library dependencies.

cygwin-libpng.dll depends on cygwin1.dll, which implements many of the
runtime functions, such as printf(), startup code, etc.  

A mingw program (or mingw-libpng.dll, for that matter), depends on
crt.dll (or msvcrt.dll, depending on which flavor of mingw you're
using).  crt.dll (or msvcrt.dll) implement printf(), startup code, etc.

If you were to link a mingw-compiled .o with a cygwin-libpng.dll, using
the mingw linker -- which printf() would get used? Which startup code? 
Well, actually the link would fail -- due to 'duplicate symbol'
problems.

And all this happens *without* mysterious mingw-libpng.dll /
cygwin-libpng.dll DLL hell.

> -> if we are looking to keep the sandbox's separate then yes.. but why care
> about running a (say) mingw32 program from cygwin bash...

Okay, now this is a valid issue.  But, you are much too unspecific.  You
can still call a generic mingw32 program from cygwin bash.  The
assumption is, that while in bash, the PATH is set so that cygwin's
/usr/bin,/bin is in the front.  But that doesn't mean that some mingw
directory cannot be toward the back of the path.  Finally, recall that
dll's will get loaded preferentially from the same directory that the
executable is in.

So, the *only* way you get in trouble is if ALL of the following are
true:  You run bash.  cygwin's /usr/bin,/bin is in the front of the
PATH.  You call 'mingw-program1', which depends on the mingw version of
my-dll.dll.  mingw-program1 is in, say, c:\mingw\usr\local\bin. 
my-dll.dll is in c:\mingw\usr\bin -- e.g. a different directory that
mingw-program1.  There is a cygwin-compiled version of my-dll.dll, in
cygwin's /usr/bin. 

Pretty damn unlikely, IMO. 

> -> if we are looking to let things cross the sandbox we should decide _what_
> things, (ie bin/pipes, bin/pipes/libs, binaries only..) we are able to
> support and then make it as flexable as possible.

libraries cannot. pipes probably can (given the textmode/binmode
issues...). Of course you can call programs from native- or
other-unix-on-win platforms; as long as there is no confusion about
dll's.

All we're discussing is how to avoid dll hell between these platforms.

> 
> I think we need to make that decide first, and then the rest falls into
> place....
> 
> if we want full cross over from the sandboxes then the answer should permit
> only porting layer/method to use another libraries. So a port layer/method
> specific library naming convention is not acceptable. 

Can't use other-compiled versions of libraries anyway (okay, *maybe* you
can mix mingw and msvc, but that's not at issue here. We're talking
about cygwin.)

> likewise if we want
> sandboxes then porting layer/method specific library file names becomes
> mandatory.

Not necessarily, if the PATH settings (or insuring that all dll's and
exe's go into the same directory) are sufficient to prevent problems.  I
don't think so, personally.  As distasteful and painful as renaming all
the dll's is, it *may*, repeat *may*, be the best option.  I believe
Chris is proactively doing some research; it is possible that we can do
something else, and avoid the 'cyg' prefix -- like using the 'AppPath'
registry or something.

It's just that there is an ingrained desire to stay as unix-like as
possible -- and that means, libraries start with 'lib', not 'cyg'.  If
AppPath can fix the problem, then I'd prefer that cygwin's install.exe
set the appropriate registry entry whenever installing an executable. 
This won't catch *everything*, but dagnabbit, I'm tired of packages
installing themselves with cp (which break on cygwin thanks to the .exe
suffix).  They oughta use install.

> 
> Personally I think that a mingw32 libpng should be useable by cygwin gcc AND
> cygwin distributed binaries, given that they are the same version... (and
> that should be part of the naming convention).

Just cannot be done. Sorry.

--Chuck

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

RE: DLL naming conventions

[Bernard Dautrevaux]

> -----Original Message-----
> From: Robert Collins [ mailto:robert.collins@itdomain.com.au ]
> Sent: Monday, September 04, 2000 2:44 PM
> To: cygwin@sources.redhat.com
> Subject: Re: DLL naming conventions
> 
> 
> ...
> 
> > > However, no modeless users (except for Paul) have 
> complained.  Perhaps
> > > Paul should become modal. :-)
> >
> > The problem iw that when you say "modal" you are really 
> saying that we
> > should have several sandboxes and that a programm from 
> sandbox "cygwin"
> > could not play with (i.e. call) a program with sandbox "pw32" or
> "mingw32";
> > that was exactly what render the Win32 Posix subsystem so 
> inattractive: it
> > can't mix with win32.
> >
> > Here the situation would only be slightly better: it may 
> work by chance
> and
> > suddenly fall apart in the wrong place (i.e. I added 
> something to mingw32
> > sandbox, and then a program from the cygwin sandbox no more works,
> assuming
> > I need to call some mingw32 program from cygwin bash...)
> >
> > I *know* that having cygpng.dll instead of libpng.dll is a 
> bit of a burden
> > for cygwin maintainers, but defining the convention and 
> using it to all
> new
> > ports should prevent the problem to suddenly arise when 
> there will be more
> > conflict than the apparently isolated zlib problem.
> 
> but this also means that mingw32 program won't use the cygwin compiled
> libpng if it is there? is that acceptable?

Not only acceptable but usually needed, as the mingw32 program will use (for
example) MSVCRT version of free() to free some memory allocated by CYGWIN
version of malloc() called from cygwin-compiled libpng; all this will have
one more than probable result: SEGFAULT ;-(

> -> if we are looking to keep the sandbox's separate then 
> yes.. but why care
> about running a (say) mingw32 program from cygwin bash...

Because perhaps some program that is not GPLed nor GPLable was ported from
UNIX to NT and thus cannot be using cygwin...

BTW this mean there must be a way to ensure that a program not compiled for
cygwin will not by error link against cygwin1.dll through some other DLL or
that program will become GPLed without its author being aware of it!...
Hopefully the program will crash without doing anything meaningful I think
so that's not too bad :-)

> -> if we are looking to let things cross the sandbox we 
> should decide _what_
> things, (ie bin/pipes, bin/pipes/libs, binaries only..) we are able to
> support and then make it as flexable as possible.

Anything tha'ts natively supported on WIN32 for inter-process-communication
should be usable and is for now I think, at least starting programs,
reading/writing files, sockets and probably pipes. 

Libs on the opposite are usually NOT mixable between environments. (note
that it's not even possible to link a program using MSVCRT.DLL with a
library built against CRTLIB.DLL, even if they are both almost
source-compatible, and not even possible to mix various versions of
MSVCRT.DLL); so we should not only forget about mixing
native/cygwin/mingw32/PW libraries but I would even favor forbidding it.

The only thing that is needed is that low-level native WIN32 DLLs should be
accessible from all "sandboxes" but the reverse is usually not possible
because the C runtime environments will be incompatible. We have exactly the
same problem on Linux: any program can access the kernel, but a
libc5-compatible library cannot call code from a libc6-compatible one and
vice-versa.

> 
> I think we need to make that decide first, and then the rest 
> falls into
> place....
> 

Sure :-)

> if we want full cross over from the sandboxes then the answer 
> should permit
> only porting layer/method to use another libraries. So a port 
> layer/method
> specific library naming convention is not acceptable. 

I presume you say: suppressing any barrier between sandboxes (i.e. on Linux
should be between libc5 and libc6); I do not think this is even possible.

> likewise if we want
> sandboxes then porting layer/method specific library file 
> names becomes
> mandatory.

This would be what we get now under Linux: programs compiled under libc5 and
libc6 are able to work together freely, but not to share code.

> 
> Personally I think that a mingw32 libpng should be useable by 
> cygwin gcc AND
> cygwin distributed binaries, given that they are the same 
> version... (and
> that should be part of the naming convention).

This would only work if libpng makes NO calls to the C Runtime Library (that
is do NOT depend on MSVCRT.DLL or CRTDLL.DLL); otherwise the program will
just crash.

Cheers,

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

Re: DLL naming conventions

[Gary V. Vaughan]

On Sun, Sep 03, 2000 at 12:30:18PM -0400, Chris Faylor wrote:
> On Sun, Sep 03, 2000 at 01:27:12PM +0100, Gary V. Vaughan wrote:
> >
> ><rant>
> >Why not just statically link all of our applications?  Then we
> >wouldn't have any problems with wrong dlls being loaded at all!
> ></rant>
> 
> Are you ranting at me?  Don't bother.

No offence was intended.  I was mostly ranting on the capacity of
Microsoft to remove all the advantages of a system (shared libraries)
but still retain all the loops you have to jump through to use them.

> My major concern was naming every cygwin DLL "cygsomething.dll".  I
> really don't like that idea, especially since it will mean work for
> people at Red Hat to accomodate.

Chuck has talked sense into me here... I no longer think that this
buys us anything.

> I did see the AppPath registry key being mentioned.  I'm not sure how
> libtool could make use of that since that is something that is set on
> installation of a package.  libtool may be out of the picture at that
> point unless you're doing 'make install'.

Bummer =(O|  Does that mean binary packages would need to run a
post-install script to set the AppPath correctly then?  If it was a
boiler plate script, perhaps libtool could generate it if it notices
that the `make install' is moving things to a staging area (for
packaging) as opposed to moving things directly to the live
directories...

> This could be a solution for cygwin but I don't know if it addresses the
> problem of other packages or not.

Paul has shown willing to provide suitable patches for his system, and
I use only cygwin myself.  If I can improve the build system on just
cygwin I will be more than happy.

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

[Corinna Vinschen]

Robert Collins wrote:
> Personally I think that a mingw32 libpng should be useable by cygwin gcc AND
> cygwin distributed binaries, given that they are the same version... (and
> that should be part of the naming convention).

How do you want to overcome the problems in using common stuff,
say, stdio?

Libraries do use other libraries. Many libraries are depending on
libc calls for example. If you compile your lib for Mingw32 use,
your library will require msvcrt library for stdio stuff while
the same library compiled for Cygwin requires cygwin1 for the same
functions.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                        mailto:cygwin@sources.redhat.com
Red Hat, Inc.
mailto:vinschen@cygnus.com

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

Re: DLL naming conventions

[Robert Collins]

...

> > However, no modeless users (except for Paul) have complained.  Perhaps
> > Paul should become modal. :-)
>
> The problem iw that when you say "modal" you are really saying that we
> should have several sandboxes and that a programm from sandbox "cygwin"
> could not play with (i.e. call) a program with sandbox "pw32" or
"mingw32";
> that was exactly what render the Win32 Posix subsystem so inattractive: it
> can't mix with win32.
>
> Here the situation would only be slightly better: it may work by chance
and
> suddenly fall apart in the wrong place (i.e. I added something to mingw32
> sandbox, and then a program from the cygwin sandbox no more works,
assuming
> I need to call some mingw32 program from cygwin bash...)
>
> I *know* that having cygpng.dll instead of libpng.dll is a bit of a burden
> for cygwin maintainers, but defining the convention and using it to all
new
> ports should prevent the problem to suddenly arise when there will be more
> conflict than the apparently isolated zlib problem.

but this also means that mingw32 program won't use the cygwin compiled
libpng if it is there? is that acceptable?
-> if we are looking to keep the sandbox's separate then yes.. but why care
about running a (say) mingw32 program from cygwin bash...
-> if we are looking to let things cross the sandbox we should decide _what_
things, (ie bin/pipes, bin/pipes/libs, binaries only..) we are able to
support and then make it as flexable as possible.

I think we need to make that decide first, and then the rest falls into
place....

if we want full cross over from the sandboxes then the answer should permit
only porting layer/method to use another libraries. So a port layer/method
specific library naming convention is not acceptable. likewise if we want
sandboxes then porting layer/method specific library file names becomes
mandatory.

Personally I think that a mingw32 libpng should be useable by cygwin gcc AND
cygwin distributed binaries, given that they are the same version... (and
that should be part of the naming convention).


Rob


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

RE: DLL naming conventions

[Bernard Dautrevaux]

> -----Original Message-----
> From: Charles Wilson [ mailto:cwilson@ece.gatech.edu ]
> Sent: Sunday, September 03, 2000 8:00 AM
> To: cygwin@sources.redhat.com
> Cc: gvv@techie.com
> Subject: Re: DLL naming conventions
> 
> 
	<skipped>

> 
> Won't fix the problem for exe's that aren't part of the official
> install, but you can work around that by requiring that 
> /bin,/usr/bin be
> in the front of the path (prior to 'outside' dirs). Even this, though,
> will not fix the problem for 'modeless' users (Michael's 'user 2') --
> because modeless users don't want /usr/bin in the front.
> 
> However, no modeless users (except for Paul) have complained.  Perhaps
> Paul should become modal. :-)

The problem iw that when you say "modal" you are really saying that we
should have several sandboxes and that a programm from sandbox "cygwin"
could not play with (i.e. call) a program with sandbox "pw32" or "mingw32";
that was exactly what render the Win32 Posix subsystem so inattractive: it
can't mix with win32.

Here the situation would only be slightly better: it may work by chance and
suddenly fall apart in the wrong place (i.e. I added something to mingw32
sandbox, and then a program from the cygwin sandbox no more works, assuming
I need to call some mingw32 program from cygwin bash...)

I *know* that having cygpng.dll instead of libpng.dll is a bit of a burden
for cygwin maintainers, but defining the convention and using it to all new
ports should prevent the problem to suddenly arise when there will be more
conflict than the apparently isolated zlib problem.

The fact that only one complain was received does not mean that there is no
problem and that we should not try to avoid the problem to be come worse.
Then progressively one could start rename all libfoo.dll's as cyfoo.dll,
still providing libfoo.dll as an interim measure to let maintainers update
their ports (which should only require a recompile provided libfoo.dll.a now
reflects cyfoo.dll).

Otherwise I'm afraid that one day the list suddenly gets filled of complains
of people saying: "I've installed foo.x.y on cygwin-1.1.4 and gets a
segfault in libbar.dll when running foo" with answers like "Don't
understand; I also use foo.x.y on cygwin-1.1.4 and do not have any problem;
do you also install xchess?" and all the expected messages to finally
understand that the native mingw32 port of gnugo also installs a libbar.dll
that is incompatible with the one needed by foo.x.y and provided by cygwin
or some other package foo depends on.

> 
> > I love being as
> > close to UNIX as possible but if it is going to cause problems then
> > it makes sense not to do things that way.
> 
> Yep -- so libtool and dll versioning issues should be 
> addressed.  But it
> appears that the 'modal' PATH requirement is the least 
> intrusive method
> of fixing the platform-specific dll confusion (e.g. native vs. cygwin
> vs. UWin vs. PW dll's, all with the same name).
> 

I don't think so, as we must rely on the PATH and thus are NOT allowed to
have two different sandboxes in one PATH (not even perhaps the standard
WIN32 directories) as we may have conflicts. Right conflicts with WIN32
native DLLs is quite improbable but that's just because this fancy "lib"
prefix for cygwin dlls :-)

I think what was proposed here was just refining a bit this convention,
saying that "lib" should be avoided (by *everybody* IMNSHO) but replaced by
a short prefix that should try to be as unambiguous as possible (and if
possible 3-char-long to avoid breaking some habits and poorly written sed
scripts) like for example "cyg" for cygwin, "mgw" for mingw32, "pow" for
Paul's Powix-On-Windows layer and so on.

This would not be perfect and clashes will still be possible but at least
they will be a lot less likely.

As for the versioning I favor without any doubt versioning the DLLs for
incompatible ABI/API changes while the (needed) import library is
non-versioned. But I think the scheme is almost agreed upon, at least for
the future when ABI or API-incompatible versions of not-yet-versioned DLLs
will appear.

Regards,

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

Re: DLL naming conventions

[Alexandre Oliva]

On Sep  3, 2000, "Gary V. Vaughan" <gvv@techie.com> wrote:

>   * When installing a libtool (.la) library:
>       - libfoo.la goes to $prefix/lib
>       - libfoo<iface>.dll goes to $prefix/bin
>       - libfoo.dll.a goes to $prefix/lib
>       - libfoo.a goes to $prefix/lib
      
Nope.  libfoo.la goes wherever -rpath specified when the library was
created; it should be the same directory that is specified at install
time.  This is often $(libdir), but it doesn't have to be.

I don't know how to arrange for an additional directory (bindir) to
be specifiable without introducing an additional command-line option.
Remember, libtool doesn't know about prefix, libdir or bindir, it just
knows about what it's given in the command line.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


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

Re: DLL naming conventions

[Chris Faylor]

On Sun, Sep 03, 2000 at 12:30:18PM -0400, Chris Faylor wrote:
>I think it may be possible to have a dll that is loaded before most
>other dlls change the PATH so that something like /usr/lib is first in
>the path, removing the /usr/lib prior to execution of 'main()'.  We
>could, in fact, even add a front end to kernel32.dll which did this.
>
>This could be a solution for cygwin but I don't know if it addresses the
>problem of other packages or not.

Nevermind.  I've been doing more reading.  Load order != order of execution:

http://msdn.microsoft.com/library/periodic/period99/hood0999.htm

cgf

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

Re: DLL naming conventions

[Chris Faylor]

On Sun, Sep 03, 2000 at 01:27:12PM +0100, Gary V. Vaughan wrote:
>On Sat, Sep 02, 2000 at 10:19:15PM -0400, Chris Faylor wrote:
>> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
>> >> Since windows-dll
>> >> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
>> >> similar, you've got a problem.
>> >
>> >Most definitely.
>> 
>> It is *not* strictly based on the executable path.  It first searches
>> the current directory, then searches the directory containing the executable.
>> Most Windows packages rely on this and place the DLL with the executable.
>> That should solve the problem of finding the "wrong" dll.
>> 
>> I'm still kind of amazed by all of the furor this discussion is generating,
>> given that I don't think we have yet seen a single problem reported.
>> 
>> If this was a big deal I would have thought that there would be many many
>> plaintive wails in this mailing list.
>> 
>> If the solution to the problem is as simple as placing the DLL with the
>> executable then why the heck don't we just do that?  I love being as
>> close to UNIX as possible but if it is going to cause problems then
>> it makes sense not to do things that way.
>
><rant>
>Why not just statically link all of our applications?  Then we
>wouldn't have any problems with wrong dlls being loaded at all!
>
>Everyone agrees that shared libraries on Unix are a good idea, right?
>How come so many of us think that the best way to use shared libraries
>on Windows is to make them as much like static libraries as we can?
>The closest thing to a static library *is* a static library.  Lets get
>off the fence here.  If we want static libraries then fine, I'll shut
>up and go away.  If we want shared libraries, wouldn't it be cool to
>hammer out the easiest (from a man-hours effort point of view) way to
>take advantage of the benefits they can offer?
>
>The whole point of a shared library, is that it is shared by the
>applications that use it.  You can upgrade all of the applications
>that use it by updating the shared library.  You only need to have one
>copy in memory.
>
>Putting a copy of all the dll's used by each application into the
>directory the application loads from defeats the purpose.  I know dll's
>are sucky compared to ELF shared libraries, and that the windows
>runtime loader is sucky compared to ld.so.  But wouldn't it be nice to
>have some of the advantages shared libraries bring to Unix when we use
>cygwin?  I'm even offering to do most of the work by making all the
>libtool using packages (i.e. just about everything from gnu.org and a
>whole buch of other stuff too) conform to whatever scheme we agree
>will work the best.  I'll bet that if we converted the non-libtool
>packages that we port to an autoconf/automake/libtool build system,
>the upstream maintainers would incorporate the patch into the real
>version, and the next release would work on cygwin out of the box.
>Assuming we choose a good scheme for libtool built dlls on cygwin.
></rant>

Are you ranting at me?  Don't bother.

Chuck Wilson has adequately explained why "just put the DLL in
the same directory" isn't a perfect plan.

Regardless, I wasn't advocating putting each executable in its own
directory with a DLL.

My major concern was naming every cygwin DLL "cygsomething.dll".  I
really don't like that idea, especially since it will mean work for
people at Red Hat to accomodate.

If you have a plan that doesn't require changing the name of libz.dll to
something like cyglibz.dll then I have no objections.

I did see the AppPath registry key being mentioned.  I'm not sure how
libtool could make use of that since that is something that is set on
installation of a package.  libtool may be out of the picture at that
point unless you're doing 'make install'.

I think it may be possible to have a dll that is loaded before most
other dlls change the PATH so that something like /usr/lib is first in
the path, removing the /usr/lib prior to execution of 'main()'.  We
could, in fact, even add a front end to kernel32.dll which did this.

This could be a solution for cygwin but I don't know if it addresses the
problem of other packages or not.

cgf

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

Re: DLL naming conventions

[Gary V. Vaughan]

On Sat, Sep 02, 2000 at 10:19:15PM -0400, Chris Faylor wrote:
> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
> >> Since windows-dll
> >> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
> >> similar, you've got a problem.
> >
> >Most definitely.
> 
> It is *not* strictly based on the executable path.  It first searches
> the current directory, then searches the directory containing the executable.
> Most Windows packages rely on this and place the DLL with the executable.
> That should solve the problem of finding the "wrong" dll.
> 
> I'm still kind of amazed by all of the furor this discussion is generating,
> given that I don't think we have yet seen a single problem reported.
> 
> If this was a big deal I would have thought that there would be many many
> plaintive wails in this mailing list.
> 
> If the solution to the problem is as simple as placing the DLL with the
> executable then why the heck don't we just do that?  I love being as
> close to UNIX as possible but if it is going to cause problems then
> it makes sense not to do things that way.

<rant>
Why not just statically link all of our applications?  Then we
wouldn't have any problems with wrong dlls being loaded at all!

Everyone agrees that shared libraries on Unix are a good idea, right?
How come so many of us think that the best way to use shared libraries
on Windows is to make them as much like static libraries as we can?
The closest thing to a static library *is* a static library.  Lets get
off the fence here.  If we want static libraries then fine, I'll shut
up and go away.  If we want shared libraries, wouldn't it be cool to
hammer out the easiest (from a man-hours effort point of view) way to
take advantage of the benefits they can offer?

The whole point of a shared library, is that it is shared by the
applications that use it.  You can upgrade all of the applications
that use it by updating the shared library.  You only need to have one
copy in memory.

Putting a copy of all the dll's used by each application into the
directory the application loads from defeats the purpose.  I know dll's
are sucky compared to ELF shared libraries, and that the windows
runtime loader is sucky compared to ld.so.  But wouldn't it be nice to
have some of the advantages shared libraries bring to Unix when we use
cygwin?  I'm even offering to do most of the work by making all the
libtool using packages (i.e. just about everything from gnu.org and a
whole buch of other stuff too) conform to whatever scheme we agree
will work the best.  I'll bet that if we converted the non-libtool
packages that we port to an autoconf/automake/libtool build system,
the upstream maintainers would incorporate the patch into the real
version, and the next release would work on cygwin out of the box.
Assuming we choose a good scheme for libtool built dlls on cygwin.
</rant>

Cheers,
	Grumpy^H^H^H^H^H^HGary =)O|
-- 
  ___              _   ___   __              _         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

[Gary V. Vaughan]

On Sun, Sep 03, 2000 at 01:34:23AM -0400, Charles Wilson wrote:
> "Gary V. Vaughan" wrote:
> 
> > > Now, suppose that the png folks release a newer version, say png-2.1.x
> > > that exposes some additional features, but is backwards compatible with
> > > png-2.0.x.  Great.  You build it, but create:
> > >
> > >   libpng31.dll.a (embeds the name libpng31.dll.a)
> > >   libpng.dll.a -> libpng31.dll.a
> > >   libpng3.dll (replaces the old version (*))
> > 
> > I don't think we need anything more than
> > 
> >     a replacement libpng3.dll
> 
> Not so.  Remember, libpng-2.1.x can include additional functions that
> were not included by libpng-2.0.x, as long as it includes all of the
> 'old' functions/vars without modification.  So, you need to update the
> import lib as well as the dll, so that new packages that use the
> additional functions will work.

Oops.  I hadn't thought of that.  Good point.

> > Otherwise we are still in violent agreement.
> 
> I agree.

=)O|

> > > > Maybe Cygwin should put all of it's libtool built libraries (or any
> > > > others that are correctly versioned w.r.t the runtime loader) into a
> > > > single directory that is near the front of the default path.  /usr/lib
> > > > seems like a good place.
> > >
> > > That's part of my 'easy' solution above.  It may fix the cygwin problem,
> > > but the requirement is not nice to native apps or other unix-on-win
> > > emulations that the user may have.
> > >
> > > Relying on 'get dll's from same dir as .exe' works -- but only if EVERY
> > > cygwin exe and EVERY cygwin dll are piled into the same dir.
> > 
> > Can't we assume that the native dll's we rely on are outside cygwin's
> > control and can be relied upon to be managed by the operating system
> > (I'm thinking of stuff in the SYSTEM directory), and that non-cygwin
> > libraries (such as Pauls pw dlls) will not be installed into the
> > cygwin binary search path?  In which case I think it is okay to
> > install all cygwin dlls and import libs to /usr/lib, making sure that
> > cygwin.bat (or any other cygwin startup methods) put /usr/lib first in
> > $PATH.  
> 
> this works for the 'sandbox user' -- Michael Ring's 'user 1' in this
> message:
>    http://sources.redhat.com/ml/cygwin/2000-08/msg01241.html
> 
> It doesn't work for Michael's 'user 2' -- the guy who normally runs in
> cmd.exe/command.com, but relies on cygwin commands every once in a
> while.  He doesn't use bash, but likes the cygwin-perl or grep every
> once and a while.  User 2 will have the cygwin directories somewhere in
> her path -- but not necessarily first.

We could tell these people to put C:/cygwin/usr/bin at the front of
their PATH...

> > Does cygwin ld use -rpath yet?  
> 
> I don't think so.  -rpath is something that ld.so uses; Windows doesn't
> have ld.so. Windows *always* loads dll's according to the following
> search order:
>    current directory
>    app's load directory
>    global executable search path
> 
> The only two exceptions I know of are:
> 
>   1) In Win2K, if there is a file called 'app.exe.local' in the same
> directory as app.exe, then all dll's will be loaded from the app's load
> directory -- even if explicitly dlopened() with an absolute path that
> points elsewhere.  the .local. may also override the 'current directory'
> part of the search order listed above, but I'm not sure.

Holy cr@p! What happened to simplicity?  If Bill has decided that he
can't understand how to write a decent shared library system, and
want's to relegate dll's to LoadLibrary() objects, why doesn't he just
say so?  Wouldn't it be easier to statically link a Win2k program that
twiddle about with all this .local mess?

>   2) You can put something called 'AppPath' in the registry, which will
> influence the directories that are searched. I don't know where in the
> list above that the directories listed in the 'AppPath' key are
> inserted.

This sounds promising.  I'll see if I can find any details on it.

> > I am prepared to work on having libtool do the right thing as far
> > as possible. 
> 
> What was the right thing, again?  :-)

Based on our conversation so far:

  * When building a libtool (.la) library, create libfoo.la,
    libfoo<iface>.dll, libfoo.dll.a and libfoo.a, where:
      - <iface> is the earliest fully supported interface number
      - libfoo.dll.a is the import library for libfoo<iface>.dll
      
  * When installing a libtool (.la) library:
      - libfoo.la goes to $prefix/lib
      - libfoo<iface>.dll goes to $prefix/bin
      - libfoo.dll.a goes to $prefix/lib
      - libfoo.a goes to $prefix/lib
      
  * When linking against libfoo.la
      - use libfoo.dll.a unless -static or -all-static 
      - otherwise use libfoo.a

  * When linking against -lfoo
      - if libfoo.la is found, behave as above
      - else let ld (or gcc) do its thing

Which is especially cool, because I don't think I need to worry about
dealing with direct linkage to dlls (I can just punt and let gcc/ld do
the hard work) which removes a whole pile of spaghetti where I had to
cope with compiling the impgen code correctly in cross compilation
environments!

> > By default libtool always searches for a dll to link against and
> > generates the implib on the fly if a suitable one is found.

This won't be necessary under the new scheme =)O|

> There are occaisions where you want to link to an import lib in
> preference to a dll -- for instance, libcygwin.a is an import lib, but
> contains initializer code and actual function implementations for some
> functions that are not included in the dll itself.  If you attempt to
> link directly to cygwin1.dll, the link fails because those things are
> missing from the virtual on-the-fly implib.

I didn't know about that.  Thanks.

> But where do you put the dll?  It has to go into the executable PATH so
> that the windows loader can find it.  Do you copy it into /usr/lib, so
> that the default ld search path will find it?  Do you add /usr/bin to
> the linktime library search path (-L/usr/bin)?  Perhaps a symlink in
> /usr/lib, pointing to /usr/bin/libfoo.dll is all you need. 
> 
> However!!! Ld uses the following library name search order when hunting
> for -lfoo:
> 
>   libfoo.dll.a
>   foo.dll.a
>   libfoo.a  <<<< NOTE!!
>   libfoo.dll
>   foo.dll

Or that.  Thanks again!  Libtool already provides --disable-static if
the user wants to build and install only the dll parts of the library.

For this to work (that is, in order for me to be able to punt to gcc/ld
in the majority of cases) I must generate dll names that will be
found, so the cygfoo.dll idea is out (Sorry Paul!).

Although this doesn't help ``User 2'' very much, he is no worse off
than before if I change libtool's behaviour in this way.  Here's a
thought:  For each dll using application linked, I could have libtool
install a .bat script to C:/cygwin/launch (or similar) which would set
the PATH environment correctly for that application.  As long as
``User 2'' has the launch directory higher in his PATH than the actual
binary directory, this would guarantee correct dll selection.

This would give ``User 1'' many of the advantages shared libraries
offer on Unix, without sinking into DLL Hell.  Assuming that everyone
buys into it.  The only reason shared libraries work properly on Unix
is that everyone has to agree to conform to the runtime loader's
versioning scheme -- so don't give some excuse about ``if we don't
want to change the core cygwin dll's to conform this won't work''.  On
my linux box, I can move my libc around or drop several incompatible
versions of libc into my filesystem, and my applications will stop
loading the intended libraries too.  No surprises there!

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]

Chris Faylor wrote:
> 
> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
> >> Since windows-dll
> >> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
> >> similar, you've got a problem.
> >
> >Most definitely.
> 
> It is *not* strictly based on the executable path.  It first searches
> the current directory, then searches the directory containing the executable.
> Most Windows packages rely on this and place the DLL with the executable.
> That should solve the problem of finding the "wrong" dll.

Again, ONLY if ALL cygwin exec's go into /usr/bin, along with ALL cygwin
dlls.  But what of the locally-compiled rxvt, that depends on (say) the
libXpm.dll, where libXpm.dll is part of official package
'libXpm-3.4k-2.tar.gz' in /cygwin/contrib?

Poor little rxvt.exe goes into /usr/local/bin, and will have to rely on
the good offices of Windows to locate libXpm.dll in the search path. 

Or, what of perl.exe, which depends on:
  libdb.dll
  libgdbm.dll
  libz.dll (actually, module Compress:Zlib)
which are all part of the official distro, so they live in /usr/bin. 
But, perl is not official -- it lives in /usr/local/bin.  To insure that
the 'right' libz.dll gets loaded (and I've got two on my machine -- one
cygwin, one native), I have to insure that D:\cygwin\usr\bin precedes
D:\Utils in the global path.   

That's okay, when I run cygwin in a sandbox (Michael's 'User 1') which
is my normal mode of operation.  However, User 2, who only occaisionally
calls cygwin exe's from a normal command prompt (no bash, so can't set
PATH specially for Cygwin in his .bashrc) -- he might have D:\Utils
precede D:\cygwin\usr\bin.

The odds of this occurring are, admittedly, rather low.  If the goal is
to pre-emtively prevent these confusing failures, in the hopes of
lightening the support load on the cygwin mailing list -- we've already
failed! :-) We've already spent far more time discussing this
hypothetical problem that it would take to tell one hundred newbies:
"Put /usr/bin in the front of your path".

> 
> I'm still kind of amazed by all of the furor this discussion is generating,
> given that I don't think we have yet seen a single problem reported.

Two issues have been intermingled -- (1) the 'cyg' prefix/runtime
loading "problem", and (2) the library versioning problem.  Granted, (1)
is very low probability -- see my arguments below.  (2) has not yet bit
us, because most contrib libraries have been dll-ized by me, and each
successive version of the dlls have been interface-compatible, so no
explicit versioning has been necessary. It will become necessary
eventually -- might as well discuss it now.

So, two fairly controversial topics have been co-mingled -- and
sometimes confused with each other -- so we've got 'furor'.

I did observe the dll-runtime loading problem, when I built a native
XEmacs that depended on native libz, libpng, and libtiff dll's.  My path
had /usr/bin first, so I got the cygwin libz.dll etc at runtime, and
XEmacs failed.

There were two possible fixed -- AND NEITHER ONE required cygwin
changes: relink my native XEmacs statically, or copy the native dll's
into D:\Program Files\XEmacs\xemacs-21.2.25\i386-pc-win32\  where the
xemacs.exe was.

> 
> If this was a big deal I would have thought that there would be many many
> plaintive wails in this mailing list.
> 

You are correct, as usual, Chris. This is a low-probability error --
UNLESS one has multiple unix-on-windows emulators installed.  Like Paul
Sokolovsky, who apparently has both cygwin and PW.

I dunno if it's worth this much effort and discussion to fix a problem
that happens so rarely, and is fixable by less intrusive means:  
  when operating in PW mode, set your PATH so that the PW /bin,/usr/bin
is first
  when operating in Cygwin mode, set your PATH so that the cygwin
/bin,/usr/bin is first.

> If the solution to the problem is as simple as placing the DLL with the
> executable then why the heck don't we just do that? 

Won't fix the problem for exe's that aren't part of the official
install, but you can work around that by requiring that /bin,/usr/bin be
in the front of the path (prior to 'outside' dirs). Even this, though,
will not fix the problem for 'modeless' users (Michael's 'user 2') --
because modeless users don't want /usr/bin in the front.

However, no modeless users (except for Paul) have complained.  Perhaps
Paul should become modal. :-)

> I love being as
> close to UNIX as possible but if it is going to cause problems then
> it makes sense not to do things that way.

Yep -- so libtool and dll versioning issues should be addressed.  But it
appears that the 'modal' PATH requirement is the least intrusive method
of fixing the platform-specific dll confusion (e.g. native vs. cygwin
vs. UWin vs. PW dll's, all with the same name).

--Chuck

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

Re: DLL naming conventions

[Charles Wilson]

"Gary V. Vaughan" wrote:
> >
> > Also, there are two separate issues being discussed here: (1) how to
> > (compile-time) link against the 'right' version of a library, and (2)
> > how to insure that the 'right' dll is loaded at run-time.
> 
> Nah.  I'm talking about (2) only.  I *am* assuming that at link time
> the only version of a library you can link with is the one that
> corresponds with the header files you have installed.

Okay. I was just going by the example from
http://www.debian.org/Lists-Archives/lsb-spec-9905/msg00011.html , quoted
here:

-------------------
> The development links become a bit more complex. The temptation is to
> place both development sets in their own subdirectories, providing:
> 
>      /usr/include/gmp1
> and
>      /usr/include/gmp2
> 
> and the development symlinks:
> 
>      libgmp1.so
> and
>      libgmp2.so
> 
> This causes problems for packages which expect to build against gmp.
> Having to edit the make file to reflect the correct include and link names
> is not a clean solution.
> 
> Thus, for gmp-2.0.2, the includes are provided in /usr/include, and the
> development link is libgmp.so. Only gmp1 need be placed in the special
> locations above.
--------------------

But, you are right. The extra linktime libaries are only necessary if
you also have the extra header files in a special directory.  Since you
have to edit the makefiles (and possible the source code) for 'package
X' that depends on the old interface (gmp1 in this example), then you
might as well specify '-lgmp1' and you don't need the symlinks.

<snip>
 
> > Since windows-dll
> > loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
> > similar, you've got a problem.
> 
> Most definitely.

Chris argues against this in his other message. I'll reply to that point
in a separt message.

> 
> > It would be nice if you could create a 'cygwin LD_LIBARY_PATH' and a 'PW
> > LD_LIBRARY_PATH' etc.  But that probably requires that you abandon dll's
> > altogether, create your own 'so' file format, write an ld.so (ld.dll?)
> > that will load .so's 'just like unix (tm)'.  And, for this to work
> > cleanly, such a beast would have to be written for ALL the major unix
> > emulation environments.  However, we're just concerned with cygwin,
> > here.  (I can't take credit for this idea; both Tor Lillqvist and Chris
> > Faylor have on occaision mentioned something similar)
> 
> In an ideal world.  I'd be surprised if anyone is keen enough to
> actually write it though.  Far more likely that we can find the time
> to make incremental improvements and adopt some conventions that make
> things work a bit better...

I think the ld.so stuff is very ambitious. IMO, it's something to keep
in mind for the next major revision of cygwin -- but then, I'm not an
official spokesman.

Again, IMO, 'adopting some conventions' is the way to go right now --
just like we adopted the convention that 'libfoo.dll.a' means an import
lib.

<snip>

> > You can (mostly) fix point (1: compiletime version) by careful naming
> > and use of import libs + careful naming and use of dll's.
> >
> > For instance:
> >
> >   libpng.dll.a  --> libpng3.dll.a
> >                 ^^
> >               symlink
> >
> >   libpng30.dll.a  (most recent API, corresponds to png-2.0.x)
> >     embeds the name "libpng3.dll"
> >   libpng20.dll.a  (older API, corresponds to png-1.0.x)
> >     embeds the name "libpng2.dll"
> >
> > Programs linked against '-lpng' will be dependent at runtime on
> > libpng3.dll. Programs linked against -lpng2 (or against '-lpng' before
> > version 2.0.x was installed -- e.g. when libpng.dll.a --> libpng2.dll.a)
> > will be dependent at runtime on libpng2.dll
> 
> Why bother with the symlinks?  You can't link against -lpng2 unless
> you have matching headers, and presumably you upgraded those when you
> installed libpng3.dll.
> 
> My proposal was to start with this:
> 
>     libpng.dll.a embeds libpng2.dll
> 
>     and we keep libpng1.dll around for the applications that were
>     linked against interface 1.
> 
> when we install png-2.0, which implements a new interface that is not
> compatible with libpng2.dll, we install:
> 
>     a replacement libpng.dll.a that embeds libpng3.dll
>     libpng3.dll
> 
>     and we keep libpng2.dll around for the applications that were
>     linked against interface 2.
> 
>     and we keep libpng1.dll around for the applications that were
>     linked against interface 1.

You are (mostly) right. The symlinks are not really necessary -- but
keeping libpng20.dll.a is a good idea (assuming you also kept the 2.0.x
headers around, and put them in /usr/include/png2/.  

The symlink buys you ease of installation for the implib.  Suppose you
had 1.0.x installed, so libpng.dll.a embeds libpng2.dll.  Then, you
install 2.0.x.  First, you need to rename libpng.dll.a to libpng2.dll.a,
and then install the new implib as libpng.dll.a.  With symlinks, none of
that is necessary -- just install the new implib as libpng30.dll.a and
replace the existing symlink with one that points to the new implib.
Easy.

BUT -- you still need smarts create the appropriate /usr/include/png2/
directory, move the header files into it, and then install the new
headers into /usr/include.

Yuck yuck and double yuck. Okay, forget the symlinks -- they help with
the implibs, but nothin' helps with the header files.

The "Right Thing To Do", if you want development stuff (compile time
headers, link time import libs) for multiple incompatible versions of a
lib, is for the maintainer (the cygwin person who maintains the port of
a particular package, on sourceware -- for libpng, me) to do the
following:

 Oh, look: libpng-2.0.x is out.  That's not compatible with
libpng-1.0.x.  I need to create a new libpng-1.0.x package that installs
thusly:
  /usr/include/png2/*.h
  /usr/bin/libpng2.dll
  /usr/lib/libpng2.dll.a (libpng20.dll.a?)

Then, I can create a new libpng-2.0.x package that installs like so:
  /usr/include/*.h
  /usr/bin/libpng3.dll
  /usr/lib/libpng3.dll.a (libpng30.dll.a?)

And tell folks to install both the updated 1.0.x package and the new
2.0.x package.  Just like you see done in the linux distributions:
especially gmp1 and gmp2.

> 
> > Now, suppose that the png folks release a newer version, say png-2.1.x
> > that exposes some additional features, but is backwards compatible with
> > png-2.0.x.  Great.  You build it, but create:
> >
> >   libpng31.dll.a (embeds the name libpng31.dll.a)
> >   libpng.dll.a -> libpng31.dll.a
> >   libpng3.dll (replaces the old version (*))
> 
> I don't think we need anything more than
> 
>     a replacement libpng3.dll

Not so.  Remember, libpng-2.1.x can include additional functions that
were not included by libpng-2.0.x, as long as it includes all of the
'old' functions/vars without modification.  So, you need to update the
import lib as well as the dll, so that new packages that use the
additional functions will work.

> 
> now applications that were linked against the libpng3.dll from png-2.0
> will pick up the bugfixes from png-2.1, but new application can be
> written for the header files installed with png-2.1 and take advantage
> of the new features.

Unless you link directly against the dll (and don't use the import lib)
this new application won't link -- because the new features (additional
functions) added in the new version of the png library won't be exposed
by the old implib.

> 
> > Now, /usr/lib contains:
> >   libpng.dll.a -> libpng31.dll.a
> >   libpng31.dll.a
> >   libpng30.dll.a
> >   libpng20.dll.a
> > and /usr/bin contains:
> >   libpng3.dll
> >   libpng2.dll
> >
> > (*) you can't play simlink games with the dll's themselves, because the
> > windows loader doesn't grok cygwin's symlinks.  You *can* play simlink
> > games, as I've shown here, with the import libs, because the cygwin ld
> > and cygwin gcc do grok symlinks.
> >
> > This scheme will work without the help of libtool (e.g. you can still
> > build & link dependent packages without being *forced* to use libtool)
> > but it's similar enough to the 'unix way' that libtool should be able to
> > handle it.
> 
> Except that I think you have an extra level of indirection that we can
> safely do away with.  Otherwise we are still in violent agreement.

I agree. The symlinks are unnecessary, because of the difficulties
imposed by keeping track of the header files for the old version.  You
just need to create a new package for the old library, that relocates
and renames the implib and headers appropriately.  

> 
> > > Libtool doesn't version dll's on Windows correctly right now, it uses
> > > the linux versioning scheme to calculate the numbers.  It should
> > > probably name them after the oldest ``interface'' (see the document
> > > quoted above) that the library fully supports.  That is, if you build
> > > a dll using libtool's --version 5:4:3, you would get library2.dll
> >                                                        ^^^^^^^^^^^^
> >                    I think you mean library3.dll (supports v5, v4, & v3)
> 
> Nope.  5:4:3 is revision 4 of the implementation of interface 5, which
> is backwards compatible with the 3 previous interface definitions
> (i.e. it is safe for applications linked against interfaces 5, 4, 3
> and 2 to load the 5:4:3 dll at runtime).   Libtool translates the
> 5:4:3 into a system specific version number for the soname to help the
> runtime loadee choose the best available library at runtime.  As I
> said before, currently this mapping is wrong on Windows, and I think
> the correct mapping is to always use the oldest supported interface
> number -- in this case library2.dll -- when generating the soname.
> This is explained fully in the version node of the libtool manual link
> that was quoted earlier in the thread.

Doh!  0-based numbering. Not 1-based numbering.

> 
> > > (this version is at interface 5, but fully supports the last 3
> > > interfaces).  This gives the windows loader the best chance of finding
> > > the newest binary compatible dll.
> >
> > In my scheme, --version 5:4:3 will give you library3.dll (assuming my
> > correction above is right), but you'd also get:
> >
> >  library.dll.a --> library5.dll.a
> >  library5.dll.a (embeds the name library2.dll)
> >
> > And these are still hanging around from previous builds
> >  library4.dll.a (embeds the name library2.dll)
> >  library3.dll.a (embeds the name library2.dll)
> >  library2.dll.a (embeds the name library1.dll)
> >  library1.dll
> 
> Okay we're diverging a little here.  I think that all you need is
> library.dll.a, which always embeds the name of the dll that matches
> the header files you have installed right now.  The point about
> library1.dll and library2.dll is spot on though.

You are correct, unless one also installs the appropriate header files
in 
  /usr/include/library4/
  /usr/include/library3/
  /usr/include/library2/

> 
> > > Unfortunately Windows makes no distinction between the application
> > > search path and the library search path, so the scheme I propose is
> > > still flawed =(O|  You might have a newer bugfixed binary compatible
> > > version of the dll you need, but if it is further down the application
> > > search path than the buggy version you originally linked with, you get
> > > the broken version.  Nice one Bill...
> >
> > Yeah, but you're still assuming that the link lib and the runtime lib
> > are the same file.
> 
> Nope.  If we maintain the versions of library.dll according to either
> of our schemes (which are broadly the same), it all breaks down if
> some bozo installs a library2.dll in a location higher up our
> *application* search path that the directory we are using, since our
> applications will load their dll instead.  Maybe ours is the
> library5.dll.a version with 2 releases worth of bugfixes and
> enhancements over their library3.dll.a version they installed.

This is true.

> 
> > > Maybe Cygwin should put all of it's libtool built libraries (or any
> > > others that are correctly versioned w.r.t the runtime loader) into a
> > > single directory that is near the front of the default path.  /usr/lib
> > > seems like a good place.
> >
> > That's part of my 'easy' solution above.  It may fix the cygwin problem,
> > but the requirement is not nice to native apps or other unix-on-win
> > emulations that the user may have.
> >
> > Relying on 'get dll's from same dir as .exe' works -- but only if EVERY
> > cygwin exe and EVERY cygwin dll are piled into the same dir.
> 
> Can't we assume that the native dll's we rely on are outside cygwin's
> control and can be relied upon to be managed by the operating system
> (I'm thinking of stuff in the SYSTEM directory), and that non-cygwin
> libraries (such as Pauls pw dlls) will not be installed into the
> cygwin binary search path?  In which case I think it is okay to
> install all cygwin dlls and import libs to /usr/lib, making sure that
> cygwin.bat (or any other cygwin startup methods) put /usr/lib first in
> $PATH.  

this works for the 'sandbox user' -- Michael Ring's 'user 1' in this
message:
   http://sources.redhat.com/ml/cygwin/2000-08/msg01241.html

It doesn't work for Michael's 'user 2' -- the guy who normally runs in
cmd.exe/command.com, but relies on cygwin commands every once in a
while.  He doesn't use bash, but likes the cygwin-perl or grep every
once and a while.  User 2 will have the cygwin directories somewhere in
her path -- but not necessarily first.

> Does cygwin ld use -rpath yet?  

I don't think so.  -rpath is something that ld.so uses; Windows doesn't
have ld.so. Windows *always* loads dll's according to the following
search order:
   current directory
   app's load directory
   global executable search path

The only two exceptions I know of are:

  1) In Win2K, if there is a file called 'app.exe.local' in the same
directory as app.exe, then all dll's will be loaded from the app's load
directory -- even if explicitly dlopened() with an absolute path that
points elsewhere.  the .local. may also override the 'current directory'
part of the search order listed above, but I'm not sure.

  2) You can put something called 'AppPath' in the registry, which will
influence the directories that are searched. I don't know where in the
list above that the directories listed in the 'AppPath' key are
inserted.

> If so we could encode
> /usr/lib into each application as the first place to *always* look
> when searching for a dll. (I guess I am asking whether the Windows
> runtime loader will honor whatever rpath directory cygwin ld may
> encode into an application -- as happens with all of the Unix ports of
> libtool).

Nope. Don't think so.  That's why the suggestion to implement an
ld.so-like loader specifically for cygwin is an attractive, but
extremely difficult, option.

> 
> > I *think* the combination of implib/dll versioning described above, plus
> > (sigh) unique prefixes for different platforms -- e.g. 'cygfoo.dll' --
> > will solve most of the problems brought up w.r.t compiletime/linktime
> > versioning, and runtime loading.  Without interfering too much with
> > native apps or other unix-emul packages.  So what do you lose?
> >
> > -1) Can't link directly to a dll; you must use an import lib.  (why? #1,
> > ld only hunts for libfoo.dll & foo.dll, not cygfoo.dll. #2, if you link
> > directly to dll's without using import libs, you lose the clean
> > separation between 'runtime links' and 'development links' -- see
> > http://www.debian.org/Lists-Archives/lsb-spec-9905/msg00011.html .  I
> > know, there aren't really any 'runtime' symlinks, but at least you can
> > separate the major so-names...)
> 
> The cygfoo point is well taken.  I'm not sure I would accept that
> patch anymore...  infact I think that it is not a necessary part of
> this proposal (either of our proposals infact) if we have some way to
> control the runtime dll search path (by always putting /usr/lib first
> in the PATH for example).

Again, works for Michael's 'user 1', but not for 'user 2'.  And there
are a lot of 'user 2's out there.

> 
> > -2) It's a helluva lot of work to change everything on a platform (say,
> > cygwin) so that all dll's start with 'cyg' instead of 'lib'
> 
> This may be a non issue if you agree with my last paragraph.
> 
> > -3) It mostly solves a lot of the issues, but not completely. Not
> > ideally. Not perfectly.
> 
> Hey.  This is Windows we're talking about =)O|
> 
> > -4) Still requires significant changes to libtool to handle dll's and
> > importlibs.
> 
> Not that significant.  And this is all stuff that is on libtool's TODO
> list anyway.  It will get done eventually, just as soon as we can nail
> down a proposal that everyone (well most of us at least) likes.
> 
> > What do you gain?
> >
> > +1) mostly solves the problem
> > +2) you can still link dynamically or statically, without the use of
> > libtool if you so choose
> 
> That is important, and I am prepared to accept a patch (nay, write a
> patch in the fullness of time) to have libtool deal with import libs
> properly.
> 
> > +3) you don't have to develop an ld.so 'smart' runtime loader
> >
> > Is +3) a bigger win than work involved in -2) ?
> 
> I think so.  Unless someone steps up to the plate and offers to
> implement an ld.so-a-like, I am prepared to work on having libtool do
> the right thing as far as possible.

I think libtool should do the right thing anyway; even if an ld.so-clone
is proposed and work begins, it'll be a LONNNGGG time before a beast
like that is ready for prime time.

What was the right thing, again?  :-)

> 
> > Will Chris, DJ, Corinna, et. al. even go for -2) ?
> 
> Guys?  Stop me now if you violently disagree with libtool taking this
> direction =)O|
> 
> > Developing an ld.so runtime loader requires far fewer changes to
> > libtool, and since you *can* link directly to dll's (*) it'll work 'just
> > like unix (tm). But developing ld.so will be a tough job.
> >
> > (*) DJ has pushed a feature into ld that generates a 'virtual' import
> > lib on-the-fly if you put a dll in the link line.
> 
> Yup. I picked his brains while he was doing it, and wrote something
> similar for libtool.  By default libtool always searches for a dll to
> link against and generates the implib on the fly if a suitable one is
> found.

There are occaisions where you want to link to an import lib in
preference to a dll -- for instance, libcygwin.a is an import lib, but
contains initializer code and actual function implementations for some
functions that are not included in the dll itself.  If you attempt to
link directly to cygwin1.dll, the link fails because those things are
missing from the virtual on-the-fly implib.

These cases are rare.

It's possible that we can do away completely with import libs for most
libraries: based on my tests, all of the following four scenarios work:

libfoo.dll & libfoo.dll.a compiled with __declspec(dllexport)
decorations on all functions and data
use-libfoo.o compiled with __declspec(dllimport) decorations on all
functions and data

link use-libfoo.o to libpfoo.dll.a
  -- generates a working executable

link use-libfoo.o to libfoo.dll
  -- generates a working executable

libfoo.dll & libfoo.dll.a compiled with __declspec(dllexport)
decorations *ONLY* on data, not functions
use-libfoo.o compiled with __declspec(dllimport) decorations *ONLY* on
data, not functions

link use-libfoo.o to libpfoo.dll.a
  -- generates a working executable

link use-libfoo.o to libfoo.dll
  -- generates a working executable

So, it seems that there is no case in which the import lib gives you
better behavior than the dll itself.

But where do you put the dll?  It has to go into the executable PATH so
that the windows loader can find it.  Do you copy it into /usr/lib, so
that the default ld search path will find it?  Do you add /usr/bin to
the linktime library search path (-L/usr/bin)?  Perhaps a symlink in
/usr/lib, pointing to /usr/bin/libfoo.dll is all you need. 

However!!! Ld uses the following library name search order when hunting
for -lfoo:

  libfoo.dll.a
  foo.dll.a
  libfoo.a  <<<< NOTE!!
  libfoo.dll
  foo.dll

So, if both the static lib (libfoo.a) and the symlink/copy of the dll
(libfoo.dll) exist in /usr/lib, the link will grab the static lib in
preference to linking directly to the dll.  (this was a necessary
compromise for backwards compatibility; if libfoo.dll can override
libfoo.a, many things break. Don't go there).  Therefore, in order for
dynamic linking to take precedence over static linking, you have to have
an import lib in /usr/lib, not the dll.  Naturally, since libtool is
smart, it could explicitly link the dll in preference to the static lib
by listing the actual pathname of the library on the link line, instead
of relying on '-lfoo', but I thought we're trying to come up with a
solution that allows both libtool-ization and normal, unassisted
compiles.

Therefore:
  /usr/lib/libfoo.dll.a
  /usr/lib/libfoo.a
  /usr/bin/libfoo.dll  (maybe libfoo3.dll, whatever)

--Chuck

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

Re: DLL naming conventions

[Robert Collins]

I have only 1 concern with putting the .dll's in the same directory as an
application that needs them... you have to copy n instances of an updated
.dll to upgrade a library.

i.e. if you have gnome, and gtk+ is updated you have to copy the new .dll to
5-10+locations, depending on the number of applications you have...

Does anyone know exactly where the registry DLL location list goes in the
dll search order? Or does the application have to use it?

That might offer an alternative search mechanism we could place in
cygwin(and yes I'd be happy to put some time into writing it - although with
no guarantees about time-frame), without writing a brand-new run-time
loader...

Rob

----- Original Message -----
From: "Chris Faylor" <cgf@cygnus.com>
To: <cygwin@sources.redhat.com>
Cc: <gvv@techie.com>
Sent: Sunday, September 03, 2000 1:19 PM
Subject: Re: DLL naming conventions


> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
> >> Since windows-dll
> >> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
> >> similar, you've got a problem.
> >
> >Most definitely.
>
> It is *not* strictly based on the executable path.  It first searches
> the current directory, then searches the directory containing the
executable.
> Most Windows packages rely on this and place the DLL with the executable.
> That should solve the problem of finding the "wrong" dll.
>
> I'm still kind of amazed by all of the furor this discussion is
generating,
> given that I don't think we have yet seen a single problem reported.
>
> If this was a big deal I would have thought that there would be many many
> plaintive wails in this mailing list.
>
> If the solution to the problem is as simple as placing the DLL with the
> executable then why the heck don't we just do that?  I love being as
> close to UNIX as possible but if it is going to cause problems then
> it makes sense not to do things that way.
>
> cgf
>
> --
> 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 Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
>> Since windows-dll
>> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
>> similar, you've got a problem.
>
>Most definitely.

It is *not* strictly based on the executable path.  It first searches
the current directory, then searches the directory containing the executable.
Most Windows packages rely on this and place the DLL with the executable.
That should solve the problem of finding the "wrong" dll.

I'm still kind of amazed by all of the furor this discussion is generating,
given that I don't think we have yet seen a single problem reported.

If this was a big deal I would have thought that there would be many many
plaintive wails in this mailing list.

If the solution to the problem is as simple as placing the DLL with the
executable then why the heck don't we just do that?  I love being as
close to UNIX as possible but if it is going to cause problems then
it makes sense not to do things that way.

cgf

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

Re: DLL naming conventions

[Gary V. Vaughan]

On Sat, Sep 02, 2000 at 02:36:03PM -0400, Charles S. Wilson wrote:
> "Gary V. Vaughan" wrote:
> > 
> > Charles S. Wilson wrote:
> > >
> > > There is *something* in the windows system that gets notified that
> > > myapp.exe depends on mydll.dll whenever you execute myapp.exe.  This
> > > *something* searches the file system according to the search path
> > > described earlier in this thread, loads the dll into the executable
> > > process's memeory space (rebasing the memory location if necessary), and
> > > fixes up all the internal pointers to match the in-process virtual
> > > memory location.
> > >
> > > Isn't that considered a dynamic linker? (Whether you call that
> > > *something* a dynamic linker or not is really immaterial.  The
> > > *something* is a runtime loader, and that's what the reference above is
> > > discussing)
> > 
> > Nope.  Tor is correct.  The libtool versioning system assumes that the
> > runtime loader is smart enough to choose the most recent compatible
> > version of each dll that an application was linked with.  Many of the
> > operating systems that libtool supports have different rules for how
> > to name these versions so that the runtime loader can do it's stuff.
> > Libtool maps the unified version number scheme it exposes to the user
> > onto the versioning rules for the host platform.  That is why it is
> > okay to have libc5 and libc6 in the same directory on your Linux box.
> > Infact I could have several incompatible versions of libc6 in my lib
> > directory, and the runtime loader would choose the newest one that is
> > binary compatible with the version that the application was originally
> > linked with.
> 
> Hmmm....you can do this sort of thing -- in a limited way, of course --
> with appropriate naming of the dll and importlib.  Recall that import
> libs contain the hardcoded name of the dll for which they were built.
> 
> Also, there are two separate issues being discussed here: (1) how to
> (compile-time) link against the 'right' version of a library, and (2)
> how to insure that the 'right' dll is loaded at run-time.

Nah.  I'm talking about (2) only.  I *am* assuming that at link time
the only version of a library you can link with is the one that
corresponds with the header files you have installed.

> In the first
> case, 'right' just means the correct version that supports the necessary
> interface; in the second case, 'right' means the correct version
> compiled for the right environment -- since you can have windows-native
> dlls, Paul's unix-emulation-environment-based dll's (PW), cygwin dll's,
> UWin dll's -- all with (potentially) the same name.

Okay.  I probably wasn't thinking too hard about that...

> Since windows-dll
> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
> similar, you've got a problem.

Most definitely.

> It would be nice if you could create a 'cygwin LD_LIBARY_PATH' and a 'PW
> LD_LIBRARY_PATH' etc.  But that probably requires that you abandon dll's
> altogether, create your own 'so' file format, write an ld.so (ld.dll?)
> that will load .so's 'just like unix (tm)'.  And, for this to work
> cleanly, such a beast would have to be written for ALL the major unix
> emulation environments.  However, we're just concerned with cygwin,
> here.  (I can't take credit for this idea; both Tor Lillqvist and Chris
> Faylor have on occaision mentioned something similar)

In an ideal world.  I'd be surprised if anyone is keen enough to
actually write it though.  Far more likely that we can find the time
to make incremental improvements and adopt some conventions that make
things work a bit better...

> While not abandoning the preceding idea, it IS a lot of work (and there
> are a lot of implementation details to work out).  Although, it *will*
> fix point (1) *and* point (2) above.  
> 
> Now, you can (mostly) fix point (2: runtime loading) by the simple
> expedient of insuring that all dll's and exe's go into the same
> directory. Ugly, but much easier that the above semi-proposal.  An
> alternative solution to point (2) is to choose a unique prefix for dll's
> built on each platform -- e.g. Paul's suggestion of 'cygfoo.dll' for
> cygwin and 'pwfoo.dll' for his PW environment.  NOTE: you only need to
> munge the prefix of the dll itself; the import lib and/or static lib can
> still be 'libfoo.dll.a' or 'libfoo.a' -- because at
> compiletime/linktime, we *control* the library search path and are not
> limited by the global windows executable path.

I with you all the way so far...

> You can (mostly) fix point (1: compiletime version) by careful naming
> and use of import libs + careful naming and use of dll's.
> 
> For instance:
> 
>   libpng.dll.a  --> libpng3.dll.a  
>                 ^^
>               symlink
> 
>   libpng30.dll.a  (most recent API, corresponds to png-2.0.x)
>     embeds the name "libpng3.dll"
>   libpng20.dll.a  (older API, corresponds to png-1.0.x)
>     embeds the name "libpng2.dll"
> 
> Programs linked against '-lpng' will be dependent at runtime on
> libpng3.dll. Programs linked against -lpng2 (or against '-lpng' before
> version 2.0.x was installed -- e.g. when libpng.dll.a --> libpng2.dll.a)
> will be dependent at runtime on libpng2.dll

Why bother with the symlinks?  You can't link against -lpng2 unless
you have matching headers, and presumably you upgraded those when you
installed libpng3.dll.

My proposal was to start with this:

    libpng.dll.a embeds libpng2.dll
    
    and we keep libpng1.dll around for the applications that were
    linked against interface 1.
    
when we install png-2.0, which implements a new interface that is not
compatible with libpng2.dll, we install:

    a replacement libpng.dll.a that embeds libpng3.dll
    libpng3.dll
    
    and we keep libpng2.dll around for the applications that were
    linked against interface 2.

    and we keep libpng1.dll around for the applications that were
    linked against interface 1.

> Now, suppose that the png folks release a newer version, say png-2.1.x
> that exposes some additional features, but is backwards compatible with
> png-2.0.x.  Great.  You build it, but create:
> 
>   libpng31.dll.a (embeds the name libpng31.dll.a)
>   libpng.dll.a -> libpng31.dll.a
>   libpng3.dll (replaces the old version (*))

I don't think we need anything more than

    a replacement libpng3.dll
    
now applications that were linked against the libpng3.dll from png-2.0
will pick up the bugfixes from png-2.1, but new application can be
written for the header files installed with png-2.1 and take advantage
of the new features.


> Now, /usr/lib contains:
>   libpng.dll.a -> libpng31.dll.a
>   libpng31.dll.a
>   libpng30.dll.a
>   libpng20.dll.a
> and /usr/bin contains:
>   libpng3.dll
>   libpng2.dll
> 
> (*) you can't play simlink games with the dll's themselves, because the
> windows loader doesn't grok cygwin's symlinks.  You *can* play simlink
> games, as I've shown here, with the import libs, because the cygwin ld
> and cygwin gcc do grok symlinks.
> 
> This scheme will work without the help of libtool (e.g. you can still
> build & link dependent packages without being *forced* to use libtool)
> but it's similar enough to the 'unix way' that libtool should be able to
> handle it.

Except that I think you have an extra level of indirection that we can
safely do away with.  Otherwise we are still in violent agreement.

> > Libtool doesn't version dll's on Windows correctly right now, it uses
> > the linux versioning scheme to calculate the numbers.  It should
> > probably name them after the oldest ``interface'' (see the document
> > quoted above) that the library fully supports.  That is, if you build
> > a dll using libtool's --version 5:4:3, you would get library2.dll
>                                                        ^^^^^^^^^^^^
>                    I think you mean library3.dll (supports v5, v4, & v3)

Nope.  5:4:3 is revision 4 of the implementation of interface 5, which
is backwards compatible with the 3 previous interface definitions
(i.e. it is safe for applications linked against interfaces 5, 4, 3
and 2 to load the 5:4:3 dll at runtime).   Libtool translates the
5:4:3 into a system specific version number for the soname to help the
runtime loadee choose the best available library at runtime.  As I
said before, currently this mapping is wrong on Windows, and I think
the correct mapping is to always use the oldest supported interface
number -- in this case library2.dll -- when generating the soname.
This is explained fully in the version node of the libtool manual link
that was quoted earlier in the thread. 

> > (this version is at interface 5, but fully supports the last 3
> > interfaces).  This gives the windows loader the best chance of finding
> > the newest binary compatible dll.
> 
> In my scheme, --version 5:4:3 will give you library3.dll (assuming my
> correction above is right), but you'd also get:
> 
>  library.dll.a --> library5.dll.a
>  library5.dll.a (embeds the name library2.dll)
> 
> And these are still hanging around from previous builds
>  library4.dll.a (embeds the name library2.dll)
>  library3.dll.a (embeds the name library2.dll)
>  library2.dll.a (embeds the name library1.dll)
>  library1.dll

Okay we're diverging a little here.  I think that all you need is
library.dll.a, which always embeds the name of the dll that matches
the header files you have installed right now.  The point about
library1.dll and library2.dll is spot on though.

> > Unfortunately Windows makes no distinction between the application
> > search path and the library search path, so the scheme I propose is
> > still flawed =(O|  You might have a newer bugfixed binary compatible
> > version of the dll you need, but if it is further down the application
> > search path than the buggy version you originally linked with, you get
> > the broken version.  Nice one Bill...
> 
> Yeah, but you're still assuming that the link lib and the runtime lib
> are the same file.

Nope.  If we maintain the versions of library.dll according to either
of our schemes (which are broadly the same), it all breaks down if
some bozo installs a library2.dll in a location higher up our
*application* search path that the directory we are using, since our
applications will load their dll instead.  Maybe ours is the
library5.dll.a version with 2 releases worth of bugfixes and
enhancements over their library3.dll.a version they installed.

> > Maybe Cygwin should put all of it's libtool built libraries (or any
> > others that are correctly versioned w.r.t the runtime loader) into a
> > single directory that is near the front of the default path.  /usr/lib
> > seems like a good place.
> 
> That's part of my 'easy' solution above.  It may fix the cygwin problem,
> but the requirement is not nice to native apps or other unix-on-win
> emulations that the user may have.
> 
> Relying on 'get dll's from same dir as .exe' works -- but only if EVERY
> cygwin exe and EVERY cygwin dll are piled into the same dir.

Can't we assume that the native dll's we rely on are outside cygwin's
control and can be relied upon to be managed by the operating system
(I'm thinking of stuff in the SYSTEM directory), and that non-cygwin
libraries (such as Pauls pw dlls) will not be installed into the
cygwin binary search path?  In which case I think it is okay to
install all cygwin dlls and import libs to /usr/lib, making sure that
cygwin.bat (or any other cygwin startup methods) put /usr/lib first in
$PATH.  Does cygwin ld use -rpath yet?  If so we could encode
/usr/lib into each application as the first place to *always* look
when searching for a dll. (I guess I am asking whether the Windows
runtime loader will honor whatever rpath directory cygwin ld may
encode into an application -- as happens with all of the Unix ports of
libtool).

> I *think* the combination of implib/dll versioning described above, plus
> (sigh) unique prefixes for different platforms -- e.g. 'cygfoo.dll' --
> will solve most of the problems brought up w.r.t compiletime/linktime
> versioning, and runtime loading.  Without interfering too much with
> native apps or other unix-emul packages.  So what do you lose?
> 
> -1) Can't link directly to a dll; you must use an import lib.  (why? #1,
> ld only hunts for libfoo.dll & foo.dll, not cygfoo.dll. #2, if you link
> directly to dll's without using import libs, you lose the clean
> separation between 'runtime links' and 'development links' -- see
> http://www.debian.org/Lists-Archives/lsb-spec-9905/msg00011.html .  I
> know, there aren't really any 'runtime' symlinks, but at least you can
> separate the major so-names...)

The cygfoo point is well taken.  I'm not sure I would accept that
patch anymore...  infact I think that it is not a necessary part of
this proposal (either of our proposals infact) if we have some way to
control the runtime dll search path (by always putting /usr/lib first
in the PATH for example).

> -2) It's a helluva lot of work to change everything on a platform (say,
> cygwin) so that all dll's start with 'cyg' instead of 'lib'

This may be a non issue if you agree with my last paragraph.

> -3) It mostly solves a lot of the issues, but not completely. Not
> ideally. Not perfectly.

Hey.  This is Windows we're talking about =)O|

> -4) Still requires significant changes to libtool to handle dll's and
> importlibs.

Not that significant.  And this is all stuff that is on libtool's TODO
list anyway.  It will get done eventually, just as soon as we can nail
down a proposal that everyone (well most of us at least) likes.

> What do you gain?
> 
> +1) mostly solves the problem
> +2) you can still link dynamically or statically, without the use of
> libtool if you so choose

That is important, and I am prepared to accept a patch (nay, write a
patch in the fullness of time) to have libtool deal with import libs
properly.

> +3) you don't have to develop an ld.so 'smart' runtime loader
> 
> Is +3) a bigger win than work involved in -2) ?

I think so.  Unless someone steps up to the plate and offers to
implement an ld.so-a-like, I am prepared to work on having libtool do
the right thing as far as possible.

> Will Chris, DJ, Corinna, et. al. even go for -2) ?

Guys?  Stop me now if you violently disagree with libtool taking this
direction =)O|

> Developing an ld.so runtime loader requires far fewer changes to
> libtool, and since you *can* link directly to dll's (*) it'll work 'just
> like unix (tm). But developing ld.so will be a tough job.
> 
> (*) DJ has pushed a feature into ld that generates a 'virtual' import
> lib on-the-fly if you put a dll in the link line.

Yup. I picked his brains while he was doing it, and wrote something
similar for libtool.  By default libtool always searches for a dll to
link against and generates the implib on the fly if a suitable one is
found.

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 S. Wilson]

"Gary V. Vaughan" wrote:
> 
> Charles S. Wilson wrote:
> >
> > There is *something* in the windows system that gets notified that
> > myapp.exe depends on mydll.dll whenever you execute myapp.exe.  This
> > *something* searches the file system according to the search path
> > described earlier in this thread, loads the dll into the executable
> > process's memeory space (rebasing the memory location if necessary), and
> > fixes up all the internal pointers to match the in-process virtual
> > memory location.
> >
> > Isn't that considered a dynamic linker? (Whether you call that
> > *something* a dynamic linker or not is really immaterial.  The
> > *something* is a runtime loader, and that's what the reference above is
> > discussing)
> 
> Nope.  Tor is correct.  The libtool versioning system assumes that the
> runtime loader is smart enough to choose the most recent compatible
> version of each dll that an application was linked with.  Many of the
> operating systems that libtool supports have different rules for how
> to name these versions so that the runtime loader can do it's stuff.
> Libtool maps the unified version number scheme it exposes to the user
> onto the versioning rules for the host platform.  That is why it is
> okay to have libc5 and libc6 in the same directory on your Linux box.
> Infact I could have several incompatible versions of libc6 in my lib
> directory, and the runtime loader would choose the newest one that is
> binary compatible with the version that the application was originally
> linked with.

Hmmm....you can do this sort of thing -- in a limited way, of course --
with appropriate naming of the dll and importlib.  Recall that import
libs contain the hardcoded name of the dll for which they were built.

Also, there are two separate issues being discussed here: (1) how to
(compile-time) link against the 'right' version of a library, and (2)
how to insure that the 'right' dll is loaded at run-time.  In the first
case, 'right' just means the correct version that supports the necessary
interface; in the second case, 'right' means the correct version
compiled for the right environment -- since you can have windows-native
dlls, Paul's unix-emulation-environment-based dll's (PW), cygwin dll's,
UWin dll's -- all with (potentially) the same name.  Since windows-dll
loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
similar, you've got a problem.

It would be nice if you could create a 'cygwin LD_LIBARY_PATH' and a 'PW
LD_LIBRARY_PATH' etc.  But that probably requires that you abandon dll's
altogether, create your own 'so' file format, write an ld.so (ld.dll?)
that will load .so's 'just like unix (tm)'.  And, for this to work
cleanly, such a beast would have to be written for ALL the major unix
emulation environments.  However, we're just concerned with cygwin,
here.  (I can't take credit for this idea; both Tor Lillqvist and Chris
Faylor have on occaision mentioned something similar)

While not abandoning the preceding idea, it IS a lot of work (and there
are a lot of implementation details to work out).  Although, it *will*
fix point (1) *and* point (2) above.  

Now, you can (mostly) fix point (2: runtime loading) by the simple
expedient of insuring that all dll's and exe's go into the same
directory. Ugly, but much easier that the above semi-proposal.  An
alternative solution to point (2) is to choose a unique prefix for dll's
built on each platform -- e.g. Paul's suggestion of 'cygfoo.dll' for
cygwin and 'pwfoo.dll' for his PW environment.  NOTE: you only need to
munge the prefix of the dll itself; the import lib and/or static lib can
still be 'libfoo.dll.a' or 'libfoo.a' -- because at
compiletime/linktime, we *control* the library search path and are not
limited by the global windows executable path.

You can (mostly) fix point (1: compiletime version) by careful naming
and use of import libs + careful naming and use of dll's.

For instance:

  libpng.dll.a  --> libpng3.dll.a  
                ^^
              symlink

  libpng30.dll.a  (most recent API, corresponds to png-2.0.x)
    embeds the name "libpng3.dll"
  libpng20.dll.a  (older API, corresponds to png-1.0.x)
    embeds the name "libpng2.dll"

Programs linked against '-lpng' will be dependent at runtime on
libpng3.dll. Programs linked against -lpng2 (or against '-lpng' before
version 2.0.x was installed -- e.g. when libpng.dll.a --> libpng2.dll.a)
will be dependent at runtime on libpng2.dll

Now, suppose that the png folks release a newer version, say png-2.1.x
that exposes some additional features, but is backwards compatible with
png-2.0.x.  Great.  You build it, but create:

  libpng31.dll.a (embeds the name libpng31.dll.a)
  libpng.dll.a -> libpng31.dll.a
  libpng3.dll (replaces the old version (*))

Now, /usr/lib contains:
  libpng.dll.a -> libpng31.dll.a
  libpng31.dll.a
  libpng30.dll.a
  libpng20.dll.a
and /usr/bin contains:
  libpng3.dll
  libpng2.dll

(*) you can't play simlink games with the dll's themselves, because the
windows loader doesn't grok cygwin's symlinks.  You *can* play simlink
games, as I've shown here, with the import libs, because the cygwin ld
and cygwin gcc do grok symlinks.

This scheme will work without the help of libtool (e.g. you can still
build & link dependent packages without being *forced* to use libtool)
but it's similar enough to the 'unix way' that libtool should be able to
handle it.

> 
> Libtool doesn't version dll's on Windows correctly right now, it uses
> the linux versioning scheme to calculate the numbers.  It should
> probably name them after the oldest ``interface'' (see the document
> quoted above) that the library fully supports.  That is, if you build
> a dll using libtool's --version 5:4:3, you would get library2.dll
                                                       ^^^^^^^^^^^^
                   I think you mean library3.dll (supports v5, v4, & v3)

> (this version is at interface 5, but fully supports the last 3
> interfaces).  This gives the windows loader the best chance of finding
> the newest binary compatible dll.

In my scheme, --version 5:4:3 will give you library3.dll (assuming my
correction above is right), but you'd also get:

 library.dll.a --> library5.dll.a
 library5.dll.a (embeds the name library2.dll)

And these are still hanging around from previous builds
 library4.dll.a (embeds the name library2.dll)
 library3.dll.a (embeds the name library2.dll)
 library2.dll.a (embeds the name library1.dll)
 library1.dll

> 
> Unfortunately Windows makes no distinction between the application
> search path and the library search path, so the scheme I propose is
> still flawed =(O|  You might have a newer bugfixed binary compatible
> version of the dll you need, but if it is further down the application
> search path than the buggy version you originally linked with, you get
> the broken version.  Nice one Bill...

Yeah, but you're still assuming that the link lib and the runtime lib
are the same file.

> 
> Maybe Cygwin should put all of it's libtool built libraries (or any
> others that are correctly versioned w.r.t the runtime loader) into a
> single directory that is near the front of the default path.  /usr/lib
> seems like a good place.

That's part of my 'easy' solution above.  It may fix the cygwin problem,
but the requirement is not nice to native apps or other unix-on-win
emulations that the user may have.

Relying on 'get dll's from same dir as .exe' works -- but only if EVERY
cygwin exe and EVERY cygwin dll are piled into the same dir.

I *think* the combination of implib/dll versioning described above, plus
(sigh) unique prefixes for different platforms -- e.g. 'cygfoo.dll' --
will solve most of the problems brought up w.r.t compiletime/linktime
versioning, and runtime loading.  Without interfering too much with
native apps or other unix-emul packages.  So what do you lose?

-1) Can't link directly to a dll; you must use an import lib.  (why? #1,
ld only hunts for libfoo.dll & foo.dll, not cygfoo.dll. #2, if you link
directly to dll's without using import libs, you lose the clean
separation between 'runtime links' and 'development links' -- see
http://www.debian.org/Lists-Archives/lsb-spec-9905/msg00011.html .  I
know, there aren't really any 'runtime' symlinks, but at least you can
separate the major so-names...)

-2) It's a helluva lot of work to change everything on a platform (say,
cygwin) so that all dll's start with 'cyg' instead of 'lib'

-3) It mostly solves a lot of the issues, but not completely. Not
ideally. Not perfectly.

-4) Still requires significant changes to libtool to handle dll's and
importlibs.

What do you gain?

+1) mostly solves the problem
+2) you can still link dynamically or statically, without the use of
libtool if you so choose
+3) you don't have to develop an ld.so 'smart' runtime loader

Is +3) a bigger win than work involved in -2) ?
Will Chris, DJ, Corinna, et. al. even go for -2) ?

Developing an ld.so runtime loader requires far fewer changes to
libtool, and since you *can* link directly to dll's (*) it'll work 'just
like unix (tm). But developing ld.so will be a tough job.

(*) DJ has pushed a feature into ld that generates a 'virtual' import
lib on-the-fly if you put a dll in the link line.

--Chuck

--Chuck

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

Re: DLL naming conventions

[Chris Faylor]

On Sat, Sep 02, 2000 at 12:36:35PM -0400, David A. Cobb wrote:
>Chris Faylor wrote:
>>Cygwin's shared region problem comes about because it uses the name
>>'cygwin' when naming shared memory regions.
>
>Well then, [ this /must/ be a dumb question ], how about changing the
>name of the shared region when making a runtime visible change ?
>Nobody (?) except cygwin itself in various incarnations sees that name
>- I hope.

It's not that simple.  Two different shared memory regions would mean
different mount tables, tty tables, pid tables, etc.  because you had
two different versions of cygwin on your system.  One program would not
be able to correctly use a tty allocated by another.  That would end up
causing at least user confusion, if not program confusion.

There is no reason to have two versions of cygwin1.dll on your system.
In 1.1.4 I've made the error message for this scenario a little clearer
so hopefully people will figure this out.

cgf

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

Re: DLL naming conventions

[David A. Cobb]

Chris Faylor wrote:

> Cygwin's shared region problem comes about because it uses the name
> 'cygwin' when naming shared memory regions.
>

Well then, [ this /must/ be a dumb question ], how about changing the
name of the shared region when making a runtime visible change ?
Nobody (?) except cygwin itself in various incarnations sees that name -
I hope.
--
David A. Cobb, Software Engineer, Public Access Advocate
"Don't buy or use crappy software"
"By the grace of God I am a Christian man,
 by my actions a great sinner" -- The Way of a Pilgrim [R. M. French, tr.]



--
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

[Gary V. Vaughan]

On Fri, Sep 01, 2000 at 09:46:28AM -0400, Charles S. Wilson wrote:
> Tor Lillqvist wrote:
> > 
> > "Charles S. Wilson" <cwilson@ece.gatech.edu> writes:
> > 
> > > 2) on interface (API/ABI) versioning
> > >  http://www.gnu.org/software/libtool/manual.html#Versioning
> > 
> > Note that this document talks about stuff that AFAIK requires
> > cooperation from the runtime dynamic linker, that it knows how to
> > search for a suitable version of a shared library. No such dynamic
> > linker on Win32, alas.
> > 
> > (Writing a Unix-like (or should one say ELF-like?) dynamic linker for
> > Win32 would be an interesting exercise, of course.)
> 
> !!!! ????
> 
> There is *something* in the windows system that gets notified that
> myapp.exe depends on mydll.dll whenever you execute myapp.exe.  This
> *something* searches the file system according to the search path
> described earlier in this thread, loads the dll into the executable
> process's memeory space (rebasing the memory location if necessary), and
> fixes up all the internal pointers to match the in-process virtual
> memory location.
> 
> Isn't that considered a dynamic linker? (Whether you call that
> *something* a dynamic linker or not is really immaterial.  The
> *something* is a runtime loader, and that's what the reference above is
> discussing)

Nope.  Tor is correct.  The libtool versioning system assumes that the
runtime loader is smart enough to choose the most recent compatible
version of each dll that an application was linked with.  Many of the
operating systems that libtool supports have different rules for how
to name these versions so that the runtime loader can do it's stuff.
Libtool maps the unified version number scheme it exposes to the user
onto the versioning rules for the host platform.  That is why it is
okay to have libc5 and libc6 in the same directory on your Linux box.
Infact I could have several incompatible versions of libc6 in my lib
directory, and the runtime loader would choose the newest one that is
binary compatible with the version that the application was originally
linked with.

Libtool doesn't version dll's on Windows correctly right now, it uses
the linux versioning scheme to calculate the numbers.  It should
probably name them after the oldest ``interface'' (see the document
quoted above) that the library fully supports.  That is, if you build
a dll using libtool's --version 5:4:3, you would get library2.dll
(this version is at interface 5, but fully supports the last 3
interfaces).  This gives the windows loader the best chance of finding
the newest binary compatible dll.

Unfortunately Windows makes no distinction between the application
search path and the library search path, so the scheme I propose is
still flawed =(O|  You might have a newer bugfixed binary compatible
version of the dll you need, but if it is further down the application
search path than the buggy version you originally linked with, you get
the broken version.  Nice one Bill...

Maybe Cygwin should put all of it's libtool built libraries (or any
others that are correctly versioned w.r.t the runtime loader) into a
single directory that is near the front of the default path.  /usr/lib
seems like a good place.

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

[Larry Hall (RFK Partners, Inc)]

At 09:39 AM 9/1/2000, Charles S. Wilson wrote:

> > Note that there *is* a solution on Windows98 and Windows2000 (at least
> > reading Microsoft prose in MSDN Library) named "side-by-side DLLs"; however
> > this does *not* work on NT nor on 95 :-(
> > 
> > The idea is either by special arrangment when building the application (not
> > very practlical when porting) or by creating a file named "myapp.exe.local"
> > in the same directory than "myapp.exe", Windows will link the DLLs it found
> > in the same directory as "myapp.exe" BEFORE looking elsewhere, and even
> > before looking if it already has a copy of this DLL in memory.
>
>Actually, on all windows platforms the search order for dll's is loaded
>by the dynamic linker (windows loader, whatever)
>   1) the directory in which the executable resides
>   2) the current directory
>   3) Windows 95/98: The Windows system directory.
>      Windows NT/2K: The 32-bit Windows system directory. 
>   4) Windows NT/2K: The 16-bit Windows system directory.
>   5) The Windows directory.
>   6) The directories that are listed in the PATH environment variable.
>
>However, it is possible to do the exquivalent of a
>dlopen("c:\absolute\path\to\my.dll") (*).  In that case, you have a
>hardcoded path to a specific dll, and reqardless of whether my.dll is in
>the executable's directory, you'll still load
>c:\absolute\path\to\my.dll.
>
>(*) I forgot what the windows equivalent function of dlopen() is; I'll
>keep using the name dlopen(), but I mean the
>windows-equivalent-funtion-for-dlopen().
>
>The .local hack in Win2K is there for this explicit dlopen case, not the
>typical dynamic linker case -- because merely placing the dll's into the
>executable directory will force the dynamic linker to use those dll's
>rather than dll's in some other location.  When you have
>myapp.exe.local, W2K will OVERRIDE the absolute path in the dlopen()
>statement, and search the application's local directory first.
>
>--Chuck



Right, so in other words, Microsoft's solution to this problem is to push
back towards static libraries.  Back the pendulum swings...





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]

Tor Lillqvist wrote:
> 
> "Charles S. Wilson" <cwilson@ece.gatech.edu> writes:
> 
> > 2) on interface (API/ABI) versioning
> >  http://www.gnu.org/software/libtool/manual.html#Versioning
> 
> Note that this document talks about stuff that AFAIK requires
> cooperation from the runtime dynamic linker, that it knows how to
> search for a suitable version of a shared library. No such dynamic
> linker on Win32, alas.
> 
> (Writing a Unix-like (or should one say ELF-like?) dynamic linker for
> Win32 would be an interesting exercise, of course.)

!!!! ????

There is *something* in the windows system that gets notified that
myapp.exe depends on mydll.dll whenever you execute myapp.exe.  This
*something* searches the file system according to the search path
described earlier in this thread, loads the dll into the executable
process's memeory space (rebasing the memory location if necessary), and
fixes up all the internal pointers to match the in-process virtual
memory location.

Isn't that considered a dynamic linker? (Whether you call that
*something* a dynamic linker or not is really immaterial.  The
*something* is a runtime loader, and that's what the reference above is
discussing)

--Chuck

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

Re: DLL naming conventions

[Charles S. Wilson]

> Note that there *is* a solution on Windows98 and Windows2000 (at least
> reading Microsoft prose in MSDN Library) named "side-by-side DLLs"; however
> this does *not* work on NT nor on 95 :-(
> 
> The idea is either by special arrangment when building the application (not
> very practlical when porting) or by creating a file named "myapp.exe.local"
> in the same directory than "myapp.exe", Windows will link the DLLs it found
> in the same directory as "myapp.exe" BEFORE looking elsewhere, and even
> before looking if it already has a copy of this DLL in memory.

Actually, on all windows platforms the search order for dll's is loaded
by the dynamic linker (windows loader, whatever)
  1) the directory in which the executable resides
  2) the current directory
  3) Windows 95/98: The Windows system directory.
     Windows NT/2K: The 32-bit Windows system directory. 
  4) Windows NT/2K: The 16-bit Windows system directory.
  5) The Windows directory.
  6) The directories that are listed in the PATH environment variable.

However, it is possible to do the exquivalent of a
dlopen("c:\absolute\path\to\my.dll") (*).  In that case, you have a
hardcoded path to a specific dll, and reqardless of whether my.dll is in
the executable's directory, you'll still load
c:\absolute\path\to\my.dll.

(*) I forgot what the windows equivalent function of dlopen() is; I'll
keep using the name dlopen(), but I mean the
windows-equivalent-funtion-for-dlopen().

The .local hack in Win2K is there for this explicit dlopen case, not the
typical dynamic linker case -- because merely placing the dll's into the
executable directory will force the dynamic linker to use those dll's
rather than dll's in some other location.  When you have
myapp.exe.local, W2K will OVERRIDE the absolute path in the dlopen()
statement, and search the application's local directory first.

--Chuck

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

Re: DLL naming conventions

[Tor Lillqvist]

"Charles S. Wilson" <cwilson@ece.gatech.edu> writes:

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

Note that this document talks about stuff that AFAIK requires
cooperation from the runtime dynamic linker, that it knows how to
search for a suitable version of a shared library. No such dynamic
linker on Win32, alas.

(Writing a Unix-like (or should one say ELF-like?) dynamic linker for
Win32 would be an interesting exercise, of course.)

--tml

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

RE: DLL naming conventions

[Bernard Dautrevaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2794 bytes --]

> -----Original Message-----
> From: Egor Duda [ mailto:deo@logos-m.ru ]
> Sent: Thursday, August 31, 2000 6:44 PM
> To: Chris Faylor
> Cc: Charles S. Wilson
> Subject: Re: DLL naming conventions
> 
> 
> Hi!
> 
> Thursday, 31 August, 2000 Chris Faylor cgf@cygnus.com wrote:
> 
> >>(This  argument is based on the supposition that dll's with the same
> >>name  will  always  conflict.  If  I'm wrong about that supposition,
> >>please correct me...as I stated above, I'm a bit confused as to when
> >>dll's will conflict and when they will not)
> 
> CF> Can someone write a simple test to verify Windows 
> behavior?  It's pointless
> CF> to argue about what Windows does with DLLs if we don't 
> know for sure.
> 
> with ease. all you need is two different builds of cygwin1.dll, sh.exe
> and  strace.exe  i've  used  my  yesterday's build and current one.
> 1. create 2 directories -- say c:\test\1 and c:\test\2
> 2. copy first cygwin1.dll to c:\test\1 and other build to c:\test\2
> 3. copy sh.exe and strace.exe into both c:\test\1 and c:\test\2
> 4. start cmd.exe, cd c:\test\1, strace -o sh.log sh
> 5. start cmd.exe, cd c:\test\2, strace -o sh.log sh
> 6.  look  at the string containing "DLL build" in c:\test\1\sh.log and
> c:\test\2\sh.log
> 
> voila
> 

Note that there *is* a solution on Windows98 and Windows2000 (at least
reading Microsoft prose in MSDN Library) named "side-by-side DLLs"; however
this does *not* work on NT nor on 95 :-(

The idea is either by special arrangment when building the application (not
very practlical when porting) or by creating a file named "myapp.exe.local"
in the same directory than "myapp.exe", Windows will link the DLLs it found
in the same directory as "myapp.exe" BEFORE looking elsewhere, and even
before looking if it already has a copy of this DLL in memory.

This helps solve what Microsoft calls "DLL Hell", but is a typically kludgy
MS solution (especially the ".local" stuff). Some DLLs cannot run
side-by-side; their list is in
"HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs"; it's not
clear however if one can add it's own DLLs to this list, for example
cygwin1.dll that cannot be run side-by-side as it shares data cross-process.

HTH

	Bernard

PS: IOW the behaviour we were talking about was documented and Microsoft
itself discover that, although it allow for better performances, it may be
problematic :-)

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

RE: DLL naming conventions

[Bernard Dautrevaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4379 bytes --]

> -----Original Message-----
> From: Chris Faylor [ mailto:cgf@cygnus.com ]
> Sent: Thursday, August 31, 2000 5:53 PM
> To: Chris Faylor
> Cc: paul-ml@is.lg.ua
> Subject: Re: DLL naming conventions
> 
> 
> 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:

> 
> 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.

Exactly why I would like to have cygfoo.dll for library foo compiled on
cygwin, to differentiate from libfoo.dll (or was it foo.dll) as provided on
the official distribution on foo.org site :-)

> 
> 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.

Now but the fancy GIMP on NT package use some libtiff.dll and some other
cygwin ported package will use the cygwin-compiled libtiff.dll; if they are
both in the path we WILL have problems ;-(

> 
> >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'.

Sure? I, as a longtime SUN user and Linux user would rather search
libreadline.so.X.Y but my HP friends will rather look for libreadline.sl :-)

So long for the UNIX-on-Windows historical compatibility... searching for
cygreadline.dll is not worst and has the advantage of being explicit!

> 
> >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.

Don't know what to understand here: does that mean that if users have
problems with cygwin they are urged to try some other UNIX-on-Windows layer
rather than explain their problems and see how it could be found some
acceptable and effective solution?

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
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: 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

[Chris Faylor]

On Thu, Aug 31, 2000 at 06:35:53PM -0400, Charles S. Wilson wrote:
>Cygwin has libz.dll
>GIMP has (a different) libz.dll (sorry to pick on you, Tor; I know you
>don't even use the name libz.dll for your zlib dll, but let me use GIMP
>as an example, okay?)
>  -- assume for the moment that libz.dll uses 'shared regions' whatever
>those are. DATA exports? I dunno.
>
>You run a cygwin program from /usr/bin -- it'll load & use the cygwin
>libz.dll in /usr/bin. Fine.
>
>Then you run GIMP. It loads *it's* version of libz.dll. Blammo! Problem.
>'shared region' mismatch or whatever. If libz.dll uses shared regions...
>
>Or vice versa: you run GIMP first, and it works. Then you run a cygwin
>app that depends on libz.dll and blammo!.
>
>How can this problem be fixed, short of (a) never ever exporting DATA --
>if that's what 'shared regions' are(???) or (b) using different names
>for the dlls -- and we're back to the 'cyg' prefix, or assuming that all
>those OTHER people will use different prefixes and leave us alone...

Cygwin's shared region problem comes about because it uses the name
'cygwin' when naming shared memory regions.

If the mythical 'libz' uses the name 'libz' then naming your version
of libz.dll 'chuck.wilson.libz.version.1.1a.dll' will not solve that.

Shared memory usage really has nothing to do with DLL naming.

>(niggling little question: do all dll's set aside a 'shared region'? or
>only those that export DATA items?  If a dll doesn't use a 'shared
>region' then you wouldn't see these sorts of errors, as long as the two
>dlls were ABI/API compatible -- or would you? )

The accepted way to share information is with CreateFileMapping and
MapViewOfFile.  There is also a method for sharing data by marking
a section in the dll as "shared".  Microsoft has said that that's not
guaranteed to work, but I've never seen it fail.

So, again, cygwin is somewhat unique in being able to detect when there
are two versions in use.  It can do this because it uses shared memory
for things like pid info, etc.  Not every DLL will do this.  And, if
a DLL does do this the problem is not necessarily rectified by renaming
the DLL.  In fact, I think it is unlikely.

cgf

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

Re: DLL naming conventions

[Robert Collins]

That's what  I meant...
I'm not sure how much of .net is dcom, a.k.a. OLE3...

And unfortuneatly I don't know the build details for a com/ole server (which
is what we'd need in binutils). I believe there is v. little to it though
when you are using in-process servers. The big hooha is creating the class
registration in the registry at install time.

Anyway it's in the discussion pot now..
Rob

----- Original Message -----
From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <cygwin@sources.redhat.com>
Sent: Friday, September 01, 2000 9:51 AM
Subject: Re: DLL naming conventions


> Robert Collins wrote:
> >
> > I'll probably get shouted at for this but...
> > what about using dcom for shared libraries? It's designed to handle
> > versioning issues transparently, load the library from whatever location
> > desired etc.
>
> No, not shouted at. I don't think cygwin-binutils can do "Distributed
> COM (TM microsoft, copyright microsoft blah blah" builds, though, so
> it's not really applicable to this discussion.
>
> Unless you want to add Distributed COM support to ld?
>
> ("Distributed COM" a.k.a. COM+ a.k.a. .NET a.k.a
> Microsoft's-next-marketing-brainstorm is what you mean by 'dcom',
> right?)
>
> --Chuck
>


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

Re: DLL naming conventions

[Charles S. Wilson]

Robert Collins wrote:
> 
> I'll probably get shouted at for this but...
> what about using dcom for shared libraries? It's designed to handle
> versioning issues transparently, load the library from whatever location
> desired etc.

No, not shouted at. I don't think cygwin-binutils can do "Distributed
COM (TM microsoft, copyright microsoft blah blah" builds, though, so
it's not really applicable to this discussion.

Unless you want to add Distributed COM support to ld?

("Distributed COM" a.k.a. COM+ a.k.a. .NET a.k.a
Microsoft's-next-marketing-brainstorm is what you mean by 'dcom',
right?)

--Chuck

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

Re: DLL naming conventions

[Tor Lillqvist]

Charles S. Wilson writes:
 > GIMP has (a different) libz.dll (sorry to pick on you, Tor; I know you
 > don't even use the name libz.dll for your zlib dll, but let me use GIMP
 > as an example, okay?)

OK, this is a hypothetical example, but to reiterate: In reality, I
use a statically linked zlib... (and the more this thread goes on, the
more I am glad that I do ;-)

--tml


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

Re: DLL naming conventions

[Robert Collins]

I'll probably get shouted at for this but...
what about using dcom for shared libraries? It's designed to handle
versioning issues transparently, load the library from whatever location
desired etc.

Rob


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

Re: DLL naming conventions

[Charles S. Wilson]

Chris Faylor wrote:
> 
> On Thu, Aug 31, 2000 at 04:44:29PM -0400, Charles Wilson wrote:
> >1) experimental proof that clever dll placement in the filesystem can
> >get us out of 'DLL hell'
> 
> Haven't you seen people complaining about the "Shared region version
> mismatch" error with cygwin?  I really should have remembered this.

Ah yes. So, to make sure I understand, the shared region version
mismatch error is caused by:

you have two different cygwin1.dll's in the filesystem.

you run one cygwin app that loads the first cygwin1.dll into memory
(say, the app is in /bin and so it picks up the cygwin1.dll in /bin)

Then, you run another cygwin app that somehow picks up the other
cygwin1.dll (for instance, somebody for whatever IDIOTIC reason (*) put
an old copy of cygwin1.dll into \Windows\System, and has \Windows\System
in the front of their path, and this cygwin app is in /not/bin)

(*) don't do this. It's stupid, silly, and in all other ways a dumb
thing to do. You've been warned.

Blammo! Problem -- 'shared region version mismatch' since the two
different versions of cygwin1.dll are both trying to access the same
'shared region'.

Obviously, this proves that the windows loader will do what Chris and
Earnie (and others) have said. Problem solved. Almost:

Cygwin has libz.dll
GIMP has (a different) libz.dll (sorry to pick on you, Tor; I know you
don't even use the name libz.dll for your zlib dll, but let me use GIMP
as an example, okay?)
  -- assume for the moment that libz.dll uses 'shared regions' whatever
those are. DATA exports? I dunno.

You run a cygwin program from /usr/bin -- it'll load & use the cygwin
libz.dll in /usr/bin. Fine.

Then you run GIMP. It loads *it's* version of libz.dll. Blammo! Problem.
'shared region' mismatch or whatever. If libz.dll uses shared regions...

Or vice versa: you run GIMP first, and it works. Then you run a cygwin
app that depends on libz.dll and blammo!.

How can this problem be fixed, short of (a) never ever exporting DATA --
if that's what 'shared regions' are(???) or (b) using different names
for the dlls -- and we're back to the 'cyg' prefix, or assuming that all
those OTHER people will use different prefixes and leave us alone...

(niggling little question: do all dll's set aside a 'shared region'? or
only those that export DATA items?  If a dll doesn't use a 'shared
region' then you wouldn't see these sorts of errors, as long as the two
dlls were ABI/API compatible -- or would you? )

> 
> >2) should new libraries version their dll's when API/ABI changes?
> 
> Well, cygwin will when/if the API changes.  That's why it's called
> cygwin1.dll.
> 
> I went through my own private DLL hell to make this change.  Cygnus
> used to rename the DLL with every release so that executables built
> with last years DLL wouldn't work with this year's DLL even if there
> were only minimal changes in this year's DLL.
> 
> We used to name the net release DLLs based on the beta version, e.g.,
> cygwinb18.dll and cygwinb19.dll.  We stopped doing that with B20 since,
> for the most part, there have been no API changes since B18.
> 
> 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.

Done and done. (although, I'll probably add '.X' instead (or maybe .X.Y
if testing shows that the Y increment is binary-incompatible even if the
X (source compatibility marker) is unchanged). Whatever is the minimum
necessary versioning for application compatibility.

--Chuck

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

Re: DLL naming conventions

[Michael Ring]

>1) I want experimental proof of the above 'solution'. I think I'll go
>build a native libz.dll and play some games unless someone beats me to
>it.
>
>2) DLL versioning. While I'm not keen on redoing all the dll-ized
>packages that I've ported so far, IF it is deemed necessary I could see
>versioning NEW releases, but ONLY when the library in question goes
>through an API or ABI incompatible change.
>
>----
>For instance, right now libpng.dll is version 1.0.8.  Next week, say,
>the png folks release 1.0.9. Fine -- the updated cygwin version will
>still be libpng.dll.  Then, in a few months, the png folks release 2.0.0
>(or 1.2.x). Ah -- that version will be libpng.2.0.dll or libpng.1.2.dll
>(*) (but the import lib will be libpng.dll.a and will overwrite the old
>import lib (**) ).
>----
>
>(*) Yes, I know it really should be libpng.3.0.dll (or libpng.2.2.dll)
>since libpng-1.x.x is actually revision 2 of the API and libpng-2.x.x
>will be version 3 of the API. It's just an example; don't get riled.
>
>(**) Another controversial issue. Let's not discuss this one yet,
>please.
>
>Okay, restating my two remaining questions:
>
>1) experimental proof that clever dll placement in the filesystem can
>get us out of 'DLL hell'

I think that is impossible. Take the following user scenarios:

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. 

No (real) dll-hell here.

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. 

It is correct that applications always use dll's that come from the
current directory or from the directory that the application loaded
from. But according to Earnie's ideas contributed software ends up in
/usr/local/somewhere.

When an application starts from /usr/local it takes dll's first from
the app's dir, then from current dir, the path is searched. Here we
have dll-hell, because noone can predict how the path of this user
will look like. It is now possible that references to dll's are found
in gimp, in cygwin's /usr/bin or anywhere else. 

I can imagine that user2 can be found often, at least a lot of
person's i know use cygwin in that manner. They do not really care for
the inner beauty of cygwin (which imho is there ;-) ) they use cygwin
because it has well working grep, awk, sed & vi inside. (Those guys
are the only reason I can understand why text-mode is still inside of
cygwin)

The only solution to this dll-hell would be to put all cygwin-apps in
one directory together with all dll's provided by cygwin & contrib. A
task that i personally would not prefer exspecially if you think about
X11R6 which by default ends up in /usr/X11R6/bin

One possible solution would be to name dll's like this:

libfoo.1.1.cygwin.dll and play tricks in the implib.

>2) should new libraries version their dll's when API/ABI changes?
>
>--Chuck

Yes, please, the versioning of cygwin-contributed dll's should go with
the versioning of the original code that was used for porting.

Normally this would mean that a dll must exist thay has versioning
equivalent to the soname that was set in the corresponding
unix.library. With one exeption: Libraries should never be build with
full mayor.minor.patch version number because links do not work under
native win98/95 (crap)-OS. The maximum dll-name should include
mayor.minor as a version number.

Example:

Package foo has version 1.1.2 and builds a unix-so with soname 1.1
libfoo.1.1.dll is the correctly named dll
libfoo.dll.a is the imp-lib with references to libfoo.1.1.dll burned
in

libfoo.1.1.2.dll is an ivalid dll-name (because it uses
mayor.minor.patch versioning)

Michael Ring

--
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 04:44:29PM -0400, Charles Wilson wrote:
>1) experimental proof that clever dll placement in the filesystem can
>get us out of 'DLL hell'

Haven't you seen people complaining about the "Shared region version
mismatch" error with cygwin?  I really should have remembered this.

>2) should new libraries version their dll's when API/ABI changes?

Well, cygwin will when/if the API changes.  That's why it's called
cygwin1.dll.

I went through my own private DLL hell to make this change.  Cygnus
used to rename the DLL with every release so that executables built
with last years DLL wouldn't work with this year's DLL even if there
were only minimal changes in this year's DLL.

We used to name the net release DLLs based on the beta version, e.g.,
cygwinb18.dll and cygwinb19.dll.  We stopped doing that with B20 since,
for the most part, there have been no API changes since B18.

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.

cgf

--
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 Thu, Aug 31, 2000 at 12:41:46PM -0700, Earnie Boyd wrote:
> >--- Chris Faylor <cgf@cygnus.com> wrote:
> >>
> >> That means that the (so far hypothetical) DLL problems should be
> >> solvable by keeping the DLLs in the same directory as the executables.
> >>
> >
> >Great news!  So my earlier suggestion stands to good effect.  Unofficial Cygwin
> >packages should install in --prefix=/usr/local/packages.x.x.x.  Official Cygwin
> >packages should install in --prefix=/usr.  No need to prefix, suffix or munge
> >the names.
> >
> >Done,
> 
> (Chris and Earnie shake hands and go about their business...)
> 
> (Other people not quite so satisified...)
> 

<g>

You're probably right about that.  Since (for the most part) official
binaries are in /usr/bin ( == /bin) and official dll's are in /usr/bin (
== /bin), then prefix/suffix/munging of dll's is a non-issue (see point
#1 below).

However, this doesn't address the question of versioning the DLLs, for
source-incomaptible changes and ABI (object-code incompatible changes)
-- e.g. versioning would help alleviate problems introduced when the
libraries become incompatible in these ways.  (I am not talking about
the core libs -- just the contrib libs like jpeg, tiff, readline...  I
am also talking here only of problems that could crop up inside the
'cygwin' sandbox -- the versioning issue is orthogonal to the issue of
other 'platforms' or applications which use similarly named dlls)

So, I guess I still have two unanswered questions:

1) I want experimental proof of the above 'solution'. I think I'll go
build a native libz.dll and play some games unless someone beats me to
it.

2) DLL versioning. While I'm not keen on redoing all the dll-ized
packages that I've ported so far, IF it is deemed necessary I could see
versioning NEW releases, but ONLY when the library in question goes
through an API or ABI incompatible change. 

----
For instance, right now libpng.dll is version 1.0.8.  Next week, say,
the png folks release 1.0.9. Fine -- the updated cygwin version will
still be libpng.dll.  Then, in a few months, the png folks release 2.0.0
(or 1.2.x). Ah -- that version will be libpng.2.0.dll or libpng.1.2.dll
(*) (but the import lib will be libpng.dll.a and will overwrite the old
import lib (**) ).
----

(*) Yes, I know it really should be libpng.3.0.dll (or libpng.2.2.dll)
since libpng-1.x.x is actually revision 2 of the API and libpng-2.x.x
will be version 3 of the API. It's just an example; don't get riled.

(**) Another controversial issue. Let's not discuss this one yet,
please.

Okay, restating my two remaining questions:

1) experimental proof that clever dll placement in the filesystem can
get us out of 'DLL hell'
2) should new libraries version their dll's when API/ABI changes?

--Chuck

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

Re: DLL naming conventions

[Tor Lillqvist]

Chris Faylor writes:
 >   1. The directory from which the application loaded. 
 >   2. The current directory. 
 >   3. Windows 95/98: The Windows system directory. [...]
 >      Windows NT/ 2000: The 32-bit Windows system directory. [...]
 >   4.Windows NT/ 2000: The 16-bit Windows system directory. [...]
 >   5.The Windows directory. [...]
 >   6.The directories that are listed in the PATH environment variable. 

Where does the possible directories from the application's App Paths
registry entry fit into this? (For instance, if you have Acrobat
Reader 4.0, look at the registry key
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App
Paths\AcroRd32.exe . It contains a couple or directories that should
be searched for DLLs when running acrord32.exe.) My wild guess is that
these directories are inserted at front of those in %PATH%.

--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 12:41:46PM -0700, Earnie Boyd wrote:
>--- Chris Faylor <cgf@cygnus.com> wrote:
>> 
>> That means that the (so far hypothetical) DLL problems should be
>> solvable by keeping the DLLs in the same directory as the executables.
>> 
>
>Great news!  So my earlier suggestion stands to good effect.  Unofficial Cygwin
>packages should install in --prefix=/usr/local/packages.x.x.x.  Official Cygwin
>packages should install in --prefix=/usr.  No need to prefix, suffix or munge
>the names.
>
>Done,

(Chris and Earnie shake hands and go about their business...)

(Other people not quite so satisified...)

cgf

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

Re: DLL naming conventions

[Earnie Boyd]

--- Chris Faylor <cgf@cygnus.com> wrote:
> 
> That means that the (so far hypothetical) DLL problems should be
> solvable by keeping the DLLs in the same directory as the executables.
> 

Great news!  So my earlier suggestion stands to good effect.  Unofficial Cygwin
packages should install in --prefix=/usr/local/packages.x.x.x.  Official Cygwin
packages should install in --prefix=/usr.  No need to prefix, suffix or munge
the names.

Done,

=====
---
   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

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

[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

[Chris Faylor]

On Thu, Aug 31, 2000 at 01:26:53PM -0500, Matt Minnis wrote:
>Chris,
>
><<Snip>>
>
>>That means that the (so far hypothetical) DLL problems should be
>>solvable by keeping the DLLs in the same directory as the executables.
>
>Yes, windows searches the current directory first, then moves on to the path.

This is not strictly true.  Here's the load order from msdn.microsoft.com:

  1. The directory from which the application loaded. 

  2. The current directory. 

  3. Windows 95/98: The Windows system directory. Use the GetSystemDirectory
     function to get the path of this directory. 

     Windows NT/ 2000: The 32-bit Windows system directory. Use the GetSystemDirectory
     function to get the path of this directory. The name of this directory is SYSTEM32. 

  4.Windows NT/ 2000: The 16-bit Windows system directory. There is no function that
    obtains the path of this directory, but it is searched. The name of this directory
    is SYSTEM. 

  5.The Windows directory. Use the GetWindowsDirectory function to get the path of this directory. 

  6.The directories that are listed in the PATH environment variable. 

So, putting DLLs in the same directory as the application should solve the problem,
as I indicated.

cgf

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

Re: DLL naming conventions

[Matt Minnis]

Chris,

<<Snip>>

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

Yes, windows searches the current directory first, then moves on to the path.

Thanks,

Matt Minnis
Cthulhu for President. Why settle for a lesser evil?

=========================================================
Preferred Resources          (314) 567-7600 phone
701 Emerson rd.              (314) 993-6699 fax
Suite 475		       mminnis@prefres.com
St. Louis, MO
63141
=========================================================


--
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 08:44:17PM +0400, Egor Duda wrote:
>Hi!
>
>Thursday, 31 August, 2000 Chris Faylor cgf@cygnus.com wrote:
>
>>>(This  argument is based on the supposition that dll's with the same
>>>name  will  always  conflict.  If  I'm wrong about that supposition,
>>>please correct me...as I stated above, I'm a bit confused as to when
>>>dll's will conflict and when they will not)
>
>CF> Can someone write a simple test to verify Windows behavior?  It's pointless
>CF> to argue about what Windows does with DLLs if we don't know for sure.
>
>with ease. all you need is two different builds of cygwin1.dll, sh.exe
>and  strace.exe  i've  used  my  yesterday's build and current one.
>1. create 2 directories -- say c:\test\1 and c:\test\2
>2. copy first cygwin1.dll to c:\test\1 and other build to c:\test\2
>3. copy sh.exe and strace.exe into both c:\test\1 and c:\test\2
>4. start cmd.exe, cd c:\test\1, strace -o sh.log sh
>5. start cmd.exe, cd c:\test\2, strace -o sh.log sh
>6.  look  at the string containing "DLL build" in c:\test\1\sh.log and
>c:\test\2\sh.log
>
>voila

Duh.  Of course I know that it is possible to load conflicting versions of
the Cygwin DLL.  I guess that means that Windows doesn't just blindly use
DLLs of the same name (unless specially instructed to do so).

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

cgf

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

Re: DLL naming conventions

[Egor Duda]

Hi!

Thursday, 31 August, 2000 Chris Faylor cgf@cygnus.com wrote:

>>(This  argument is based on the supposition that dll's with the same
>>name  will  always  conflict.  If  I'm wrong about that supposition,
>>please correct me...as I stated above, I'm a bit confused as to when
>>dll's will conflict and when they will not)

CF> Can someone write a simple test to verify Windows behavior?  It's pointless
CF> to argue about what Windows does with DLLs if we don't know for sure.

with ease. all you need is two different builds of cygwin1.dll, sh.exe
and  strace.exe  i've  used  my  yesterday's build and current one.
1. create 2 directories -- say c:\test\1 and c:\test\2
2. copy first cygwin1.dll to c:\test\1 and other build to c:\test\2
3. copy sh.exe and strace.exe into both c:\test\1 and c:\test\2
4. start cmd.exe, cd c:\test\1, strace -o sh.log sh
5. start cmd.exe, cd c:\test\2, strace -o sh.log sh
6.  look  at the string containing "DLL build" in c:\test\1\sh.log and
c:\test\2\sh.log

voila

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19



--
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: 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: DLL naming conventions

[Chris Faylor]

On Thu, Aug 31, 2000 at 11:47:18AM -0400, Charles S. Wilson wrote:
>(This argument is based on the supposition that dll's with the same name
>will always conflict. If I'm wrong about that supposition, please
>correct me...as I stated above, I'm a bit confused as to when dll's will
>conflict and when they will not)

Can someone write a simple test to verify Windows behavior?  It's pointless
to argue about what Windows does with DLLs if we don't know for sure.

cgf

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

Re: DLL naming conventions

[Charles S. Wilson]

Earnie Boyd wrote:
> 
> As Chris already pointed out, the solution to this for Cygwin is:
> 
> For any official cygwin/latest or cygwin/contrib package release the:
>        package should be configured with --prefix=/usr
>        .dll should goto /usr/bin.
>        .a   should goto /usr/lib.
>        no versioning controls on the names of the libraries.

But Paul is suggesting that the prefix for dll's be changed so that the
foo library is named:
   libfoo.dll.a (import lib)
   libfoo.a     (static lib)
   cygfoo23.dll

This will not affect build procedures at all, since -lfoo will find
libfoo.dll.a (which was built with '--dll-name=cygfoo23.dll' option),
and '-lfoo -static' will find libfoo.a.

The versioning of the dll will affect upgradability IMO. 

Not even Paul is suggesting that the version number change based on pico
or micro level library changes ( libfoo version X.Y.Z-A  --> version
X.Y.Z-(A+1) or version X.Y.(Z+1)-A  would still have the same version
number: libfoo.X.Y.dll ).  This is because only the major and minor
version numbers mean that the interface has changed:

X means source-level incompatiblity: libfoo version X+1 will not ever
work with a package 'BAR' written for libfoo version X, unless you
modify 'BAR's source.

Y means object-level incompatibility: libfoo version X.Y+1 can be used
with package 'BAR', but you'll have to relink/recompile BAR for that to
work. You can't 'slipstream' libfoo version X.Y+1 and expect BAR to
work.

With that understanding, I think that versioning the DLL's *only* based
on X.Y is okay. (I suppose the "right" thing is to also version the
import libs based on X, but I just don't have the energy for that...)

Now, the use of the 'cyg' prefix instead of the 'lib' prefix -- for
DLL's *only*, not import libs -- is a whole 'nother can of worms. See
below.

> 
> For any unoffical cygwin package release the:
>        package should be configured with --prefix=/usr/local/package-x.x.x.
>        .dll should goto /usr/local/package-x.x.x/bin.
>        .a should goto /usr/local/package-x.x.x/lib.
>        .exe should goto /usr/local/package-x.x.x/bin.
>        .info should goto /usr/local/package-x.x.x/doc/info.
>        man files should goto /usr/local/package-x.x.x/doc/man.
>        html files should goto /usr/local/package-x.x.x/doc/html.
>        etc.
>        no versioning controls of the names of the libraries 

I'm not so sure about the versioning controls on DLL's, here, either.

> unless the
> libraries use shared memory regions that may conflict with other libraries of
> the same name.

Okay, now I am confused.

If two libraries have the same name, don't they automatically conflict? 
Windows loads the first one it finds into memory, and every executable
thereafter will use that copy, right?

Suppose the following:

The native Win32 port of GIMP uses libz.dll and libtiff.dll (compiled
natively, so no dependence on cygwin1.dll). Tor Lillqvist distributes
libz.dll and libtiff.dll bundled with his native Win32 GIMP (installed
into the same directory as the executable). Clearly, these two dlls are
incompatible with the cygwin libraries of the same name, and vice versa.

I built a cygwin XEmacs that depends on the cygwin libz.dll and
libtiff.dll.

Now, I run GIMP. Naturally, since the windows dynamic loader looks in
the directory of the executable before searching the path for any
dynamic dependencies, the GIMP/windows-native versions of libz.dll and
libtiff.dll are loaded into memory.

Then, I run cygwin-XEmacs.  Does the windows loader even try to locate
libz.dll or libtiff.dll -- or does it just use the (windows-native) ones
in memory?  Or does it try to load them, and not finding them in the
xemacs executable directory, searches the path and finds them in
/usr/bin and loads the cygwin-versions? If the windows loader DOES load
the cygwin-versions, do they then conflict in memory -- or do they
conflict only if they use shared memory regions....

How do you tell if a dll uses shared memory regions?

--------

Anyway, the more I ponder, the more I think using 'cyg' prefix on dll's
is a good idea -- Chris's objections notwithstanding.  Yes, cygwin was
here first.  But, by sticking to the 'libfoo.dll' name, we rely on the
good nature of the other unix-on-windows layers to not interfere with
us.  Or that other application packages will not interfere with us. 
Personally, I don't trust 'em. :-)

If we use a 'cyg' prefix, then its VERY unlikely any external executable
or package will ever screw up a cygwin installation through dll
conflicts.  We may, however, need to submit another patch to ld, so that
we restore the ability to link directly to dll's -- e.g. make ld 'know'
about the cyg prefix.

(This argument is based on the supposition that dll's with the same name
will always conflict. If I'm wrong about that supposition, please
correct me...as I stated above, I'm a bit confused as to when dll's will
conflict and when they will not)

--Chuck

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

RE: DLL naming conventions

[Earnie Boyd]

--- Bernard Dautrevaux <Dautrevaux@microprocess.com> wrote:
> > -----Original Message-----
> > From: Charles Wilson [ mailto:cwilson@ece.gatech.edu ]
> > Sent: Wednesday, August 30, 2000 9:16 PM
> > To: Bernard Dautrevaux
> > Cc: Paul Sokolovsky; cygwin@sources.redhat.com
> > Subject: Re: DLL naming conventions
> > 
> > 
> > <<warning. this message is controversial. please read the entire thing
> > before responding...>>
> 

As Chris already pointed out, the solution to this for Cygwin is:

For any official cygwin/latest or cygwin/contrib package release the:
       package should be configured with --prefix=/usr
       .dll should goto /usr/bin.
       .a   should goto /usr/lib.
       no versioning controls on the names of the libraries.

For any unoffical cygwin package release the:
       package should be configured with --prefix=/usr/local/package-x.x.x.
       .dll should goto /usr/local/package-x.x.x/bin.
       .a should goto /usr/local/package-x.x.x/lib.
       .exe should goto /usr/local/package-x.x.x/bin.
       .info should goto /usr/local/package-x.x.x/doc/info.
       man files should goto /usr/local/package-x.x.x/doc/man.
       html files should goto /usr/local/package-x.x.x/doc/html.
       etc.
       no versioning controls of the names of the libraries unless the
libraries use shared memory regions that may conflict with other libraries of
the same name.

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

RE: DLL naming conventions

[Bernard Dautrevaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 9578 bytes --]

> -----Original Message-----
> From: Charles Wilson [ mailto:cwilson@ece.gatech.edu ]
> Sent: Wednesday, August 30, 2000 9:16 PM
> To: Bernard Dautrevaux
> Cc: Paul Sokolovsky; cygwin@sources.redhat.com
> Subject: Re: DLL naming conventions
> 
> 
> <<warning. this message is controversial. please read the entire thing
> before responding...>>

I read it all, and I have to confess one thing: I took for granted that when
talking of versioning DLLs we were talking of the "interface" version, that
is compatibility versioning. 

This mistake was aggravated by the fact that we use 4-figures version
numbers, where the first number is the product generation -- total
incompatibility even at the user level --, the second correspond to
incompatible interface changes -- but source code compatibility --, the
third one 
is changed when compatible infercae changes are done and the last one is for
bugfix releases. 

So when saying having both X.Y and X.Z it was incompatible libraries (though
you can just recompile without any source code change), not minor
versionning. 

So I agree with you, we need libpng.dll and libpng2.dll (even if I would
call the earlier one libpng1.dll for consistency, but that's a non-problem),
but having libz123a.dll would be  *huge* nuisance.
 
Note that I need to use 2 figures for the incompatible changes of my
packages as I write a lot of things in C++ and object compatibility is
sometimes more difficult to achieve than source compatibility ;-(, so I use
one figure for the source-level incompatible changes, 1 for the
source-level-compatible but nevertheless object-level incompatible changes
and two others for compatible interface change and bug fixes without any
interface change (I was going to write "without semantics change" but indeed
correcting a bug change the semantics :-)).
> 
> Bernard Dautrevaux wrote:
> > 
> > I agree 100%; I port a lot of software to Windows and would 
> *hate* having to
> > change -ltiff to -lcytiff everywhere :-)
> > 
> > However having problems because I need some version of the 
> DLL coming from
> > some provider (e.g. the cygwin-compatible tcl DLL) and 
> picking another one
> > just because they both are named tcl.dll is just a 
> nuisance. All my DLLs are
> > usually named as <vendor><lib-name><version>.dll with 
> import libraries named
> > just lib<lib-name>.a (as you propose also below).
> 
> I knew I wasn't the first to think of this...
> 
> > 
> > > 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
> > 
> > I usually do just that with my own DLLs :-) Note that I 
> NEVER put version
> > numbers on the import libraries and ALWAYS put them on dll 
> themselves, so
> > that I can have tools using several versions of the DLL 
> installed at once
> > without any problem (as long as my DLLs do not share data 
> between instances
> > like cygwin itself where this will clearly broke apart).
> > 
> > > I'm not really in favor of using version numbers on shared
> > > libs,
> > 
> > I always do this, for reasons explained below :-)
> 
> To me, there are two benefits to dlls:
>  
> 1) less duplicated code to store & download (compared to 
> static linking)
> 2) update a dll to incorporate bugfix -> instant update of all linked
> applications
> 
> If you version dll's, you lose #2 completely.  Disk space is cheap and
> connection speed is getting faster all the time, so #1 is kinda
> pointless these days IMO and will become more pointless in the future.
> 
> > 
> > > 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
> > 
> > Why? usually the compile environment is quite well 
> controlled so that the
> > header files, import libraries and DLLs are all in sync, so 
> there is no need
> > to version the import library; however it is interesting to 
> version the DLL
> > itself to avoid having to recompile everything (even 
> obsoleted stuff) each
> > time a new version fo the DLL gets out.
> 
> I think versioning import libs is just silly -- but I threw 
> it out there
> to see if it would stick.

OK :-)

> 
> Why would you have to recompile an app if a new (but compatible) DLL
> comes out?  You'd only have to recompile if (a) you linked by ordinal
> instead of by name (AFAIK, cygwin-ld only links by name -- you can't
> link by ordinal) AND the library developer didn't use consistent
> ordinals, or (b) the DLL had an incompatible interface -- e.g. a major
> soname change.
> 
> However, versioning dlls down to the micro-revision level will cause a
> real headache, fast:
> 
> Q: why doesn't package X work? It says it requires zlib and I have it
> installed...
> A: you need version x.x.A of zlib, you probably have version x.x.B
> Q: okay, I removed version x.x.B and installed version x.x.A from the
> archived tarballs, and now package Y is broken
> A: well, package Y needs version x.x.B -- so you need to have both
> zlib-A and zlib-B installed if you want BOTH package X and 
> package Y to
> work.  Be sure install version x.x.A of zlib first, and version x.x.B
> last so that the import lib will link to the newer version of 
> zlib when
> you build package Z...
> 
> Aaarrrgghhh!!!!!!

Me too! 

> 
> You might as well link statically and forget you ever heard of DLLs.
> It'll sure cut down on support headaches.

Sure but complicates a lot updates of existing installs, as you pointed out
:-)

> 
> > 
> > Note that I'm biased at writing supported code, where I 
> want to avoid as far
> > as possible the risk of some code working in my environment 
> because I pick
> > version X.Y of some DLL and failing at the customer site, 
> perhaps at the
> > other end of the world (actually not yet really, just at 
> the other end of
> > France, but we can dream :-)) because he picks version 
> X.Y+1 from the
> > evaluation of some new stuff I do not have installed yet on 
> the support
> > people machine :-(
> 
> Yeah...but you're trying to support ONE application.  Since 
> I'm porting
> libraries to cygwin, I'm concerned about supporting ALL packages that
> depend on those libraries -- both their developers and their 
> (sometimes
> clueless) users.
> 
> I also don't want developers of package XYZ complaining to me 
> or the to
> the list because XYZ depended on version a.b of some library, and I
> removed it from the standard installation and put version a.b+1 on
> cygwin to catch some bugfixes.  "Please put a.b back -- we'd 
> prefer that
> you did extra work and supported 83 old revisions of each of your 27
> libraries, rather than us using and supporting the use of the most
> bugfree version of your library...we like bugs..."
> 
> Not gonna happen. At least, not by me. I hate to put it this way, but
> unversioned libraries (other than incompatible interface 
> changes) FORCE
> developers of other packages to use & support the most recent, most
> bugfree version of the libraries.  I'm NOT gonna get sucked into
> supporting all the old revisions of every library I've 
> ported.  I've got
> enough to do answering the questions about only the most recent
> versions...
> 
> If someone else wants to take over maintainership of the umpteen
> libraries I've ported so far, and version 'em -- fine.  But 
> don't expect
> me to help answer the thousands of FAQs that'll suddenly show 
> up on the
> list.  Unless somebody comes up with a really good argument for
> versioned libs (beyond the *necessity* imposed by incompatible
> interfaces -- I'll grant that one) AND can explain how to minimize the
> support difficulties.
> 
> > 
> > However I'm supporting strongly the ability of having old 
> and new versions
> > of tools working together on the same machine; for a long 
> time I avoided
> > DLLs just for that but with versioned DLLs I can use them 
> and my execs are a
> > lot lighter :-)
> 
> Until you neglect to upgrade to the newer versioned DLLs, and have to
> ship the old versions of the versioned dlls to everybody who uses your
> app.  Then your exec download is much heavier.
> 
> To me, the absolute best #1 *benefit* -- not drawback -- of DLLs and
> shared libs in general is that you can 'slipstream' update 
> all dependent
> apps without recompiling. 

I 100% agree; the volume of code is only slightly important fro me too; it's
just a bit faster to burn a 400Meg CDROM than a 600 one :-) 

The only reason I'm switching to DLLs is the upgradeability they bring me.

> 
> sure, when there's a major, incompatible change in the interface
> (so-name, in unix parlance) we might have to revisit this issue.  For
> instance, libpng-2.x.x (still in alpha) is incompatible with older
> apps.  It'll definitely have to be libpng2.dll. But for micro- and
> minor- version changes, I don't want to deal with versioned 
> dlls and the
> INEVITABLE support NIGHTMARE that will ensue.  You think non-versioned
> DLLs are a support problem? just wait...

Sure minor/micro versioned DLLs would be real nightmare! 



> 
> --Chuck
> 

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

Re: DLL naming conventions

[Charles Wilson]

<<warning. this message is controversial. please read the entire thing
before responding...>>

Bernard Dautrevaux wrote:
> 
> I agree 100%; I port a lot of software to Windows and would *hate* having to
> change -ltiff to -lcytiff everywhere :-)
> 
> However having problems because I need some version of the DLL coming from
> some provider (e.g. the cygwin-compatible tcl DLL) and picking another one
> just because they both are named tcl.dll is just a nuisance. All my DLLs are
> usually named as <vendor><lib-name><version>.dll with import libraries named
> just lib<lib-name>.a (as you propose also below).

I knew I wasn't the first to think of this...

> 
> > 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
> 
> I usually do just that with my own DLLs :-) Note that I NEVER put version
> numbers on the import libraries and ALWAYS put them on dll themselves, so
> that I can have tools using several versions of the DLL installed at once
> without any problem (as long as my DLLs do not share data between instances
> like cygwin itself where this will clearly broke apart).
> 
> > I'm not really in favor of using version numbers on shared
> > libs,
> 
> I always do this, for reasons explained below :-)

To me, there are two benefits to dlls:
 
1) less duplicated code to store & download (compared to static linking)
2) update a dll to incorporate bugfix -> instant update of all linked
applications

If you version dll's, you lose #2 completely.  Disk space is cheap and
connection speed is getting faster all the time, so #1 is kinda
pointless these days IMO and will become more pointless in the future.

> 
> > 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
> 
> Why? usually the compile environment is quite well controlled so that the
> header files, import libraries and DLLs are all in sync, so there is no need
> to version the import library; however it is interesting to version the DLL
> itself to avoid having to recompile everything (even obsoleted stuff) each
> time a new version fo the DLL gets out.

I think versioning import libs is just silly -- but I threw it out there
to see if it would stick.

Why would you have to recompile an app if a new (but compatible) DLL
comes out?  You'd only have to recompile if (a) you linked by ordinal
instead of by name (AFAIK, cygwin-ld only links by name -- you can't
link by ordinal) AND the library developer didn't use consistent
ordinals, or (b) the DLL had an incompatible interface -- e.g. a major
soname change.

However, versioning dlls down to the micro-revision level will cause a
real headache, fast:

Q: why doesn't package X work? It says it requires zlib and I have it
installed...
A: you need version x.x.A of zlib, you probably have version x.x.B
Q: okay, I removed version x.x.B and installed version x.x.A from the
archived tarballs, and now package Y is broken
A: well, package Y needs version x.x.B -- so you need to have both
zlib-A and zlib-B installed if you want BOTH package X and package Y to
work.  Be sure install version x.x.A of zlib first, and version x.x.B
last so that the import lib will link to the newer version of zlib when
you build package Z...

Aaarrrgghhh!!!!!!

You might as well link statically and forget you ever heard of DLLs.
It'll sure cut down on support headaches.

> 
> Note that I'm biased at writing supported code, where I want to avoid as far
> as possible the risk of some code working in my environment because I pick
> version X.Y of some DLL and failing at the customer site, perhaps at the
> other end of the world (actually not yet really, just at the other end of
> France, but we can dream :-)) because he picks version X.Y+1 from the
> evaluation of some new stuff I do not have installed yet on the support
> people machine :-(

Yeah...but you're trying to support ONE application.  Since I'm porting
libraries to cygwin, I'm concerned about supporting ALL packages that
depend on those libraries -- both their developers and their (sometimes
clueless) users.

I also don't want developers of package XYZ complaining to me or the to
the list because XYZ depended on version a.b of some library, and I
removed it from the standard installation and put version a.b+1 on
cygwin to catch some bugfixes.  "Please put a.b back -- we'd prefer that
you did extra work and supported 83 old revisions of each of your 27
libraries, rather than us using and supporting the use of the most
bugfree version of your library...we like bugs..."

Not gonna happen. At least, not by me. I hate to put it this way, but
unversioned libraries (other than incompatible interface changes) FORCE
developers of other packages to use & support the most recent, most
bugfree version of the libraries.  I'm NOT gonna get sucked into
supporting all the old revisions of every library I've ported.  I've got
enough to do answering the questions about only the most recent
versions...

If someone else wants to take over maintainership of the umpteen
libraries I've ported so far, and version 'em -- fine.  But don't expect
me to help answer the thousands of FAQs that'll suddenly show up on the
list.  Unless somebody comes up with a really good argument for
versioned libs (beyond the *necessity* imposed by incompatible
interfaces -- I'll grant that one) AND can explain how to minimize the
support difficulties.

> 
> However I'm supporting strongly the ability of having old and new versions
> of tools working together on the same machine; for a long time I avoided
> DLLs just for that but with versioned DLLs I can use them and my execs are a
> lot lighter :-)

Until you neglect to upgrade to the newer versioned DLLs, and have to
ship the old versions of the versioned dlls to everybody who uses your
app.  Then your exec download is much heavier.

To me, the absolute best #1 *benefit* -- not drawback -- of DLLs and
shared libs in general is that you can 'slipstream' update all dependent
apps without recompiling. 

sure, when there's a major, incompatible change in the interface
(so-name, in unix parlance) we might have to revisit this issue.  For
instance, libpng-2.x.x (still in alpha) is incompatible with older
apps.  It'll definitely have to be libpng2.dll. But for micro- and
minor- version changes, I don't want to deal with versioned dlls and the
INEVITABLE support NIGHTMARE that will ensue.  You think non-versioned
DLLs are a support problem? just wait...

--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 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: DLL naming conventions

[Bernard Dautrevaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5526 bytes --]

> -----Original Message-----
> From: Charles Wilson [ mailto:cwilson@ece.gatech.edu ]
> Sent: Wednesday, August 30, 2000 4:52 PM
> To: Paul Sokolovsky
> Cc: cygwin@sources.redhat.com
> Subject: Re: DLL naming conventions
> 
> 
> 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...

I agree 100%; I port a lot of software to Windows and would *hate* having to
change -ltiff to -lcytiff everywhere :-) 

However having problems because I need some version of the DLL coming from
some provider (e.g. the cygwin-compatible tcl DLL) and picking another one
just because they both are named tcl.dll is just a nuisance. All my DLLs are
usually named as <vendor><lib-name><version>.dll with import libraries named
just lib<lib-name>.a (as you propose also below).


	<skipped>

> > 
> >   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 usually do just that with my own DLLs :-) Note that I NEVER put version
numbers on the import libraries and ALWAYS put them on dll themselves, so
that I can have tools using several versions of the DLL installed at once
without any problem (as long as my DLLs do not share data between instances
like cygwin itself where this will clearly broke apart).

> I'm not really in favor of using version numbers on shared 
> libs, 

I always do this, for reasons explained below :-)

> 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

Why? usually the compile environment is quite well controlled so that the
header files, import libraries and DLLs are all in sync, so there is no need
to version the import library; however it is interesting to version the DLL
itself to avoid having to recompile everything (even obsoleted stuff) each
time a new version fo the DLL gets out.

Note that I'm biased at writing supported code, where I want to avoid as far
as possible the risk of some code working in my environment because I pick
version X.Y of some DLL and failing at the customer site, perhaps at the
other end of the world (actually not yet really, just at the other end of
France, but we can dream :-)) because he picks version X.Y+1 from the
evaluation of some new stuff I do not have installed yet on the support
people machine :-(

However I'm supporting strongly the ability of having old and new versions
of tools working together on the same machine; for a long time I avoided
DLLs just for that but with versioned DLLs I can use them and my execs are a
lot lighter :-)

> 
> > 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.

I think libtool is quite irrelevant here; even manually we can do all that
without too much of a hassle, as long as we have sorted out the clumsy
windows-dll building mechanism, but due to the discussion I take that for
granted :-).

Regards,

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
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

[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]

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: 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

[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

[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 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

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