Visibility patch for gcc (was Name clashes in shared libraries)

Peter S. Mazinger ps.m at gmx.net
Mon May 22 19:28:34 UTC 2006


On Mon, 22 May 2006, Josu Onandia wrote:

> 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).

cant recall any, but I am not sure if all archs had visibility support 
added in gcc-3.3.x, maybe the patches were only needed for gcc-3.4 due to 
some bugs

Peter 
> Thanks
> 
> Josu Onandia
> R & D
> Fagor Automation
> 
> 
> 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list