Bug#265678: Bug#279240: fakeroot doesn't build on mips and mipsel

[GOTO Masanori <gotom@debian.or.jp>]

Hi,

At Sun, 07 Nov 2004 18:53:24 +0900,
Kenshi Muto wrote:
> I tried to reproduce a problem, then Masanori Goto and I find
> (temporary) solution.

Recently I got the root access to mips/mipsel machine (Thanks to
Mutsumi Ishikawa and Kenshi Muto), and checked this problem.

> <Temporary solution>
> Add "#undef RTLD_NEXT" to libfakeroot.c when architecture is mips/mipsel.
> </Temporary solution>
> 
> Problem will be solved.

Yes, I confirmed the following (workaround) patch fixed the problem on
mipsel (I didn't test it on mips):


--- ../../fakeroot-1.1.5/libfakeroot.c  2004-10-08 00:56:04.000000000 +0900
+++ libfakeroot.c       2004-11-06 22:11:38.000000000 +0900
@@ -73,7 +73,7 @@
 };
 
 void *get_libc(){
- 
+#undef RTLD_NEXT 
 #ifndef RTLD_NEXT
  void *lib=0;
  if(!lib){ 


It disables to use RTLD_NEXT (== -1).

It seems when we use RTLD_NEXT, the next line returns the invalid
address which is not in the glibc scope (and interestingly it's
libacl1 scope):

       *(next_wrap[i].doit)=dlsym(get_libc(), next_wrap[i].name);

> fakeroot on sarge works, but one on sid won't work. At least about
> 'mv' command, newest libacl makes RTLD_NEXT confusing.

"mv" command depends on the following libraries:

        libacl.so.1 => /lib/libacl.so.1 (0x2ab04000)
        libc.so.6 => /lib/libc.so.6 (0x2ab4c000)
        libattr.so.1 => /lib/libattr.so.1 (0x2ad18000)
        /lib/ld.so.1 => /lib/ld.so.1 (0x2aaa8000)

Moreover, when we use libacl1 (2.2.23-1), fakeroot without RTLD_NEXT
hack works well.  However when we use the recent libacl1 (2.2.26-1),
fakeroot does not work and RTLD_NEXT hack is needed.


Thiemo was also spotted this problem:

> The problem is caused by dlsym() returning the lazy binding stub of
> the next library instead of the actual implementation. Example:
> 
> /usr/bin/file
> /usr/lib/libfakeroot/libfakeroot.so.0
> /usr/lib/libmagic.so.1
> /usr/lib/libz.so.1
> /lib/libc.so.6
> /lib/ld.so.1
> 
> __xstat64 (in libc) is called from both file and libmagic, and
> libfakeroot tries to wrap it. With the current behaviour, the wrapper
> function in libfakeroot resolves to the lazy binding stub in libmagic
> instead of the __xstat64 implementation in libc.
> 
> The stub in libmagic is marked as undefined:
> 
>     95: 0000dee0     0 FUNC    GLOBAL DEFAULT  UND __xstat64@GLIBC_2.2 (3)

I guess the lazy binding + RTLD_NEXT is broken with the recent
libraries which are compiled by the recent binutils 2.15 or the recent
gcc 3.3.  I guess it's binutils and glibc dl related problem, but I
still don't know what the actual problem is.

Regards,
-- gotom