This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

AW: DLL naming flamefest


>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=<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.)
>  <prefix>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 -->

<flame-retardant underwear OFF>
<lexan faceshield OFF>
<asbestos firesuit OFF>

>  (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@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]