[CentOS] version GLIBC_2.0 not defined in file libpthread.so.0
Pierre Bourgin
pierre.bourgin at arteris.com
Mon Apr 23 16:39:36 UTC 2007
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
More information about the CentOS
mailing list