Follow-up Comment #13, bug #86984 (project xrootd):
I have investigated a bit further and it looks like the library is built,
linked and loaded fine. There must be some bug in XrdPosix_Opendir.
6311:
6311: initialize program: ls
6311:
6311:
6311: transferring control: ls
6311:
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`setlocale' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`bindtextdomain' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`textdomain' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`__cxa_atexit' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`isatty' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`getenv' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`ioctl' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`getopt_long' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`strlen' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`strncmp' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`__errno_location' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`malloc' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`memcpy' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`strcmp' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`tcgetpgrp' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`sigemptyset' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`sigaction' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`sigaddset' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`sigismember' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`__overflow' [GLIBC_2.2.5]
6311: binding file ls [0] to /usr/lib64/libXrdPosixPreload.so [0]:
normal symbol `opendir' [GLIBC_2.2.5]
6311: binding file /usr/lib64/libXrdPosixPreload.so [0] to
/usr/lib64/libXrdPosix.so.0 [0]: normal symbol `XrdPosix_Opendir'
6311: binding file /usr/lib64/libXrdPosix.so.0 [0] to
/lib64/libc.so.6 [0]: normal symbol `strncmp' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`__ctype_get_mb_cur_max' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`error' [GLIBC_2.2.5]
ls: .: Can not access a needed shared library
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`free' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`fflush_unlocked' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`signal' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`exit' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`__fpending' [GLIBC_2.2.5]
6311: binding file ls [0] to /usr/lib64/libXrdPosixPreload.so [0]:
normal symbol `fclose' [GLIBC_2.2.5]
6311: binding file /usr/lib64/libXrdPosixPreload.so [0] to
/usr/lib64/libXrdPosix.so.0 [0]: normal symbol `XrdPosix_Fclose'
6311: binding file /usr/lib64/libXrdPosix.so.0 [0] to
/lib64/libc.so.6 [0]: normal symbol `fileno' [GLIBC_2.2.5]
6311: binding file ls [0] to /lib64/libc.so.6 [0]: normal symbol
`dcgettext' [GLIBC_2.2.5]
ls: write error: Can not access a needed shared library
>From the linker trace above you can see that at some point "opendir" is
called and since libXrdPosixPreload is higher in the lookup scope than libc
it highjacks this call and transmits it to XrdPosix_Opendir which must be
returning garbage.
I do realize that this stuff is widely used and that it is extremely but I
hope that you can now see how fragile all this is. IMO a proper solution
(proper as in not being a bunch of hacks) needs to be implemented instead.
_______________________________________________________
Reply to this item at:
<http://savannah.cern.ch/bugs/?86984>
_______________________________________________
Message sent via/by LCG Savannah
http://savannah.cern.ch/
|