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 Message-ID: <39AE7E06.CEFB0BC8@ece.gatech.edu> Date: Thu, 31 Aug 2000 11:47:18 -0400 From: "Charles S. Wilson" X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Earnie Boyd CC: cygwin AT sources DOT redhat DOT com Subject: Re: DLL naming conventions References: <20000831133952 DOT 21477 DOT qmail AT web123 DOT yahoomail DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Earnie Boyd wrote: > > As Chris already pointed out, the solution to this for Cygwin is: > > For any official cygwin/latest or cygwin/contrib package release the: > package should be configured with --prefix=/usr > .dll should goto /usr/bin. > .a should goto /usr/lib. > no versioning controls on the names of the libraries. But Paul is suggesting that the prefix for dll's be changed so that the foo library is named: libfoo.dll.a (import lib) libfoo.a (static lib) cygfoo23.dll This will not affect build procedures at all, since -lfoo will find libfoo.dll.a (which was built with '--dll-name=cygfoo23.dll' option), and '-lfoo -static' will find libfoo.a. The versioning of the dll will affect upgradability IMO. Not even Paul is suggesting that the version number change based on pico or micro level library changes ( libfoo version X.Y.Z-A --> version X.Y.Z-(A+1) or version X.Y.(Z+1)-A would still have the same version number: libfoo.X.Y.dll ). This is because only the major and minor version numbers mean that the interface has changed: X means source-level incompatiblity: libfoo version X+1 will not ever work with a package 'BAR' written for libfoo version X, unless you modify 'BAR's source. Y means object-level incompatibility: libfoo version X.Y+1 can be used with package 'BAR', but you'll have to relink/recompile BAR for that to work. You can't 'slipstream' libfoo version X.Y+1 and expect BAR to work. With that understanding, I think that versioning the DLL's *only* based on X.Y is okay. (I suppose the "right" thing is to also version the import libs based on X, but I just don't have the energy for that...) Now, the use of the 'cyg' prefix instead of the 'lib' prefix -- for DLL's *only*, not import libs -- is a whole 'nother can of worms. See below. > > For any unoffical cygwin package release the: > package should be configured with --prefix=/usr/local/package-x.x.x. > .dll should goto /usr/local/package-x.x.x/bin. > .a should goto /usr/local/package-x.x.x/lib. > .exe should goto /usr/local/package-x.x.x/bin. > .info should goto /usr/local/package-x.x.x/doc/info. > man files should goto /usr/local/package-x.x.x/doc/man. > html files should goto /usr/local/package-x.x.x/doc/html. > etc. > no versioning controls of the names of the libraries I'm not so sure about the versioning controls on DLL's, here, either. > unless the > libraries use shared memory regions that may conflict with other libraries of > the same name. Okay, now I am confused. If two libraries have the same name, don't they automatically conflict? Windows loads the first one it finds into memory, and every executable thereafter will use that copy, right? Suppose the following: The native Win32 port of GIMP uses libz.dll and libtiff.dll (compiled natively, so no dependence on cygwin1.dll). Tor Lillqvist distributes libz.dll and libtiff.dll bundled with his native Win32 GIMP (installed into the same directory as the executable). Clearly, these two dlls are incompatible with the cygwin libraries of the same name, and vice versa. I built a cygwin XEmacs that depends on the cygwin libz.dll and libtiff.dll. Now, I run GIMP. Naturally, since the windows dynamic loader looks in the directory of the executable before searching the path for any dynamic dependencies, the GIMP/windows-native versions of libz.dll and libtiff.dll are loaded into memory. Then, I run cygwin-XEmacs. Does the windows loader even try to locate libz.dll or libtiff.dll -- or does it just use the (windows-native) ones in memory? Or does it try to load them, and not finding them in the xemacs executable directory, searches the path and finds them in /usr/bin and loads the cygwin-versions? If the windows loader DOES load the cygwin-versions, do they then conflict in memory -- or do they conflict only if they use shared memory regions.... How do you tell if a dll uses shared memory regions? -------- Anyway, the more I ponder, the more I think using 'cyg' prefix on dll's is a good idea -- Chris's objections notwithstanding. Yes, cygwin was here first. But, by sticking to the 'libfoo.dll' name, we rely on the good nature of the other unix-on-windows layers to not interfere with us. Or that other application packages will not interfere with us. Personally, I don't trust 'em. :-) If we use a 'cyg' prefix, then its VERY unlikely any external executable or package will ever screw up a cygwin installation through dll conflicts. We may, however, need to submit another patch to ld, so that we restore the ability to link directly to dll's -- e.g. make ld 'know' about the cyg prefix. (This argument is based on the supposition that dll's with the same name will always conflict. If I'm wrong about that supposition, please correct me...as I stated above, I'm a bit confused as to when dll's will conflict and when they will not) --Chuck -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com