Name clashes in shared libraries
Josu Onandia
jonandia at fagorautomation.es
Thu May 18 09:29:45 UTC 2006
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 thought *this* would eliminate the name clash between the application and the library.
I tested the method with a small library, and it worked perfectly. Then, I build
the real library *this* way. Everything seems ok, but when I launch the application (use_lib),
ld aborts it with *this* error:
./use_lib: can't resolve symbol ''
Yes, *this* is not a typo, actually it is a reference to a no-name symbol. I'm stuck here
*for* some time now, googling without results, and everything I *try* fails. I REALLY would
appreciate any ideas or suggestions. And I will of course provide more detail *if* needed.
The details: target is powerpc
binutils-2.14.90.0.8
gcc 3.3.6
uClibc-0.9.27
nm 2.14.90.08
Command line
powerpc-linux-uclibc-gcc -O0 -g3 -Wall -c -fmessage-length=0 -fsigned-char -fPIC ........
(I tried -fpic but I got some errors about truncated offsets, then I was suggested
to use -fPIC instead).
powerpc-linux-uclibc-gcc -Wl,--version-script=library.map -shared -olibrt55.so ...*... *-lm
To see the dynamic symbols I execute powerpc-linux-nm -D -p -f s librt55.so
The result is:
Symbols from librt55.so:
*Name* Value *Class* *Type* Size *Line* Section
longjmp | | U | FUNC|00000078| |*UND*
strcpy | | U | FUNC|00000094| |*UND*
sqrt | | U | FUNC|00000040| |*UND*
printf | | U | FUNC|000000c8| |*UND*
memmove | | U | FUNC|0000024c| |*UND*
_DYNAMIC |005340a0| a | OBJECT| | |*ABS*
atol | | U | FUNC|00000048| |*UND*
__ctype_b | | U | OBJECT|00000004| |*UND*
ceil | | U | FUNC|000002bc| |*UND*
floor | | U | FUNC|000002c0| |*UND*
memcpy | | U | FUNC|00000224| |*UND*
sample_function |0003d214| T | FUNC|00000054| |.text
__cxa_finalize | | w | NOTYPE| | |*UND*
malloc | | U | FUNC|00000a6c| |*UND*
strtoul | | U | FUNC|00000054| |*UND*
__ctype_toupper | | U | OBJECT|00000004| |*UND*
strtol | | U | FUNC|00000054| |*UND*
atof | | U | FUNC|00000044| |*UND*
strcat | | U | FUNC|000000b0| |*UND*
__deregister_frame_info| | w | NOTYPE| | |*UND*
modf | | U | FUNC|00000268| |*UND*
fmod | | U | FUNC|00000048| |*UND*
cos | | U | FUNC|00000188| |*UND*
strstr | | U | FUNC|000002e4| |*UND*
sin | | U | FUNC|0000018c| |*UND*
atan2 | | U | FUNC|00000048| |*UND*
_SDA_BASE_ |0053c16c| g | OBJECT| | |.sdata
strncmp | | U | FUNC|000002f4| |*UND*
pow | | U | FUNC|00000048| |*UND*
strncpy | | U | FUNC|00000274| |*UND*
log10 | | U | FUNC|00000040| |*UND*
realloc | | U | FUNC|00000780| |*UND*
strtok | | U | FUNC|0000005c| |*UND*
sscanf | | U | FUNC|000000b4| |*UND*
strncat | | U | FUNC|0000026c| |*UND*
memset | | U | FUNC|000001d8| |*UND*
strcmp | | U | FUNC|000000c4| |*UND*
tan | | U | FUNC|00000104| |*UND*
atan | | U | FUNC|00000434| |*UND*
sprintf | | U | FUNC|000000b8| |*UND*
asin | | U | FUNC|00000040| |*UND*
_GLOBAL_OFFSET_TABLE_|00534160| a | OBJECT| | |*ABS*
_setjmp | | U | FUNC|00000008| |*UND*
strlen | | U | FUNC|0000019c| |*UND*
toupper | | U | FUNC|0000007c| |*UND*
__assert | | U | FUNC|000000a8| |*UND*
div | | U | FUNC|0000005c| |*UND*
strchr | | U | FUNC|000002bc| |*UND*
acos | | U | FUNC|00000040| |*UND*
_Jv_RegisterClasses | | w | NOTYPE| | |*UND*
_SDA2_BASE_ |0053c16c| g | OBJECT| | |.sdata2
__register_frame_info| | w | NOTYPE| | |*UND*
free | | U | FUNC|000003f0| |*UND*
----------------------------
In the target, I've configured ld with debug support, and I make $ LD_DEBUG=all ./use_lib
The output is huge. This is only the last lines:
relocation processing: /lib/librt55.so
R_PPC_RELATIVE offset=0x5188e4 addend=0x5188e4 patched: 0x0 ==> 0x3052f8e4 @ 0x3052f8e4
R_PPC_RELATIVE offset=0x5188e8 addend=0x534e50 patched: 0x0 ==> 0x3054be50 @ 0x3052f8e8
R_PPC_RELATIVE offset=0x5188f0 addend=0x3f108 patched: 0x0 ==> 0x30056108 @ 0x3052f8f0
..........*... *20000 lines more
R_PPC_RELATIVE offset=0x53532c addend=0x35448c patched: 0x0 ==> 0x3036b48c @ 0x3054c32c
value=0x535560 size=0x0 info=0x3 other=0x0 shndx=0x15
R_PPC_ADDR16_HA offset=0x62fa6 addend=0x535b24./use_lib: can't resolve symbol ''
when I link without the --version-script flag, the same log says:
relocation processing: /lib/librt55.so
R_PPC_RELATIVE offset=0x56e734 addend=0x56e734 patched: 0x0 ==> 0x30585734 @ 0x30585734
R_PPC_RELATIVE offset=0x56e738 addend=0x58aca0 patched: 0x0 ==> 0x305a1ca0 @ 0x30585738
R_PPC_RELATIVE offset=0x56e740 addend=0x94f5c patched: 0x0 ==> 0x300abf5c @ 0x30585740
.........*... *ONLY 13000 lines more !!!!!
R_PPC_RELATIVE offset=0x58b17c addend=0x3aa2e0 patched: 0x0 ==> 0x303c12e0 @ 0x305a217c
plc_seg_datos
value=0x58b974 size=0x4 info=0x11 other=0x0 shndx=0x15
R_PPC_ADDR16_HA offset=0xb8dfa addend=0x0 patched: 0x81ef ==> 0x305a81ef @ 0x300cfdfa
plc_seg_datos
value=0x58b974 size=0x4 info=0x11 other=0x0 shndx=0x15
R_PPC_ADDR16_LO offset=0xb8dfe addend=0x0 patched: 0x3e00 ==> 0x29743e00 @ 0x300cfdfe
plc_seg_datos
value=0x58b974 size=0x4 info=0x11 other=0x0 shndx=0x15
R_PPC_ADDR16_HA offset=0xb8eaa addend=0x0 patched: 0x81ef ==> 0x305a81ef @ 0x300cfeaa
plc_seg_datos
value=0x58b974 size=0x4 info=0x11 other=0x0 shndx=0x15
R_PPC_ADDR16_LO offset=0xb8eae addend=0x0 patched: 0x3e00 ==> 0x29743e00 @ 0x300cfeae
.............*... *continues
I'm sorry *for* the big post.
Thank you very much in advance
Josu Onandia
R & D
Fagor Automation
More information about the uClibc
mailing list