cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: sukender: curl/tests/libtest CMakeLists.txt,NONE,1.1

From: Sukender <suky0001_at_free.fr>
Date: Wed, 08 Apr 2009 10:09:21 +0200

Le Tue, 07 Apr 2009 19:45:37 +0200, Daniel Stenberg <daniel_at_haxx.se> a écrit:

> On Tue, 7 Apr 2009, Sukender wrote:
>
>>> Ah right. I had forgot about that. The test has an #ifdef for
>>> CURL_HIDDEN_SYMBOLS so if the internal symbols are not available that
>>> define should be set.
>>
>> Errr.... well, should I always set it or not, then? I mean I don't really
>> understand the reason for defining CURL_HIDDEN_SYMBOLS or not since Bill's
>> config and mine seem similar. The "internal symbols" should be available on
>> both configs, shouldn't they?
>
> In the configure script, --enable-hidden-symbols will make libcurl only expose
> truly public symbols and then CURL_HIDDEN_SYMBOLS gets defined. Two
> "hardcoded" config-*.h files seem to also define it.
>
>

Hi Daniel,

I got a problem with Win32:
    CURL_EXTERN int curl_mprintf(const char *format, ...);
The printf-like functions are defined "CURL_EXTERN", that is to say "__declspec(dllimport)" when building /curl or /tests (and with a dynamic libcurl). When including mprintf.c in tests/server targets, then the function is in the test source and thus "__declspec(dllimport)" has nothing to do here.

I'm not really sure about chat to remove/change. Do you have an idea? Should we use a special flag that means "I'm using directly mprintf.c, so don't set printf-like functions to be imported"?

-- 
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Received on 2009-04-08