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]

Re: DLL naming conventions


Paul Sokolovsky wrote:
> 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.

Well, Netscape Communicator actually uses 'jpeg3240.dll', but your point
about the GIMP is well taken.

> 
>     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.

Okay, a demonstrated problem.

>     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.

Hmmm....actually, you would if you truly wanted to support different
versions of a library that are incompatible at the source level (major
version number changes).  'Course, you'd also need to keep around
multiple versions of the header files....just too much work for me to
contemplate.

Nope. No version numbers on import libs. Not ever.

> 
> >> 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.

Well, the problem with libtool is that it's a developer's tool.  Take
the gettext package, for instance.  It uses some version of libtool that
does not understand cygwin/dlls.  The only way to 'fix' it is to replace
the libtool that is distributed WITH gettext, with a newer version.

See, libtool isn't a tool that lives on the end-user's system. It's a
couple of scripts that are distributed with each package that uses
libtool.  So, you've probably got 27 versions of libtool on your system
right now.

Perhaps the current version of libtool groks cygwin dlls. (In the 'old'
dlltool way; I'm positive it doesn't use 'gcc -shared').  But none of
the commonly-used libraries or applications out there USE the most
current libtool.

Should libtool support dlls on cygwin?  Yes, absolutely.  

Should it version the dll's with the major and minor version numbers,
but not the micro or pico version numbers?  Sure, as long as you can use
--no-versioning.  

Should it create dlls with a 'cyg' prefix when running on CYGWIN instead
of a 'lib' prefix?  Ummm...maybe, IMO.

See my other response in this thread, to Earnie Boyd (posted at 11:30am
EDT)

--Chuck

--
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]