Subject: Re: DLL naming conventions
From: "Gary V. Vaughan" <[email-masked]>
To: Charles Wilson <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Sun, 3 Sep 2000 13:04:41 +0100

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: [email-masked]
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       [email-masked] 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
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 [email-masked]