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