[uClibc] Re: Issues with ".hidden" libgcc symbols in soft-float code

Peter S. Mazinger ps.m at gmx.net
Wed Sep 24 18:39:06 UTC 2003



> - After correcting the above issue, I built the gcc-3.3.1 toolchain and uClibc libraries using Erik Andersen's build scripts, building shared libraries and selecting "INCLUDE_LIBGCC_SYMBOLS" in the uClibc configuration, and found that the libgcc symbols are in fact included in the resulting libc (verified using nm and objdump). However, these come with the ".hidden" attribute that's included in the gcc-3.3.1 libgcc. This wouldn't be a problem except that libm uses some of these symbols as well; normally, libm would be able to resolve these through libc, but with the hidden attribute libm can't use these.
> 
> 
> Can anyone suggest the best approach to resolving this issue? I can think of two: 
> - finding a way to have the included libgcc symbols not use the ".hidden" attribute (but I don't know how to do this, or if it would be a good thing to do...)
> - modify the get-needed-libgcc-objects script to transfer the libgcc stuff into libm as well as libc; but I don't know if there are other libs that would need these as well, and it seems wasteful to include multiple copies of libgcc stuff...
The same happened to me on i386, trying to use gcc with propolice patch 
and the smash-protector code went from libgcc as hidden into libc.so.0.
Reported earlier, some of the apps cannot be built anymore.

Maybe this is rubbish:
What would it be to activate /etc/ld.so.preload code and use a separate 
library for these that is preloaded (or preload libgcc.so), without 
putting the code into libc.so?

Peter

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


____________________________________________________________________
Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol.
Probald ki most! http://www.freestart.hu



More information about the uClibc mailing list