RE: curl, libcurl, libcomprex, leakbug (was:Re: Packaging cURL for cygwin distribution ???)

["Gerrit P. Haase" <freeweb at nyckelpiga dot de>]

> Roth, Kevin P. schrieb am 2001-10-12 12:50:

>>> Gerrit P. Haase schrieb am 2001-10-12 14:08:
>>>But we will figure out how to build them:)
>
>Wow! Vielen dank (...thanks...) for taking the time to do this. I have
>almost zero knowledge/understanding of these tools (autoconf, libtool,
>etc) and as such would not have come up with this "fix" for creating a
>DLL.

I read the autobook (partially). http://sources.redhat.com/autobook/

>For what it's worth, the guy who maintains the minGW build of cURL
>seems to use a different strategy, though I don't really know how
>different the final outcome is. (From looking, he appears to use a pair
>of custom Makefile.m32 files in the lib/ and src/ directories)

The minGW maintainer creates the .dll's 'manually' from the static lib with
'dllwrap'.

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

'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.

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.

>Also: thank you Gerrit for copying me on your most recent email, since
>I'm not on the cygwin-apps list (apparently it's by invite only). Also,
>thank you Christopher for the compliments. Yes, this was my first post,
>and I'm sure I learned more by scouring through the archives than I
>would have by asking dumb questions and getting tired, battle-weary
>answers (if I got any at all)...
>
>
>I am willing to be the person that compiles and uploads new cygwin
>tarballs for cURL (to the curl downloads page, from which perhaps
>Christopher or Corinna can grab them). They seem to be coming out every
>month or so lately. But if one of you would rather subscribe to the
>curl-announce list, and be responsible for compiling new versions for
>cygwin, that would be fine with me too ;-)

Yes, please do so.  

>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.

As you mention above, there are 'special' Makefiles for mingw, and if
all the autotool problems are solved, it should work for all platforms.

There are still some issues. Autoconf, automake and libtool are not 
100% compatible and not 100% bugfree (unfortunately), IMHO.
And there are also other ways to create dll's which works since a long
time now.  cURL package is full libtoolized and they use also
autoconf 2.52 so it was the easiest way to add a macro to configure.in
and the LDFLAG to Makefile.am, but i also needed to remove one macro call
in configure.in and then there is this problem that there is passed
a flag (--no-verify) to ltconfig during configuring libcomprex.
I suggest this is a bug in libtool, but I don't know.

>I will also ask if he has any suggestions on how best to go about
>setting up the automated Cygwin tarball creation process (I'll try to
>summarize the rules for him). But if he and I have further questions, do
>you mind if I shoot a note back to you (and/or cygwin-apps) for more
>info?

Depends on where you want to compile it, cross-compilation is a special
issue where i cannot help much because I don't use linux (nowadays).

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

It is not important how the dll is named, as long as libtool is used.
The executables know how their dll is named to find it.
Also these names were 'created' by libtool.
And it is a 'standard' for cygwin, the static lib is called lib...a
the importlib is called lib...dll.a the def is called lib...def and
the dll is called cyg..-0.dll 
Libtool uses the file lib...la to look for the names.

It was discussed before I played with cygwin, maybe you find s.th.
in the archives. (cygwin or libtool).

Gerrit

-- 
=^..^=