DLL naming conventions

[Paul Sokolovsky]

Hello Charles,

Charles Wilson <cwilson@ece.gatech.edu> wrote:

CW> Paul Sokolovsky wrote:
>>
>> Hello cygwin,
>>
>>   Existance of several GNU targets based on incompatible underlying
>> libraries brings (or will bring soon) problem of clashes between their
>> components. Mere installing software build with each of them into
>> separate directory and setting PATH to one of the in per-session
>> manner is not flexible since often one piece of software absent in
>> that or another distribution. Of particular importance here is
>> clashing of DLLs which is espicially hard to detect for end users. It
>> would be nice if there were some convention for naming DLLs build for
>> particular target. Cygwin did that for a some time, for example,
>> native builds of Tcl/Tk, etc. used to have 'cyg' prefix. However,
>> latest additions seem not to follow this practise.

CW> Yup, I know.  Most the latest additions which have dll's were ones that
CW> I ported.

    Exactly contemplating your releases, as well as my own activity of
doing same for mingw32, made me to raise this question.

CW>   I did not want dependent packages to be required to modify
CW> their makefiles to use '-lcygtiff' or worse yet, '-lcygtiff35' when a
CW> plain '-ltiff' is already there and works.

    Neither I even consider possibility to changes like that. If
something uses -ltiff on any other system, it will use -ltiff on
cygwin, mingw32, whatever. Period. I'm surprised that you considered
such possibility to the end of your mail, not from the very
beginning.

CW>   I haven't seen too many reports of actual
CW> problems with windows dlls clashing with cygwin dlls; several folks have
CW> mentioned that 'it could happen, we should fix it before it does' but
CW> nobody has *actually* had it happen to them.

    I'm yet another such person with cassandristic attitudes. However,
I can point the problem spot more precisely: just as you provide
zlib/libjpeg/libpng/libtiff for cygwin, I'm doing that for mingw32
( http://mingwrep.sourceforge.net )

CW> I've no interest in fixing a problem (and causing many many more
CW> problems) when the initial problem has not been demonstrated to affect
CW> real users.

    Depending on different objective and subjective reasons, Tor
Lillqvist might use my builds in his GIMP-win32 distribution. I tried
to use versioned names for my libpng.2.1.dll (2.1 is *interface* name,
from README) and libjpeg.6.dll (I can point you where libjpeg.dll
already used: in Netscape Nav.). However, for libz.dll and libtiff.dll
it is not. Zlib has rock-solid API and I don't want to clutter dll
with any numbers. For libtiff, there's that stupid LZW problem. I
would like to have LZW-less dll to drop-in-replacable by LZW-contating
one, so they'd better not to have versioning numbers.

    Ok, now suppose you installed some cygwin-hosted tool on computer
of secretary in your firm. Also, she's cool enough to prefer GIMP to
PhotoShop and she installed it. Suppose both dlls get on PATH (for
example, cygwin's was put by you, and GIMP's stupid shrink-wrapped
installer drop its to windows/system). Poor user.

CW> One less intrusive possibility I have thought of is:
CW>   import lib:  libtiff{ver?}.dll.a (built with
CW> --dllname=cyglibtiff{ver?}.dll)
CW>   dll       :  cyglibtiff{ver?}.dll

CW> If this is done, then you no longer can link directly to the dll
CW> (without changing the makefile to say '-lcyglibtiff{ver}',  but
CW> ordinarily you'd link using the import lib so everything would be ok,
CW> and you can still use '-ltiff' in the makefile.

    Note, that my very question is about whether Cygwin people want
that to be automatically supported by libtool. I appreciate you
attention and comprehensive discussion, but I'll understand if you'll
simply say "I won't do that". But returning back to libtool, you wan't
be able to link directly to libtool-generated dll that way since it's by
default includes versioning info. And as you understand, FAQ entry
with "you've got to use --no-versioning switch to libtool when
building DLLs with cygwin" won't help. So, staying with implibs for
linking is only feasible alternative.

CW> I'm not really in favor of using version numbers on shared libs,  since
CW> you'd also have to version the import libs also

    As you know, you wouldn't and shouldn't.

>> More importantly, it can be automatically
>> supported on appropriate level (in libtool).

CW> No, it can't.

   ???

CW>  Currently, libtool itself doesn't support *building* dlls.

     Well, to be precise it *does*. In rather ungroundly complicated
way. But - it's currently. My port of libtool for pw32 does it
far more seamlessly. And, before going for inclusion these changes
into official distribution, I'd like it to work for all GNU/Win32
targets, not only mine.

CW>   Also, you are assuming that every package that depends on
CW> dll-ized libraries uses libtool in its build process.  While that would
CW> be great, it is not true.  Unfortunately, *very* few packages use
CW> libtool, in my experience.

    Once again, I have no ambition to force maintainers of not
configure-enabled libs to change namings of their dlls - that's up to
their own consideration, reasons was presented and discussed.

CW> Comments, anyone?

CW> --Chuck


--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com