delorie.com/archives/browse.cgi | search |
Mailing-List: | contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm |
Sender: | cygwin-apps-owner AT sourceware DOT cygnus DOT com |
List-Subscribe: | <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com> |
List-Archive: | <http://sources.redhat.com/ml/cygwin-apps/> |
List-Post: | <mailto:cygwin-apps AT sources DOT redhat DOT com> |
List-Help: | <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs> |
Delivered-To: | mailing list cygwin-apps AT sources DOT redhat DOT com |
Message-ID: | <3BC726E8.8000404@ece.gatech.edu> |
Date: | Fri, 12 Oct 2001 13:22:48 -0400 |
From: | Charles Wilson <cwilson AT ece DOT gatech DOT edu> |
User-Agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 |
X-Accept-Language: | en-us |
MIME-Version: | 1.0 |
To: | "Roth, Kevin P." <KPRoth AT MarathonOil DOT com> |
CC: | cygwin-apps AT cygwin DOT com |
Subject: | Re: curl, libcurl, libcomprex, leakbug (was:Re: Packaging cURL for cygwin distribution ???) |
References: | <6EB31774D39507408D04392F40A10B2BC1FD6D AT FDYEXC202 DOT mgroupnet DOT com> |
Versioning for DLLs is important. Search the archives for more info; these threads should get you started -- but be prepared for a lot of reading... http://www.cygwin.com/ml/cygwin/2000-08/msg01128.html http://www.cygwin.com/ml/cygwin-apps/2001-03/msg00011.html http://www.cygwin.com/ml/cygwin/2000-10/msg01275.html http://www.cygwin.com/ml/cygwin-xfree/2001-q3/msg00432.html http://www.gnu.org/software/libtool/manual.html#Versioning Also: >> > > [libtool] should >> > > probably name [dll's] after the oldest ``interface'' (see the document >> > > quoted above) that the library fully supports. That is, if you build >> > > a dll using libtool's --version 5:4:3, you would get library2.dll >> >> 5:4:3 is revision 4 of the implementation of interface 5, which >> is backwards compatible with the 3 previous interface definitions >> (i.e. it is safe for applications linked against interfaces 5, 4, 3 >> and 2 to load the 5:4:3 dll at runtime). Libtool translates the >> 5:4:3 into a system specific version number for the soname to help the >> runtime loadee choose the best available library at runtime. As I >> said before, currently this mapping is wrong on Windows, > > ======== Robert's hacked libtool seems to use the "correct" mapping, > below, on windows. > >> and I think >> the correct mapping is to always use the oldest supported interface >> number -- in this case library2.dll -- when generating the soname. >> This is explained fully in the version node of the libtool manual link >> that was quoted earlier in the thread. The upshot of all this is that libraries should follow this naming scheme: static lib: /usr/lib/libfoo.a import lib: /usr/lib/libfoo.dll.a dynamic lib: /usr/bin/cygfoo<VER>.dll or /usr/bin/cygfoo-<VER>.dll --Chuck > I noticed your example had a DLL name of cygcurl-2.dll. The DLLs (and > libs) from the mingw version are named: > 137134 09-25-01 03:21 libcurl.a > 771 09-25-01 03:01 libcurl.def > 140524 09-25-01 03:25 libcurl.dll > 19726 09-25-01 03:25 libcurldll.a > Is there any specific reason to use cygcurl-2.dll instead of > libcurl.dll? If so, could you either explain the reason to me or point > me to a previous discussion of this issue (or both)?
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |