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/
