Re: Link to static library from DSO without exporting symbols?

[Paul Pluzhnikov]

"Boris" <boris@gtemail.net> writes:

> Paul Pluzhnikov wrote:
>> Assuming Linux, the answer is to use linker version script and
>> explicitly make only your "public" interface visible, hiding
>> everything else.
>
> Why is this so complicated? If I build a shared library like this:
>
> g++ -shared -o libfoo.so foo.o -lbar
>
> why doesn't the linker (I'm on Linux) hides automatically all the symbols 
> from libbar? 

Because it can't know that's what you wanted it to do.
Linking against archive library is almost the same as linking
against an object. Should it also hide all objects from foo.o
as well, and export nothing at all?

> Isn't it safe to assume that libfoo probably wants to get 
> linked to some symbols in libbar but does not want to export these symbols? 

Not at all. A lot of people build their DSOs like this:

- compile a bunch of sources in multiple directories into src1.a, src2.a, etc.
- link them all into giant DSO like this:

  ld -shared -o giant.so --whole-archive src1.a src2.a --no-whole-archive

In this case, the user explicitly wants to have everything in src*.a
to be included and exported from giant.so

> In my example where I link a shared library to the Expat XML parser I want 
> to make use of some functions from Expat and not create a shared library 
> which among others provides the same functions as Expat does already.

So why are you linking agains libExpat.a ?
Link against libExpat.so instead.

You probably want to use code from Expat, do not want to force
the user to link agains libExpat.so, and do not want that code
to conflict with potentially different version of Expat that the
user might link against, and you want the static linker to guess your
intent. 

Tough luck. You'll have to explicitly tell the linker what your
intent is.

> What's 
> the rationale of exporting all symbols by default?

The rationale is that shared libraries should work just as archive
libraries did. When you do 'ar r foo.a foo.o bar.o' foo.a has
everything that foo.o and bar.o had. So 'ld -shared -o foo.so foo.o bar.o' 
should do the same. And as I said, from linker perspective there
is not buch difference between 'ld -shared -o foo.so foo.o bar.o' and
'ld -shared -o foo.so foo.o bar.a'

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.