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