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/