Daniel Stenberg wrote:
> On Thu, 9 Apr 2009, Sukender wrote:
>
>>> 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.
>
> Don't take my word for absolute truth when it concerns anything
> windows-related. I don't use nor develop for windows. Someone else is
> likely to know a lot better than me on this subject.
>
>> Okay. So should we set those symbols public when CURL_HIDDEN_SYMBOLS
>> is OFF?
>
> Set which symbols public? In *nix land ALL global symbols typically get
> public then so there's no effort involved.
>
>>> 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
>
>> 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?
>
> Yes, that 2) is the same as the A) I wrote. It is a special build made
> to work with the tests.
>
> The question is then, how do you make that special build so that it
> exposes the necessary functions? If we say "static lib" there's nothing
> needed to change. If we say "DLL" we need to invent a way to mark some
> functions to get exported when they are used in these special builds.

Oh crap! Forget about the "Yeepee it works" in my previous mail... I simply had CURL_HIDDEN_SYMBOLS to ON...
So, what about putting a CURL_EXTERN in front of Curl_hash_destroy and Curl_mk_dnscache when CURL_HIDDEN_SYMBOLS is OFF?

-- 
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/