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: Thu, 09 Apr 2009 00:04:59 +0200

Daniel Stenberg wrote:
> On Wed, 8 Apr 2009, Sukender wrote:
>
>> In curl.h, line 100 the code looks like:
>
> [..]
>
>> My question is: why don't CURL_HIDDEN_SYMBOLS is tested when we're in
>> Win32 DLL? Isn't there something missing here?
>
> Sorry but I don't understand. What would check for CURL_HIDDEN_SYMBOLS
> when we build a win32 DLL?

Hmmm... This was jus a remark. I thought there could be something missing. But it seems not...

>> And about the define to avoid DLL linkage problem, I suggest:
>> #ifdef USES_DIRECT_CURL_UTILITIES
>> #define CURL_UTILITY_EXTERN
>> #else
>> #define CURL_UTILITY_EXTERN CURL_EXTERN
>> #endif
>>
>> And changing CURL_EXTERN to CURL_UTILITY_EXTERN when needed. For
>> example with curl_strequal, we would change:
>> CURL_EXTERN int (curl_strequal)(const char *s1, const char *s2);
>> to
>> CURL_UTILITY_EXTERN int (curl_strequal)(const char *s1, const char *s2);
>>
>> But that's not clear if it sounds coherent with my first remark... Any
>> idea?
>
> Well, first I would find the term CURL_UTILITY_EXTERN quite strange.
> What does it mean? And in this particular example, why would that need
> to be modified? It is already exported!

Actually, for tests/server these must not be exported (since the .c files are included in the test, without linking to libcurl). So the goal was to add a define in tests/server projects so that the CURL_EXTERN (or equivalent) becomes empty.

> But for functions that are not external for "normal" DLLs (like the ones
> used in lib558.c) I can see how we can possibly want to make them marked
> with "magic markers" but then I'd prefer them to be something like
> CURL_EXTERN_FOR_TEST or similar that gives away slightly more clues on
> what the purpose is.
>
> ... of course if you build a special build for the test _anyway_, why
> can't you instead make that build a static lib and then we won't need a
> work-around at all?

For lib558, the problem is a bit different. The linker doesn't find some symbols, like Curl_hash_destroy and Curl_mk_dnscache. Any idea why?

I don't care about building lib558 only when using a static lib, but I thing CMake scripts should work in most cases, and I guess we're not far from making it run with lib558+DLL.

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