Bugs item #3016471, was opened at 2010-06-15 12:17
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3016471&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: compile or build problem
Group: portability problem
>Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Volker Grabsch (vog)
Assigned to: Daniel Stenberg (bagder)
Summary: missing symbol CURL_STATICLIB

Initial Comment:
When CURL is compiled with "--disable-shared" and/or "--enable-static", the CURL_STATICLIB symbol is expected to be defined. However, it isn't. So every static build of CURL for Windows fails because of inappropriate dllimport/dllexport declarations in the CURL headers.

The attached patch fixes that issue by adding the missing stub for CURL_STATICLIB to curlbuild.h.in.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-07-05 02:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-06-20 20:39

Message:
I believe the current way is better than your suggested way, even if
certainly don't clain that it is a perfect solution.

You seem to totally ignore the default case for how libcurl is built: both
a static and dynamic lib is produced (and how would that leave the
headers?). The choice is then left to the user to pick which model they
want on their link command line. This is default action with libtool for
hundreds, if not thousands, of existing libs today. This is nothing we in
the curl project have invented. You claim that "Usually, one is interested
in only one of them" but I say that is just your naive view and is
certainly not in any way reflecting how users all over are viewing this.

Unfortunately, the main culprit for this awkward solution is that Windows
is a broken environment so that we cannot easily use the same header and
source for both link libraries and shared libraries.

The test programs within the curl built are no reason at all for this
solution. No matter how we'd end up, we could figure out a working way for
the test programs.

So please. Even if you don't want this behavior, you must accept that this
is the default and accepted behaviors since a long time back for libraries.
Changing our concept must be in compliance with that, and the way you
suggested is not. Sorry.

Again, I don't think our current concept is desirable, but so far we don't
have any better solution that works.

----------------------------------------------------------------------

Comment By: Volker Grabsch (vog)
Date: 2010-06-20 02:04

Message:
Sorry, I don't see any better solution.

However, I also don't see the problem. When cURL is compiled with
"--disable-shared" then it is perfectly okay if the headers work with
static builds only, isn't it? (BTW, this is what we do in the
Mingw-cross-env project.)

Also, what's the purpose of having a static and shared library
side-by-side? Usually, one is interested in only one of them.

The only scenario where I see that mix is the cURL test programs, and even
there it is not really necessary. The test programs are linked statically
to cURL even when a shared library is requested. I would feel better if the
test programs would use the shared library if it's that what will actually
be used by the end user.

Anyway, that's just my personal thoughts. Feel free to ignore them if I'm
wrong.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-06-18 21:15

Message:
I don't see any solution to this problem other than what we already have.
If you have other ideas, feel free to bring them on.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-06-16 21:37

Message:
Sorry, but your suggested patch suddenly makes the headers force and assume
that nothing but static can or will be built using the public headers, and
that's an assumption we can't have.

The same set of headers can indeed be used for both static and dynamic
build.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3016471&group_id=976
Received on 2010-07-05