Daniel Stenberg wrote:
On Thu, 9 Apr 2009, Sukender wrote:
... 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?
Yes, because when you build a DLL that DLL only exposes the functions we
have told it to expose. Curl_hash_destroy and Curl_mk_dnscache are not
on that list since they're private.
I thought the _USRDLL define meant "Export anything" under MSVC... it seems to
be wrong. Okay. So should we set those symbols public when CURL_HIDDEN_SYMBOLS is OFF?
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.
I don't see how you can make that work without one of these options:
A) you build a "test version" of the lib to run the test with
or
B) you use the plain source code for the lib558 tool, but in my view
that is
opening all gates to pain and misery since we don't write libcurl
source
code in general to be that easy to rip out and use sub-parts from so
it'll
pull dependencies that will differ over time and what not.
Totally agreed with B). So A) only remains. My knowledge of libcurl is limited,
so sorry if I'm a bit slow... Why can't we simply have:
1. CURL_HIDDEN_SYMBOLS is ON => "normal" lib => no 558, or
2. CURL_HIDDEN_SYMBOLS is OFF => lib with additional symbols => everything ok,
including 558?
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.
About that, can we simply set CURL_EXTERN to be void when a special define is
set (in test/server projects, which include .c file directly)?
( Or should we rename CURL_UTILITY_EXTERN to
CURL_EXTERN_BUT_NOT_IF_YOU_INCLUDE_LIB_FILES_DIRECTLY? ;D )
--
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
