From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Sokolovsky To: Charles Wilson Cc: cygwin@sources.redhat.com Subject: Re[2]: DLL naming conventions Date: Thu, 31 Aug 2000 05:07:00 -0000 Message-id: <3623.000831@is.lg.ua> References: <39AD1F78.4F5EAABE@ece.gatech.edu> X-SW-Source: 2000-08/msg01189.html Hello Charles, Charles Wilson 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