cURL / Mailing Lists / curl-library / Single Mail

curl-library

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

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 8 Apr 2009 23:47:32 +0200 (CEST)

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?

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

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?

-- 
  / daniel.haxx.se
Received on 2009-04-08