* Re: DLL naming conventions
@ 2000-09-01 4:49 Tor Lillqvist
2000-09-01 6:47 ` Charles S. Wilson
0 siblings, 1 reply; 20+ messages in thread
From: Tor Lillqvist @ 2000-09-01 4:49 UTC (permalink / raw)
To: cygwin
"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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-01 4:49 DLL naming conventions Tor Lillqvist @ 2000-09-01 6:47 ` Charles S. Wilson 2000-09-02 6:56 ` Gary V. Vaughan 0 siblings, 1 reply; 20+ messages in thread From: Charles S. Wilson @ 2000-09-01 6:47 UTC (permalink / raw) To: Tor Lillqvist; +Cc: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-01 6:47 ` Charles S. Wilson @ 2000-09-02 6:56 ` Gary V. Vaughan 2000-09-02 11:36 ` Charles S. Wilson 0 siblings, 1 reply; 20+ messages in thread From: Gary V. Vaughan @ 2000-09-02 6:56 UTC (permalink / raw) To: Charles S. Wilson; +Cc: Tor Lillqvist, cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-02 6:56 ` Gary V. Vaughan @ 2000-09-02 11:36 ` Charles S. Wilson 2000-09-02 16:40 ` Gary V. Vaughan 0 siblings, 1 reply; 20+ messages in thread From: Charles S. Wilson @ 2000-09-02 11:36 UTC (permalink / raw) To: Gary V. Vaughan; +Cc: Tor Lillqvist, cygwin, libtool "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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-02 11:36 ` Charles S. Wilson @ 2000-09-02 16:40 ` Gary V. Vaughan 2000-09-02 19:20 ` Chris Faylor 2000-09-02 22:32 ` DLL naming conventions Charles Wilson 0 siblings, 2 replies; 20+ messages in thread From: Gary V. Vaughan @ 2000-09-02 16:40 UTC (permalink / raw) To: Charles S. Wilson; +Cc: Tor Lillqvist, cygwin, libtool 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-02 16:40 ` Gary V. Vaughan @ 2000-09-02 19:20 ` Chris Faylor 2000-09-02 21:23 ` Robert Collins ` (3 more replies) 2000-09-02 22:32 ` DLL naming conventions Charles Wilson 1 sibling, 4 replies; 20+ messages in thread From: Chris Faylor @ 2000-09-02 19:20 UTC (permalink / raw) To: cygwin; +Cc: gvv 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-02 19:20 ` Chris Faylor @ 2000-09-02 21:23 ` Robert Collins 2000-09-02 22:56 ` Charles Wilson ` (2 subsequent siblings) 3 siblings, 0 replies; 20+ messages in thread From: Robert Collins @ 2000-09-02 21:23 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-02 19:20 ` Chris Faylor 2000-09-02 21:23 ` Robert Collins @ 2000-09-02 22:56 ` Charles Wilson 2000-09-03 5:31 ` Gary V. Vaughan 2000-09-04 15:22 ` Current Directory? [Branch from Re: DLL naming conventions] David A. Cobb 3 siblings, 0 replies; 20+ messages in thread From: Charles Wilson @ 2000-09-02 22:56 UTC (permalink / raw) To: cygwin; +Cc: gvv 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-02 19:20 ` Chris Faylor 2000-09-02 21:23 ` Robert Collins 2000-09-02 22:56 ` Charles Wilson @ 2000-09-03 5:31 ` Gary V. Vaughan 2000-09-03 9:31 ` Chris Faylor 2000-09-04 15:22 ` Current Directory? [Branch from Re: DLL naming conventions] David A. Cobb 3 siblings, 1 reply; 20+ messages in thread From: Gary V. Vaughan @ 2000-09-03 5:31 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-03 5:31 ` Gary V. Vaughan @ 2000-09-03 9:31 ` Chris Faylor 2000-09-03 10:32 ` Chris Faylor 2000-09-04 6:56 ` Gary V. Vaughan 0 siblings, 2 replies; 20+ messages in thread From: Chris Faylor @ 2000-09-03 9:31 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-03 9:31 ` Chris Faylor @ 2000-09-03 10:32 ` Chris Faylor 2000-09-04 6:56 ` Gary V. Vaughan 1 sibling, 0 replies; 20+ messages in thread From: Chris Faylor @ 2000-09-03 10:32 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-03 9:31 ` Chris Faylor 2000-09-03 10:32 ` Chris Faylor @ 2000-09-04 6:56 ` Gary V. Vaughan 1 sibling, 0 replies; 20+ messages in thread From: Gary V. Vaughan @ 2000-09-04 6:56 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Current Directory? [Branch from Re: DLL naming conventions] 2000-09-02 19:20 ` Chris Faylor ` (2 preceding siblings ...) 2000-09-03 5:31 ` Gary V. Vaughan @ 2000-09-04 15:22 ` David A. Cobb 2000-09-04 19:53 ` Chris Faylor 3 siblings, 1 reply; 20+ messages in thread From: David A. Cobb @ 2000-09-04 15:22 UTC (permalink / raw) To: cygwin; +Cc: gvv 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. With the possibility of several processes active and several partitions, etc., just like the big boys; what does "current directory" mean? I only see it when defining a PIF for a DOS program. -- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Current Directory? [Branch from Re: DLL naming conventions] 2000-09-04 15:22 ` Current Directory? [Branch from Re: DLL naming conventions] David A. Cobb @ 2000-09-04 19:53 ` Chris Faylor 2000-09-05 12:29 ` Bob McGowan 0 siblings, 1 reply; 20+ messages in thread From: Chris Faylor @ 2000-09-04 19:53 UTC (permalink / raw) To: cygwin On Mon, Sep 04, 2000 at 06:22:18PM -0400, David A. Cobb wrote: >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. > >With the possibility of several processes active and several partitions, etc., >just like the big boys; what does "current directory" mean? I only see it when >defining a PIF for a DOS program. I actually got the order wrong. It searches the directory containing the executable and then the current directory. As far as what the "current directory" means, it means the directory you're cd'ed to. cgf -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Current Directory? [Branch from Re: DLL naming conventions] 2000-09-04 19:53 ` Chris Faylor @ 2000-09-05 12:29 ` Bob McGowan 2000-09-05 13:37 ` David A. Cobb 0 siblings, 1 reply; 20+ messages in thread From: Bob McGowan @ 2000-09-05 12:29 UTC (permalink / raw) To: cygwin Chris Faylor wrote: > > On Mon, Sep 04, 2000 at 06:22:18PM -0400, David A. Cobb wrote: > >Chris Faylor wrote: > > > >> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote: > >> >> Since windows-dll --- > > As far as what the "current directory" means, it means the directory > you're cd'ed to. > > cgf I'd like to expand on this, hopefully to add clarity. The above is absolutely correct, for an interactive foreground shell session. Another way to say it is that the "current directory" is what you would get if you were to open the file named "." (dot, period...) in an application (which includes the shells). Additionally, since any particular application may be run in the background, and may also change directory, it is possible to have several "current directories", depending on which of the running applications you are referring to. -- Bob McGowan Staff Software Quality Engineer VERITAS Software rmcgowan@veritas.com -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Current Directory? [Branch from Re: DLL naming conventions] 2000-09-05 12:29 ` Bob McGowan @ 2000-09-05 13:37 ` David A. Cobb 2000-09-05 15:02 ` Bob McGowan 0 siblings, 1 reply; 20+ messages in thread From: David A. Cobb @ 2000-09-05 13:37 UTC (permalink / raw) To: cygwin Bob McGowan wrote: > I'd like to expand on this, hopefully to add clarity. The above is > absolutely correct, for an interactive foreground shell session. > Another way to say it is that the "current directory" is what you would > get if you were to open the file named "." (dot, period...) in an > application (which includes the shells). > > Additionally, since any particular application may be run in the > background, and may also change directory, it is possible to have > several "current directories", depending on which of the running > applications you are referring to. > The "Current Directory" then, must be a property/attribute of the "Current Process." Is that correct? With respect to the operator, it is relative to the current top window? In other words, when I launch a program the cd is established by the [shell] process in which I execute the launch command. Subsequently, the running process may change it internally. If I focus somewhere else, "my" current directory changes, but that's irrelevant to the program I launched before. Have I got it? > > -- > Bob McGowan > Staff Software Quality Engineer > VERITAS Software > rmcgowan@veritas.com > > -- > Want to unsubscribe from this list? > Send a message to cygwin-unsubscribe@sourceware.cygnus.com -- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Current Directory? [Branch from Re: DLL naming conventions] 2000-09-05 13:37 ` David A. Cobb @ 2000-09-05 15:02 ` Bob McGowan 0 siblings, 0 replies; 20+ messages in thread From: Bob McGowan @ 2000-09-05 15:02 UTC (permalink / raw) To: David A. Cobb; +Cc: cygwin "David A. Cobb" wrote: > > Bob McGowan wrote: > > > I'd like to expand on this, hopefully to add clarity. The above is --- The one thing I did not say I was doing, was looking at this from a "command line" orientation. Windowing software adds complexity since the user now is seeing multiple instances of applications. > > The "Current Directory" then, must be a property/attribute of the "Current > Process." Is that correct? With respect to the operator, it is relative > to the current top window? I'm not sure what the definition should be for "Current Process". If by that you mean the currently active, top window, then basically, yes. But, each and every process has a "current directory", whether or not it is currently running, whether or not it is the "top window", etc. You are correct that from the perspective of the operator, the operator's "current directory" will be that of the top window. > In other words, when I launch a program the cd is established by the > [shell] process in which I execute the launch command. Subsequently, the > running > process may change it internally. If I focus somewhere else, "my" current > directory changes, but that's irrelevant to the program I launched before. > > Have I got it? > I think you've got it ;) -- Bob McGowan Staff Software Quality Engineer VERITAS Software rmcgowan@veritas.com -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-02 16:40 ` Gary V. Vaughan 2000-09-02 19:20 ` Chris Faylor @ 2000-09-02 22:32 ` Charles Wilson 2000-09-03 5:29 ` Gary V. Vaughan 1 sibling, 1 reply; 20+ messages in thread From: Charles Wilson @ 2000-09-02 22:32 UTC (permalink / raw) To: Gary V. Vaughan; +Cc: Tor Lillqvist, cygwin, libtool "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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-02 22:32 ` DLL naming conventions Charles Wilson @ 2000-09-03 5:29 ` Gary V. Vaughan 2000-09-03 12:40 ` Alexandre Oliva 0 siblings, 1 reply; 20+ messages in thread From: Gary V. Vaughan @ 2000-09-03 5:29 UTC (permalink / raw) To: Charles Wilson; +Cc: cygwin, libtool 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DLL naming conventions 2000-09-03 5:29 ` Gary V. Vaughan @ 2000-09-03 12:40 ` Alexandre Oliva 0 siblings, 0 replies; 20+ messages in thread From: Alexandre Oliva @ 2000-09-03 12:40 UTC (permalink / raw) To: Gary V. Vaughan; +Cc: Charles Wilson, cygwin, libtool 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2000-09-05 15:02 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-09-01 4:49 DLL naming conventions Tor Lillqvist 2000-09-01 6:47 ` Charles S. Wilson 2000-09-02 6:56 ` Gary V. Vaughan 2000-09-02 11:36 ` Charles S. Wilson 2000-09-02 16:40 ` Gary V. Vaughan 2000-09-02 19:20 ` Chris Faylor 2000-09-02 21:23 ` Robert Collins 2000-09-02 22:56 ` Charles Wilson 2000-09-03 5:31 ` Gary V. Vaughan 2000-09-03 9:31 ` Chris Faylor 2000-09-03 10:32 ` Chris Faylor 2000-09-04 6:56 ` Gary V. Vaughan 2000-09-04 15:22 ` Current Directory? [Branch from Re: DLL naming conventions] David A. Cobb 2000-09-04 19:53 ` Chris Faylor 2000-09-05 12:29 ` Bob McGowan 2000-09-05 13:37 ` David A. Cobb 2000-09-05 15:02 ` Bob McGowan 2000-09-02 22:32 ` DLL naming conventions Charles Wilson 2000-09-03 5:29 ` Gary V. Vaughan 2000-09-03 12:40 ` Alexandre Oliva
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).