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: <3BC73F2F.6050105@ece.gatech.edu>
Date: Fri, 12 Oct 2001 15:06:23 -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: cygwin-apps AT cygwin DOT com
CC: "Roth, Kevin P." <KPRoth AT MarathonOil DOT com>
Subject: Re: curl, libcurl, libcomprex, leakbug (was:Re: Packaging cURL for cygwin distribution ???)
References: <3BC750FE DOT 23291 DOT 2229240 AT localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Gerrit P. Haase wrote:

> 
> libtool uses the new gcc feature '-shared' to create the dll:
> gcc -shared  $(OBJECTS) -lssl -lcrypto -o .libs/cygcurl-2.dll \
>   -Wl,--image-base=0x10000000 -Wl,--out-implib,.libs/libcurl.dll.a
> 
> But it always uses the default image-base (where can I toggle this?).


Don't bother.  DLL relocation doesn't take much time, and using other 
algorithms to pick an image base other than 0x10000000 can lead to 
conflicts with cygwin1.dll.  Just let it be.  (Search the archives for 
"image base" and "Robert Collins" for more information.

 
> 'dllwrap' is an older tool the makes it easier, now gcc supports the -shared 
> option it works without dllwrap, too.
> There is more about this way in the cygin-user-guide.


cygwin-user-guide is way out of date on this subject.

> 
> But there is still more, take a look at the dllhelpers:
> http://www.neuro.gatech.edu/users/cwilson/cygutils/V1.1/dll-stuff/
> 
> I'm not up to date with the c++ issues, there are still some problems I guess.
> 


>>I will ask the curl maintainer (Daniel Stenberg) to add in your changes
>>(-no-undefined and AC_LIBTOOL_WIN32_DLL), and see whether he has any
>>problem with that. This package is also actively built using minGW, so
>>I'm hoping those changes don't conflict in any way with the minGW
>>builds.
>>


I'm not real clear on *very* recent changes to libtool.  I know that 
libtool-1.4 supports DLL-building on cygwin in the goat book style, 
which requires AC_LIBTOOL_WIN32_DLL and such.  HOWEVER, that was *prior* 
to the auto-import changes to binutils.

These binutils changes make it easier to build *cygwin* DLLs without 
AC_LIBTOOLS_WIN32_DLL -- I think.  Robert Collins has a hacked up 
version of libtool 
(http://www.neuro.gatech.edu/users/cwilson/cygutils/robert-collins) that 
takes advantage of this.  Gary Vaughan (libtool maintainer) is 
interested in these improvements and wants to fold them in to the 
development versions of libtools -- but I do not know what the status of 
that is, yet.

I was active in pushing the improvements into binutils, and pushing 
Corinna to release up-to-date versions of autoconf and automake -- and 
then I was going to get back with Gary on the libtool issues.  However, 
there are reasons to retain the older versions of autoconf and automake, 
so I am currently attempted to create a set of scripts to allow both 
autoconf-2.13 and autoconf-2.5x to coexist. (Ditto automake-1.4p5 and 
automake-1.5).  Once that's done, then I'll get back in touch with Gary 
on the libtool issues.

Point: building DLLs on cygwin, using libtool, is currently in flux.

--Chuck