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