Hi Folks,
as reported into glibc bug #5104
(http://sourceware.org/bugzilla/show_bug.cgi?id=5104)
"
The loader does not handle symbols with the STT_COMMON type.
We (the Binutils project) are currently examining the possibilty of having the
linker set the type of common symbols to STT_COMMON instead of STT_OBJECT. See
the thread starting here:
http://sources.redhat.com/ml/binutils/2007-10/msg00046.html
It was pointed out however that the loader would not currently handle such
symbols properly, so for now, the patch is not going to be applied. It would be
good however if the loader could process such symbols, so that we might then
allow the linker to generate them.
Cheers
Nick Clifton
"
the uclibc ld.so has to be updated to handle this kind of symbols with next
binutils release.
This patch does it.
Regards,
Carmelo
Hadle STT_COMMON symbols too. Following binutils release
will set the type of common symbols to STT_COMMON
instead of STT_OBJECTS, so the dynamic linker needs
to handle this type os symbols too.
Same changes have been added to glibc (See: bugzilla #5104).
This patch ensures the uclibc will work with later bintuils.
Signed-off-by: Carmelo Amoroso <[EMAIL PROTECTED]>
--- uClibc-trunk/ldso/ldso/dl-hash.c 2007-10-08 08:54:40.020926000 +0200
+++ uClibc-trunk-st/ldso/ldso/dl-hash.c 2007-10-08 08:59:19.892237000 +0200
@@ -177,7 +177,12 @@ char *_dl_find_hash(const char *name, st
continue;
if (sym->st_value == 0)
continue;
- if (ELF_ST_TYPE(sym->st_info) > STT_FUNC)
+ if (ELF_ST_TYPE(sym->st_info) > STT_FUNC
+ && ELF_ST_TYPE(sym->st_info) != STT_COMMON)
+ /* Ignore all but STT_NOTYPE, STT_OBJECT, STT_FUNC
+ * and STT_COMMON entries since these are no
+ * code/data definitions
+ */
continue;
if (_dl_strcmp(strtab + sym->st_name, name) != 0)
continue;
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
