cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: sukender: curl/tests/libtest CMakeLists.txt,NONE,1.1

From: Sukender <suky0001_at_free.fr>
Date: Thu, 09 Apr 2009 01:27:45 +0200

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.

Well I mean adding CURL_EXTERN in front of Curl_hash_destroy and Curl_mk_dnscache.

>>> 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?

It doesn't seem...

I just added "USES_DIRECT_CURL_UTILITIES" in tests/server, and added
  #ifdef USES_DIRECT_CURL_UTILITIES
  #define CURL_EXTERN
  #else
  [...]
  #endif
in curl.h. That works perfectly. And guess what??? I don't have Curl_hash_destroy and Curl_mk_dnscache link errors now!!! That's unbeleivable.
I'd like to commit this... agreed?

-- 
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Received on 2009-04-09