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.
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)?
Don't we already have this ability?
--
/ daniel.haxx.se
