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>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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)?