RE: DLL naming conventions

[Bernard Dautrevaux <Dautrevaux at microprocess dot com>]

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