Hi John,
John E. Malmberg schrieb:
> On VMS, for a shared library image, you have to use an explicit list of
> public symbols that will be visible for compile time linking.
>
> For upward compatibility, newer entries are always added to the end of
> the list, and the existing entries can not change in order. That way
> newer shared images can replace older ones with out relinking any of the
> applications that use them.
>
> In setting up a shared library image for libcurl, I noticed that the
> curl program for 7.19.5 is referencing two non-public symbols:
>
> Curl_raw_equal and Curl_raw_nequal. In order for me to have curl use
> the shared library instead of a privately linked copy, I have to also
> make those symbols public.
>
> Is it intentional that the curl program not be able to use the shared
> image?
no. You just need to link lib/rawstr.c to the curl executable;
see src/Makefile.inc:
# libcurl has sources that provide functions named curlx_* that aren't
part of
# the official API, but we re-use the code here to avoid duplication.
CURLX_ONES = $(top_srcdir)/lib/strtoofft.c \
        $(top_srcdir)/lib/strdup.c \
        $(top_srcdir)/lib/rawstr.c

perhaps you can make use of the Makefile.inc within your build process?

> Or should I make those symbols public in the shared image that I will be
> kitting up?
no, I dont think so.

> Several of the tests/libtests modules also reference non-public symbols.
> For unit tests, I can see that those would be limited to development,
> so there is no need to have those symbols exposed.
same here: they link the above mentioned files in.

Günter.
Received on 2009-06-03