[Bug libc/12454] Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed!

["jason.vas.dias at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12454

--- Comment #18 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2011-04-26 13:20:13 UTC ---
Not sure if this is pertinent here, but I suspect so -
what I'm seeing is :
  o no problem if ld.so has no   'DT_RPATH' / 'DT_RPATH_LINK'
  o problem if using ld.so with  non-empty DT_RPATH / DT_RPATH_LINK 

$ objdump -x /lib64/ld-2.13.so | grep RPATH

^- this bug does NOT happen when using this loader:

$ echo 'int i = 42; ' > rc.c
$ gcc -o rc.so -shared -nostlib -fPIC rc.c
$ /lib64/ld-2.13.so --list ./rc.so
        statically linked

$ objdump -x /lib32/ld-2.13.so | grep RPATH
  RPATH               
/mnt/sda3/gcc/./gcc/32/:/mnt/sda3/gcc/./gcc/:/mnt/sda3/gcc/x86_64-pc-linux-gnu/libgcc/32:/mnt/sda3/gcc/x86_64-pc-linux-gnu/libgcc:/usr/lib32:/lib32

^- bug only happens using this loader :

$ gcc -m32 -o rc.so -shared -nostdlib -fPIC rc.c
$ /lib32/ld-2.13.so --list ./rc.so
Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion
`nlist > 1' failed!


Now, in order to build any ld.so at all with an RPATH, you must be
somehow disabling this bit of code :
$ diff -U0 elf/dynamic-link.h~ elf/dynamic-link.h
--- elf/dynamic-link.h~ 2011-04-08 02:03:09.000000000 +0100
+++ elf/dynamic-link.h  2011-04-07 02:59:09.000000000 +0100
@@ -208,2 +208,3 @@
-  assert (info[DT_RUNPATH] == NULL);
-  assert (info[DT_RPATH] == NULL);
+  /*  assert (info[DT_RUNPATH] == NULL);
+      assert (info[DT_RPATH] == NULL);
+  */

Now, I remember being roundly upbraded by Uli for attempting something so
crazy, with something along the lines of "an RPATH setting for ld.so 
causes so many problems for the loader it never will be supported" - but
I've been building the 32-bit sub-architecture glibc (ONLY!) for x86_64
for years with these lines commented out, hoping to find (and maybe fix?)
any problems caused, and running 32-bit freeware such as mozilla plugins
against this 32-bit loader, with no problems (except this one!) found so
far. Yes, I can see how commenting out these lines would be crazy for
a NATIVE loader, but not for a sub-architecture loader such as 32-bit
on native 64-bit or vice versa.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.