Visibility patch for gcc (was Name clashes in shared libraries)
Josu Onandia
jonandia at fagorautomation.es
Mon May 22 12:37:17 UTC 2006
Peter S. Mazinger wrote:
>On Thu, 18 May 2006, Carl Miller wrote:
>
>
>
>>On Thu, May 18, 2006 at 11:29:45AM +0200, Josu Onandia wrote:
>>
>>
>>>Hi all,
>>>
>>>I have a problem using shared libraries on an embedded powerpc target.
>>>I'm porting a legacy project that has a very large library (5MB of stripped
>>>code, 112MB with full symbol information). I was having some trouble
>>>because gcc makes
>>>all the functions of the library *public* by *default*. This is problematic
>>>when inside
>>>the library and inside the application there are functions with the same
>>>name. You
>>>don't get an error such as 'Duplicated symbol', so everything seems ok
>>>(this is not
>>>safe, in my opinion), and the application actually gets loaded and starts
>>>execution,
>>>but when one of those functions is called inside the library, it is the
>>>function
>>>that is inside the application the one that is called.
>>>
>>>I've read that there is a way of controlling what symbols are exported from
>>>inside the library. With the option -Wl,--version-script=library.map
>>>'library.map' being a file like *this*:
>>>
>>> {
>>> global: sample_function;
>>> local: *;
>>> };
>>>
>>>This is supposed to make the function 'sample_function' *public* and the
>>>rest *private*.
>>>
>>>
>>I've not used the version-script option to ld before, but I've achieved
>>the results you're looking for by using gcc's visibility attribute in
>>my shared library code.
>>
>>This page explains it (scroll down to the section on "visibility"):
>>http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Function-Attributes.html
>>
>>Although this page is heavily C++ oriented, it's got some good
>>discussion and examples of using visibility attributes in code, that
>>are largely just as applicable to C:
>>http://gcc.gnu.org/wiki/Visibility
>>
>>
>> -----Carl
>>
>>
>
>If you want to use "visibility", look around for patches for your gcc
>version (different distros use them).
>
>Peter
>
>
>
Thank you, for your comments.
It is quite clear to me that the toolchain has a bug handling the
'version-script' with a large library and a big relocation table. It
seems that it hits some limit somewhere: compiler, linker, loader, or
whatever.
But I wont follow this path. Your suggestion of using the 'visibility'
flag sounds much better.
Now, the problem is that we are still using using powerpc-linux-gcc
3.3.6, and I only find patches for version 3.4.0.
Anybody knows of a visibility patch for gcc 3.3.6? I've been reading
the patch, and the backporting to 3.3.6 is not evident (to me).
Thanks
Josu Onandia
R & D
Fagor Automation
More information about the uClibc
mailing list