Name clashes in shared libraries

Peter S. Mazinger ps.m at gmx.net
Thu May 18 20:04:23 UTC 2006


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

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