Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com From: Michael DOT Ring AT t-mobil DOT de Date: 24 Oct 2000 11:37:09 +0000 Discarded-X400-MTS-Extensions: (43) (12) (2) (135) (115) (5) (6) (3) To: cygwin AT sources DOT redhat DOT com Subject: AW: DLL naming flamefest Importance: normal Autoforwarded: FALSE Message-Id: Original-Encoded-Information-Types: (1) (0) (10021) (7) (1) (0) (6), (1) (0) (10021) (7) (1) (0) (1) >static lib: libfoo.a (not versioned) >import lib: libfoo.dll.a (not versioned) >dll : cygfooX.dll (versioned -- usually) The master of dll's has spoken, so be it! I'll get to the drawbacks in a minute. >So what's this about a change to binutils? CVS versions of binutils >accept a new > '--dll-search-prefix=' option. >This option changes the search order at link time, when doing a dynamic >link, to the following: > libfoo.dll.a (import libs are preferred) > foo.dll.a > libfoo.a (then static libs -- which MIGHT > be an import lib. There's also a > more esoteric reason why this has > to be here; I don't want to go > into that now.) > foo.dll > libfoo.dll > foo.dll >Eventually, (and don't pester the core team about this), the next >cygwin-binutils release will include this functionality. At that time, >I'd like to get a patch into cygwin-gcc so that gcc calls ld with >'--dll-search-prefix=cyg'. Then, when you specify '-lfoo' and there is >no import lib nor static lib, you can still link to cygfoo.dll using >DJ's on-the-fly virtual import lib spiffyness. With these changes, >'cygfoo.dll' will be a fully supported, preferred *default* name for >dlls. I have not (yet) checked your site but I would like to get my hands on a pre-compilesd version of gcc & binutils with all needed features included (The version you used to build your dll's) Are they available ? >So, here's the downside: >This won't work as seamlessly for versioned dll's -- you'd have to >specify '-lfoo7' to link to cygfoo7.dll. BUT, remember, >link-directly-to-dll-with-no-implib is an emergency fallback for dlls >that we don't have implibs for. (Worse, if the dll is stripped you >can't link to it -- all of the dll's in the seven packages above are >stripped -- because I'm supplying implibs!) fine with me! >Windows is dumb. YESYESYES and YES! >We don't version the statlibs or import libs because we can >play symlink games later; all of our build tools DO understand >symlinks. Also, dll's for 'frozen' libraries don't need to be >versioned. zlib is NOT going to change its interface. Neither is >gettext (libintl). WAY too many things would break if those ever >changed their interface. So, of the seven libraries listed above, >here's the breakdown: >UNVERSIONED >zlib-1.1.3-5 very stable >gdbm-1.8.0-3 last update 2 yrs ago. next-to-last, 5 years. >gettext-0.10.35-2 last update 1.5 yrs ago. Too bad that they are not versioned, makes things look more consistent, but I do agree, versioning is not necessary >Now, before flaming, please read the following thread (all of it -- >almost 200 messages!). > >"DLL naming conventions" > http://www.cygwin.com/ml/cygwin/2000-08/msg01128.html >continues in the next month's archives: > http://sources.redhat.com/ml/cygwin/2000-09/msg00000.html >there are lots of ancilliary branches. > >"libtool" > http://sources.redhat.com/ml/cygwin/2000-09/msg00137.html > >"linking against shared libraries" > http://sources.redhat.com/ml/cygwin/2000-09/msg00551.html Ooops, only read 150 messages of those, so I am not entitled to flame..... But when thinking about it, there's nothing to flame for me here --> > (3) Various other valid objections for a variety of good reasons. >Michael Ring comes to mind here. Even a few of MY objections were >valid. :-P 8-) > (4) There's work going on in the libtool project that *may* eventually >make all this easier. Gary Vaughan of the libtool group is up-to-date >on the ld--dll-search-prefix thing, and is aware of the cygfooX.dll >naming convention. If this naming convention is accepted, "they" will >probably try to support it seamlessly (I may be speaking out of turn, >but that's *my* impression of various messages.) I hope that this will come true; I am still waiting for their book to reach my local bookstore, cygwin+chuck-aware libtool should make porting much easier. Michael -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com