Re: Shared library linking to Static library

[Andrew Haley <aph at redhat dot com>]

Roopa V wrote:

> On Tue, Apr 14, 2009 at 8:16 PM, Ian Lance Taylor <iant@google.com> wrote:
>> Andrew Haley <aph@redhat.com> writes:
>>
>>> Roopa V wrote:
>>>
>>>> I have an application which links to two libraries, a static library,
>>>> “libstatic.a” and a dynamic library, “libdynamic.so”. The shared
>>>> object “libdynamic.so” also internally links to “libstatic.a”. A
>>>> global variable is defined in libstatic.a and is accessed in both test
>>>> application and libdynamic.so. I'm exporting required symbols of
>>>> libdynamic.so to the application using libdynamic.map file with
>>>> --version-scripts linker option. libdynamic.map file is defined as:
>>>> {
>>>> global:
>>>> operation_*;
>>>> local:
>>>> *;
>>>> };
>>>>
>>>> This creates two copies of libstatic in the memory. libdynamic shared
>>>> object uses its own "private copy" of libstatic.
>>> That's very odd.  Are you sure that everyone exports the global variable?
>>> As long as they do, the dynamic linker should fix everything to point to
>>> the same variable.
>> Presumably the variables coming from libstatic are not named
>> operation_*, and as such are treated as local within libdynamic.
>>
>> One approach to solve this problem is to simply not link libdynamic
>> against libstatic, and to instead let libdynamic pull the symbols from
>> the main executable.  Another approach is to add the symbols from
>> libstatic to your version script as global symbols.

> I have tried both the approaches. Approach 1 will have libdynamic
> compatibility issue. The libstatic library is not backward compatible
> and libdynamic promises backward compatibility.
> If libdynamic uses libstatic APIs which are not supported in its older
> versions of libstatic and application links to older libstatic, then
> libdynamic will not be able to resolve its libstatic symbols. So as
> per the design, libdynamic shared library is advised to carry its
> libstatic with it. Is there any linker option which overrides global
> precedence over local scope?
> 
> With the approach 2, I have to keep track of all global symbols of
> libstatic library in the future and export them in the libdynamic
> export file. Maintainability will be a problem. libstatic.a is the
> static library which provides some common functionalities which are
> used by both the application and libdynamic library.
> 
> I have also tried undefining libstatic symbols in libdynamic so that
> they resolve at link time of the application. This can be done using
> ld linker option --undefined=symbol, but this is not working for me.

Your requirements are self-contradictory.  On the one hand, you want
the changes done to global variables of libstatic by the application
to be reflected in libdynamic.so, and on the other hand you want to be
able to use two incompatible versions of libstatic.

It's traditional on this list to help people do what they want
regardless of whether it's a good idea, but in your case I think it
would be the wrong thing to do.  It is far better in the long run to
tell you the truth:

Your design is completely broken.

Ian Taylor, being a nice guy, has been trying to help you do what you
want, but it's not in your real best interests.  As you said,
"Maintainability will be a problem.".  Well, yes, it will.  If you
carry out this plan you'll end up with something difficult to maintain
and horrible to debug.

Andrew.