This is the mail archive of the
mailing list for the Cygwin project.
Re: DLL naming conventions
On Fri, Sep 01, 2000 at 09:46:28AM -0400, Charles S. Wilson wrote:
> Tor Lillqvist wrote:
> > "Charles S. Wilson" <firstname.lastname@example.org> 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
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
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.
___ _ ___ __ _ mailto: email@example.com
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ firstname.lastname@example.org
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ gpg public key:
Want to unsubscribe from this list?
Send a message to email@example.com