[CentOS] version GLIBC_2.0 not defined in file libpthread.so.0

Mon Apr 23 16:39:36 UTC 2007
Pierre Bourgin <pierre.bourgin at arteris.com>

Bisbal, Prentice a écrit :
> Pierre Bourgin wrote:
>> Bisbal, Prentice wrote:
>>
>> [...]
>>> Below is the output of the commands you requested. The naviagent
>>> binary is 32-bit. The RPM filename has "noarch" for the architecture,
>>> and there is no way to specify the Linux distribution or architecture
>>> on the download page, so EMC must be doing the "one size fits all"
>>> thing. 
>>>
>>> # file /opt/Navisphere/bin/naviagent
>>> /opt/Navisphere/bin/naviagent: ELF 32-bit LSB executable, Intel
>>> 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked
>>> (uses shared libs), stripped 
>>>
>>> # ldd /opt/Navisphere/bin/naviagent
>>>         linux-gate.so.1 =>  (0xffffe000)
>>>         libnsl.so.1 => /lib/libnsl.so.1 (0xf7fb7000)
>>>         libdl.so.2 => /lib/libdl.so.2 (0x00495000)
>>>         libm.so.6 => /lib/tls/libm.so.6 (0x0049b000)
>>>         libpthread.so.0 => /lib/tls/libpthread.so.0 (0x004ca000)
>>>         libc.so.6 => /lib/tls/libc.so.6 (0x00368000)
>>>         /lib/ld-linux.so.2 (0x0034f000)
>> So you should modify $LD_LIBRARY_PATH to use the older libpthread.so,
>> the one from the compat-glibc package. 
>>
>> The output of the command below should indicate that libpthread.so.0
>> is taken from the /usr/lib/i386-redhat-linux3E/lib, instead of using
>> /lib/tls/libpthread.so.0 :  
>>
>> % LD_LIBRARY_PATH=/usr/lib/i386-redhat-linux3E/lib ldd
>>           /opt/Navisphere/bin/naviagent [...] libpthread.so.0 =>
>> /usr/lib/i386-redhat-linux3E/lib/libpthread.so.0
>> [...]
>>
>> If this is case, you just have to write a shell wrapper script or a
>> shell alias to call naviagent, something like: 
>>
>> % chmod +x /usr/local/bin/naviagent
>> % cat /usr/local/bin/naviagent
>> #! /bin/sh
>> LD_LIBRARY_PATH=/usr/lib/i386-redhat-linux3E/lib
>> /opt/Navisphere/bin/naviagent $@
>>
>> Then modify $PATH in order to call it first:
>>
>> % which naviagent
>> /usr/local/bin/naviagent
>>
>> Try so see if it's working.
>>
>> You can also take a look in ld.so(8) man page and the LD_PRELOAD
>> environment variable if it's still no working. 
>>
>> Regards,
>> Pierre
> 
> Pierre, 
> I tried your suggestions with no luck. Whe I specify LD_LIBRARY_PATH, it
> still pulls libpthread.so.0 from the /lib/tls:
> 
> ldd /opt/Navisphere/bin/naviagent
>         linux-gate.so.1 =>  (0xffffe000)
>         libnsl.so.1 => /lib/libnsl.so.1 (0xf7fb7000)
>         libdl.so.2 => /lib/libdl.so.2 (0x00495000)
>         libm.so.6 => /lib/tls/libm.so.6 (0x0049b000)
>         libpthread.so.0 => /lib/tls/libpthread.so.0 (0x004ca000)
>         libc.so.6 => /lib/tls/libc.so.6 (0x00368000)
>         /lib/ld-linux.so.2 (0x0034f000)
> 
> LD_LIBRARY_PATH=/usr/lib/i386-redhat-linux3E/lib/ ldd
> /opt/Navisphere/bin/naviagent
>         linux-gate.so.1 =>  (0xffffe000)
>         libnsl.so.1 => /lib/libnsl.so.1 (0xf7fb7000)
>         libdl.so.2 => /lib/libdl.so.2 (0x00495000)
>         libm.so.6 => /lib/tls/libm.so.6 (0x0049b000)
>         libpthread.so.0 => /lib/tls/libpthread.so.0 (0x004ca000)
>         libc.so.6 => /lib/tls/libc.so.6 (0x00368000)
>         /lib/ld-linux.so.2 (0x0034f000)
> 
> Using LD_PRELOAD produced errors:
> 
> LD_PRELOAD=/usr/lib/i386-redhat-linux3E/lib/libpthread.so ldd
> /opt/Navisphere/bin/naviagent
> ERROR: ld.so: object '/usr/lib/i386-redhat-linux3E/lib/libpthread.so'
> from LD_PRELOAD cannot be preloaded: ignored.
> ERROR: ld.so: object '/usr/lib/i386-redhat-linux3E/lib/libpthread.so'
> from LD_PRELOAD cannot be preloaded: ignored.
> ERROR: ld.so: object '/usr/lib/i386-redhat-linux3E/lib/libpthread.so'
> from LD_PRELOAD cannot be preloaded: ignored.
>         linux-gate.so.1 =>  (0xffffe000)
>         libnsl.so.1 => /lib/libnsl.so.1 (0xf7fb7000)
>         libdl.so.2 => /lib/libdl.so.2 (0x00495000)
>         libm.so.6 => /lib/tls/libm.so.6 (0x0049b000)
>         libpthread.so.0 => /lib/tls/libpthread.so.0 (0x004ca000)
>         libc.so.6 => /lib/tls/libc.so.6 (0x00368000)
>         /lib/ld-linux.so.2 (0x0034f000)
> 
> When that didn't work, I took a look at all the libpthread files on my
> system:
> 
> for file in $(locate libpthread); do file $file; done
> /lib64/libpthread.so.0: symbolic link to `libpthread-0.10.so'
> /lib64/tls/libpthread-2.3.4.so: ELF 64-bit LSB shared object, AMD
> x86-64, version 1 (SYSV), not stripped
> /lib64/tls/libpthread.so.0: symbolic link to `libpthread-2.3.4.so'
> /lib64/libpthread-0.10.so: ELF 64-bit LSB shared object, AMD x86-64,
> version 1 (SYSV), not stripped
> /usr/lib64/libpthread.so: ASCII C program text
> /usr/lib64/libpthread_p.a: current ar archive
> /usr/lib64/nptl/libpthread.so: ASCII C program text
> /usr/lib64/nptl/libpthread_nonshared.a: current ar archive
> /usr/lib64/nptl/libpthread.a: current ar archive
> /usr/lib64/libpthread_nonshared.a: current ar archive
> /usr/lib64/libpthread.a: current ar archive
> /usr/lib/i386-redhat-linux3E/lib/libpthread_real.so: ELF 32-bit LSB
> shared object, Intel 80386, version 1 (SYSV), stripped
> /usr/lib/i386-redhat-linux3E/lib/libpthread.so: ASCII C program text
> /usr/lib/i386-redhat-linux3E/lib/libpthread_nonshared.a: current ar
> archive
> /usr/lib/i386-redhat-linux3E/lib/libpthread.a: current ar archive
> /usr/lib/x86_64-redhat-linux3E/lib64/libpthread_real.so: ELF 64-bit LSB
> shared object, AMD x86-64, version 1 (SYSV), stripped
> /usr/lib/x86_64-redhat-linux3E/lib64/libpthread.so: ASCII C program text
> /usr/lib/x86_64-redhat-linux3E/lib64/libpthread_nonshared.a: current ar
> archive
> /usr/lib/x86_64-redhat-linux3E/lib64/libpthread.a: current ar archive
> /usr/lib/libpthread.so: ASCII C program text
> /usr/lib/libpthread_nonshared.a: current ar archive
> /usr/lib/libpthread.a: current ar archive
> /lib/libpthread.so.0: symbolic link to `libpthread-0.10.so'
> /lib/tls/libpthread-2.3.4.so: ELF 32-bit LSB shared object, Intel 80386,
> version 1 (SYSV), not stripped
> /lib/tls/libpthread.so.0: symbolic link to `libpthread-2.3.4.so'
> /lib/i686/libpthread.so.0: symbolic link to `libpthread-0.10.so'
> /lib/i686/libpthread-0.10.so: ELF 32-bit LSB shared object, Intel 80386,
> version 1 (SYSV), not stripped
> /lib/libpthread-0.10.so: ELF 32-bit LSB shared object, Intel 80386,
> version 1 (SYSV), not stripped
> 
> Nothing looks out of place or unusual. I took your advice and read the
> ld.so man page. I used the LD_DEBUG variable to get full debugging
> output:
> 
> LD_DEBUG=all ldd /opt/Navisphere/bin/naviagent 2>/root/ld.debug.log
>         linux-gate.so.1 =>  (0xffffe000)
>         libnsl.so.1 => /lib/libnsl.so.1 (0xf7fb7000)
>         libdl.so.2 => /lib/libdl.so.2 (0x00495000)
>         libm.so.6 => /lib/tls/libm.so.6 (0x0049b000)
>         libpthread.so.0 => /lib/tls/libpthread.so.0 (0x004ca000)
>         libc.so.6 => /lib/tls/libc.so.6 (0x00368000)
>         /lib/ld-linux.so.2 (0x0034f000)
> 
> The debug log is pretty big, so I attached it as a file. I looked
> through it, but nothing looked unusual to me. Could be that I don't know
> what to look for. 
> 
> Any other ideas/suggestions? 

almost none ... it's really strange that the libpthread.so.0 used comes 
from /lib/tls and not from /usr/lib/i386-redhat-linux3E/ .

* try to play with LD_ASSUME_KERNEL=2.2.5  or LD_ASSUME_KERNEL=2.4.7 
perhaps ? It's semi-documented here: 
http://article.gmane.org/gmane.linux.centos.general/11770
and here: http://people.redhat.com/drepper/assumekernel.html

I've also some specialized software here (chipit) that has this sentence 
in their installation notes:
--------------------------------------------------------------------------------
4) On Linux systems that by default use the new NPTL POSIX thread
    library -- usually systems running a 2.6 kernel, but also some with a
    recent 2.4 kernel (2.4.20 or later), e.g. RHEL3 / CentOS 3.x -- the
    setup script will define the environment variable LD_ASSUME_KERNEL and
    assign it a value of "2.4.7" -- unless it has been set up already by
    another script/application.
--------------------------------------------------------------------------------

* Send me privately a copy of your binary (just is case).

* what about the library linux-gate.so.1 ? you have it locally ?

Someone clever has perhaps a clue ?


This is monday, a bad day :-(

Pierre