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/
