Re: sukender: curl/tests/libtest CMakeLists.txt,NONE,1.1
Date: Thu, 09 Apr 2009 00:31:25 +0200
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
> 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
> code in general to be that easy to rip out and use sub-parts from so
> 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
>>> #define CURL_UTILITY_EXTERN CURL_EXTERN
>>> 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);
>>> 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/Received on 2009-04-09