From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gary V. Vaughan" To: "Charles S. Wilson" Cc: Tor Lillqvist , cygwin@sources.redhat.com Subject: Re: DLL naming conventions Date: Sat, 02 Sep 2000 06:56:00 -0000 Message-id: <20000902140958.F7695@demon.co.uk> References: <200009011148.OAA23769@urkki.tellabs.fi> <39AFB333.69CE5F95@ece.gatech.edu> X-SW-Source: 2000-09/msg00036.html On Fri, Sep 01, 2000 at 09:46:28AM -0400, Charles S. Wilson wrote: > Tor Lillqvist wrote: > > > > "Charles S. Wilson" 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