I just installed EMC PowerPath 5.0.0 and Navisphere Agent and CLI on a CentOS 4.4/x86_64 system. When I try to start naviagent, I get the error below. Before upgrading to CentOS4.4, this same system had RHEL3 ES for x86_64 on it, and the same problem was encountered. I spent weeks going back and forth with EMC tech support, but the problem was never resolved. I'm hoping someone here on this list can shed more light on the cause and solution.
PowerPath appears to be working just fine.
/opt/Navisphere/bin/naviagent: relocation error: /opt/Navisphere/bin/naviagent: symbol __pthread_atfork, version GLIBC_2.0 not defined in file libpthread.so.0 with link time reference
-- Prentice
The contents of this communication, including any attachments, may be confidential, privileged or otherwise protected from disclosure. They are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication. Please notify the sender immediately and delete the communication in its entirety.
Bisbal, Prentice wrote:
I just installed EMC PowerPath 5.0.0 and Navisphere Agent and CLI on a CentOS 4.4/x86_64 system. When I try to start naviagent, I get the error below. Before upgrading to CentOS4.4, this same system had RHEL3 ES for x86_64 on it, and the same problem was encountered. I spent weeks going back and forth with EMC tech support, but the problem was never resolved. I'm hoping someone here on this list can shed more light on the cause and solution.
PowerPath appears to be working just fine.
/opt/Navisphere/bin/naviagent: relocation error: /opt/Navisphere/bin/naviagent: symbol __pthread_atfork, version GLIBC_2.0 not defined in file libpthread.so.0 with link time reference
what is the /opt/Navisphere/bin/naviagent binary: a 32 or 64 bit ? Please send the output of commands: $ file /opt/Navisphere/bin/naviagent $ ldd /opt/Navisphere/bin/naviagent
do you have the some compat* packages installed ? they should help; for instance:
$ rpm -q compat-glibc compat-glibc-2.3.2-95.30.i386
$ rpm -ql compat-glibc | grep libpthread | xargs file /usr/lib/i386-redhat-linux3E/lib/libpthread.a: current ar archive /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_real.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
$ strings /usr/lib/i386-redhat-linux3E/lib/libpthread_real.so | grep GLIBC GLIBC_2.0 GLIBC_2.1 GLIBC_2.1.1 GLIBC_2.1.2 GLIBC_2.2 GLIBC_2.2.3 GLIBC_2.2.6 GLIBC_2.3.2 GLIBC_PRIVATE
(I don't know why, but nm informs this library has no symbols).
my $0.02
Pierre Bourgin
Pierre Bourgin wrote:
Bisbal, Prentice wrote:
I just installed EMC PowerPath 5.0.0 and Navisphere Agent and CLI on a CentOS 4.4/x86_64 system. When I try to start naviagent, I get the error below. Before upgrading to CentOS4.4, this same system had RHEL3 ES for x86_64 on it, and the same problem was encountered. I spent weeks going back and forth with EMC tech support, but the problem was never resolved. I'm hoping someone here on this list can shed more light on the cause and solution.
PowerPath appears to be working just fine.
/opt/Navisphere/bin/naviagent: relocation error: /opt/Navisphere/bin/naviagent: symbol __pthread_atfork, version GLIBC_2.0 not defined in file libpthread.so.0 with link time reference
what is the /opt/Navisphere/bin/naviagent binary: a 32 or 64 bit ? Please send the output of commands: $ file /opt/Navisphere/bin/naviagent $ ldd /opt/Navisphere/bin/naviagent
do you have the some compat* packages installed ? they should help; for instance:
$ rpm -q compat-glibc compat-glibc-2.3.2-95.30.i386
$ rpm -ql compat-glibc | grep libpthread | xargs file /usr/lib/i386-redhat-linux3E/lib/libpthread.a: current ar archive /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_real.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
$ strings /usr/lib/i386-redhat-linux3E/lib/libpthread_real.so | grep GLIBC GLIBC_2.0 GLIBC_2.1 GLIBC_2.1.1 GLIBC_2.1.2 GLIBC_2.2 GLIBC_2.2.3 GLIBC_2.2.6 GLIBC_2.3.2 GLIBC_PRIVATE
(I don't know why, but nm informs this library has no symbols).
my $0.02
Pierre Bourgin
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)
# rpm -qa | grep -i compat compat-db-4.1.25-9 compat-glibc-2.3.2-95.30 compat-db-4.1.25-9 java-1.4.2-gcj-compat-1.4.2.0-27jpp compat-libgcc-296-2.96-132.7.2 compat-libcom_err-1.0-5 compat-openldap-2.1.30-6.4E compat-glibc-2.3.2-95.30 compat-gcc-32-c++-3.2.3-47.3 java-1.4.2-gcj-compat-devel-1.4.2.0-27jpp compat-libstdc++-296-2.96-132.7.2 compat-libstdc++-33-3.2.3-47.3 compat-glibc-headers-2.3.2-95.30 compat-libcom_err-1.0-5 compat-openldap-2.1.30-6.4E compat-libstdc++-33-3.2.3-47.3 compat-gcc-32-3.2.3-47.3
# rpm -ql compat-glibc | grep libpthread | xargs file /usr/lib/i386-redhat-linux3E/lib/libpthread.a: current ar archive /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_real.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped /usr/lib/x86_64-redhat-linux3E/lib64/libpthread.a: current ar archive /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_real.so: ELF 64-bitLSB shared object, AMD x86-64, version 1 (SYSV), stripped
# strings /usr/lib/i386-redhat-linux3E/lib/libpthread_real.so | grep GLIBC GLIBC_2.0 GLIBC_2.1 GLIBC_2.1.1 GLIBC_2.1.2 GLIBC_2.2 GLIBC_2.2.3 GLIBC_2.2.6 GLIBC_2.3.2 GLIBC_PRIVATE
# nm /usr/lib/i386-redhat-linux3E/lib/libpthread_real.so nm: /usr/lib/i386-redhat-linux3E/lib/libpthread_real.so: no symbols
rpm -qpl naviagentcli-6.24.1.5.0-1.noarch.rpm /etc/Navisphere/SupportedFlareRevisions /etc/Navisphere/agent.config /etc/init.d/naviagent /opt/Navisphere/bin/SIWMain.jar /opt/Navisphere/bin/archivedump.jar /opt/Navisphere/bin/archivemerge.jar /opt/Navisphere/bin/archiveretrieve.jar /opt/Navisphere/bin/naviagent /opt/Navisphere/bin/navicli /opt/Navisphere/bin/navicli.jar /opt/Navisphere/bin/naviseccli
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 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?
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
-
Bisbal, Prentice -
Pierre Bourgin