Thanks Ian for the quick reply.
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.
Thanks,
Roopa
On Tue, Apr 14, 2009 at 8:16 PM, Ian Lance Taylor <iant@xxxxxxxxxx> wrote:
> Andrew Haley <aph@xxxxxxxxxx> 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.
>
> Ian
>
