Assura LVS problem

A

Adam

Guest
Hi Friends,


I tried to do LVS using Assura. However, LVS failed. The log
file shows the error:

/cadence/assura317/tools/assura/bin/64bit/assura: error while loading
shared libraries: libstdc++.so.5: wrong ELF class: ELFCLASS32

What caused the error?

Thanks in advance.
 
Hi Adam,

My understanding from your description is that you are trying to
launch a 64bit executable with a shared object that is compiled for a
32bit hardware. This error is very likely to pop up because of a wrong
setting of the LD_LIBRARY_PATH env variable. You are either missing up
something with in your Assura Installation or pre-appending (hard-
wiring) a 32bit path into your LD_LIBRARY_PATH. BTW, are you a RHEL or
a Suse user ? I think the settings are slightly different, not 100%
sure though.

Regards,
Riad.
 
Riad KACED wrote, on 01/06/09 20:13:
Hi Adam,

My understanding from your description is that you are trying to
launch a 64bit executable with a shared object that is compiled for a
32bit hardware. This error is very likely to pop up because of a wrong
setting of the LD_LIBRARY_PATH env variable. You are either missing up
something with in your Assura Installation or pre-appending (hard-
wiring) a 32bit path into your LD_LIBRARY_PATH. BTW, are you a RHEL or
a Suse user ? I think the settings are slightly different, not 100%
sure though.

Regards,
Riad.
Click to expand...
I agree with Riad - what are your PATH and LD_LIBRARY_PATH set to? What OS are
you using, and what does "uname -a" give?

In order to run 64 bit executables, you should not put the 64 bit executables in
your path, or set the LD_LIBRARY_PATH to point to the 64 bit libraries - this
should be taken care of by the wrappers, especially when using the
$CDS_AUTO_64BIT variable to enable 64 bit Assura.

Regards,

Andrew.
 
On Jan 6, 4:18 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
Riad KACED wrote, on 01/06/09 20:13:

Hi Adam,

My understanding from your description is that you are trying to
launch a 64bit executable with a shared object that is compiled for a
32bit hardware. This error is very likely to pop up because of a wrong
setting of the LD_LIBRARY_PATH env variable. You are either missing up
something with in your Assura Installation or pre-appending (hard-
wiring) a 32bit path into your LD_LIBRARY_PATH. BTW, are you a RHEL or
a Suse user ? I think the settings are slightly different, not 100%
sure though.

Regards,
Riad.

I agree with Riad - what are your PATH and LD_LIBRARY_PATH set to? What OS are
you using, and what does "uname -a" give?

In order to run 64 bit executables, you should not put the 64 bit executables in
your path, or set the LD_LIBRARY_PATH to point to the 64 bit libraries - this
should be taken care of by the wrappers, especially when using the
$CDS_AUTO_64BIT variable to enable 64 bit Assura.

Regards,

Andrew.
Click to expand...
Hi Riad and Andrew,

Thank you both for you kind help.

I just checked my .cshrc file, I didn't set the LD_LIBRARY_PATH env
variable.


setenv ASSURAHOME /.../cadence/assura317

set path = ($ASSURAHOME/tools/dfII/bin $ASSURAHOME/tools/bin
$ASSURAHOME/tools/assura/bin $PATH)

uname -a gives the follows:

.... 5.9 Generic_118558-10 sun4u sparc SUNW,Sun-Blade-2500

In order to prevent 64bit CDL , I use
setenv CDS_AUTO_64BIT "EXCLUDE: si.exe"
before starting icfb. However, assura LVS doesn't work and shows the
error message as I mentioned above.

Thanks again,
Adam
 
On Tue, 6 Jan 2009 06:41:54 -0800 (PST), Adam
<wang.adam2008@gmail.com> wrote:

Hi Friends,


I tried to do LVS using Assura. However, LVS failed. The log
file shows the error:

/cadence/assura317/tools/assura/bin/64bit/assura: error while loading
shared libraries: libstdc++.so.5: wrong ELF class: ELFCLASS32

What caused the error?

Thanks in advance.
Click to expand...
Your LD_LOAD_PATH seems to be pointing to the wrong directory(ies).
Set it to /lib64 or similar places. A 64 bit app can't load 32 bit
libraries (or vice versa).

Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com
 
Adam wrote, on 01/07/09 19:51:
On Jan 6, 4:18 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm
wrote:
Riad KACED wrote, on 01/06/09 20:13:

Hi Adam,
My understanding from your description is that you are trying to
launch a 64bit executable with a shared object that is compiled for a
32bit hardware. This error is very likely to pop up because of a wrong
setting of the LD_LIBRARY_PATH env variable. You are either missing up
something with in your Assura Installation or pre-appending (hard-
wiring) a 32bit path into your LD_LIBRARY_PATH. BTW, are you a RHEL or
a Suse user ? I think the settings are slightly different, not 100%
sure though.
Regards,
Riad.
I agree with Riad - what are your PATH and LD_LIBRARY_PATH set to? What OS are
you using, and what does "uname -a" give?

In order to run 64 bit executables, you should not put the 64 bit executables in
your path, or set the LD_LIBRARY_PATH to point to the 64 bit libraries - this
should be taken care of by the wrappers, especially when using the
$CDS_AUTO_64BIT variable to enable 64 bit Assura.

Regards,

Andrew.

Hi Riad and Andrew,

Thank you both for you kind help.

I just checked my .cshrc file, I didn't set the LD_LIBRARY_PATH env
variable.


setenv ASSURAHOME /.../cadence/assura317

set path = ($ASSURAHOME/tools/dfII/bin $ASSURAHOME/tools/bin
$ASSURAHOME/tools/assura/bin $PATH)

uname -a gives the follows:

... 5.9 Generic_118558-10 sun4u sparc SUNW,Sun-Blade-2500

In order to prevent 64bit CDL , I use
setenv CDS_AUTO_64BIT "EXCLUDE: si.exe"
before starting icfb. However, assura LVS doesn't work and shows the
error message as I mentioned above.

Thanks again,
Adam
Click to expand...
What does

echo $LD_LIBRARY_PATH

show?

And what does:

assura -debug3264

output?

Regards,

Andrew.

--
Andrew Beckett
Senior Solution Architect - Cadence Design Systems Ltd (UK)
 
On Jan 8, 6:36 am, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
Adam wrote, on 01/07/09 19:51:



On Jan 6, 4:18 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm
wrote:
Riad KACED wrote, on 01/06/09 20:13:

Hi Adam,
My understanding from your description is that you are trying to
launch a 64bit executable with a shared object that is compiled for a
32bit hardware. This error is very likely to pop up because of a wrong
setting of the LD_LIBRARY_PATH env variable. You are either missing up
something with in your Assura Installation or pre-appending (hard-
wiring) a 32bit path into your LD_LIBRARY_PATH. BTW, are you a RHEL or
a Suse user ? I think the settings are slightly different, not 100%
sure though.
Regards,
Riad.
I agree with Riad - what are your PATH and LD_LIBRARY_PATH set to? What OS are
you using, and what does "uname -a" give?

In order to run 64 bit executables, you should not put the 64 bit executables in
your path, or set the LD_LIBRARY_PATH to point to the 64 bit libraries - this
should be taken care of by the wrappers, especially when using the
$CDS_AUTO_64BIT variable to enable 64 bit Assura.

Regards,

Andrew.

Hi Riad and Andrew,

Thank you both for you kind help.

I just checked my .cshrc file, I didn't set the LD_LIBRARY_PATH env
variable.

setenv ASSURAHOME /.../cadence/assura317

set path = ($ASSURAHOME/tools/dfII/bin $ASSURAHOME/tools/bin
$ASSURAHOME/tools/assura/bin $PATH)

uname -a gives the follows:

... 5.9 Generic_118558-10 sun4u sparc SUNW,Sun-Blade-2500

In order to prevent 64bit CDL , I use
setenv CDS_AUTO_64BIT "EXCLUDE: si.exe"
before starting icfb. However, assura LVS doesn't work and shows the
error message as I mentioned above.

Thanks again,
Adam

What does

echo $LD_LIBRARY_PATH

show?

And what does:

assura -debug3264

output?

Regards,

Andrew.

--
Andrew Beckett
Senior Solution Architect - Cadence Design Systems Ltd (UK)
Click to expand...
Hi Andrew,

echo $LD_LIBRARY_PATH

/usr/sge/lib/sol-sparc64:/usr/ecs/ldv51/tools.sun4v/lib:/SunOS/sw/lib:/
usr/lib:/usr/dt/lib:/usr/openwin/lib:/usr/ucblib:/usr/ecs/antlr-2.7.1/
lib:/usr/ecs/specman-4.0.2/sn_rel4.0.2/solaris:/usr/ecs/lib:/usr/sfw/
lib:/usr/local/lib


assura -debug3264

# CDS_AUTO_64BIT = EXCLUDE:si.exe
#
# PATH = /Linux/sw/request/cadence/assura317/bin:/Linux/sw/request/
cadence/assur
a317/tools/bin/64bit:/Linux/sw/request/cadence/assura317/tools/bin:/
Linux/sw/req
uest/cadence/mmsim62/tools/bin:/Linux/sw/request/cadence/
ic5141_ISR0405/tools/bi
n:/Linux/sw/request/cadence/ic5141_ISR0405/tools/dfII/bin:/Linux/sw/
request/cade
nce/ic5141_ISR0405/tools/plot/bin:/Linux/sw/request/cadence/
ic5141_ISR0405/tools
/etc:/Linux/sw/request/cadence/mmsim62/tools/bin:/Linux/sw/request/
cadence/ic514
1_ISR0405/tools/bin:/Linux/sw/request/cadence/ic5141_ISR0405/tools/
dfII/bin:/Lin
ux/sw/request/cadence/ic5141_ISR0405/tools/plot/bin:/Linux/sw/request/
cadence/ic
5141_ISR0405/tools/etc:/Linux/sw/request/cadence/mmsim62/tools/bin:/
Linux/sw/req
uest/cadence/ic5141_ISR0405/tools/bin:/Linux/sw/request/cadence/
ic5141_ISR0405/t
ools/dfII/bin:/Linux/sw/request/cadence/ic5141_ISR0405/tools/plot/bin:/
Linux/sw/
request/cadence/ic5141_ISR0405/tools/etc:/Linux/sw/request/cadence/
mmsim62/tools
/bin:/Linux/sw/request/cadence/ic5141_ISR0405/tools/bin:/Linux/sw/
request/cadenc
e/ic5141_ISR0405/tools/dfII/bin:/Linux/sw/request/cadence/
ic5141_ISR0405/tools/p
lot/bin:/Linux/sw/request/cadence/ic5141_ISR0405/tools/etc:/Linux/sw/
request/cad
ence/soc41/tools/dfII/bin:/Linux/sw/request/cadence/soc41/tools/bin:/
Linux/sw/re
quest/cadence/ius56/tools/systemc/gcc/install/bin:/Linux/sw/request/
cadence/ius5
6/tools/spectre/bin:/Linux/sw/request/cadence/ius56/tools/dfII/bin:/
Linux/sw/req
uest/cadence/ius56/tools/bin:/Linux/sw/request/cadence/assura317/tools/
dfII/bin:
/Linux/sw/request/cadence/assura317/tools/assura/bin:/Linux/sw/request/
cadence/r
c81/tools/dfII/bin:/Linux/sw/request/cadence/rc81/tools/bin/64bit:/
Linux/sw/requ
est/cadence/rc81/tools/bin:/usr/sge/bin/lx24-amd64:/Linux/sw/bin:/usr/
bin:/bin:/
usr/X11R6/bin:/usr/sbin:/sbin
#
# LD_LIBRARY_PATH = /Linux/sw/request/cadence/assura317/tools/lib/
64bit:/Linux/s
w/request/cadence/assura317/tools/lib:/Linux/sw/request/cadence/
assura317/tools/
QT/lib/64bit:/usr/sge/lib/lx24-amd64:/Linux/sw/lib:/usr/lib:/lib:/usr/
X11R6/lib
#
# LOCAL_ASSUME_KERNEL = unset
#
# Launching: /Linux/sw/request/cadence/assura317/tools/assura/bin/
64bit/assura
#
/Linux/sw/request/cadence/assura317/tools/assura/bin/64bit/assura:
error while l
oading shared libraries: libstdc++.so.5: wrong ELF class: ELFCLASS32



Thanks a lot!

Regards,
Adam
 
Adam wrote:

echo $LD_LIBRARY_PATH

/usr/sge/lib/sol-sparc64:/usr/ecs/ldv51/tools.sun4v/lib:/SunOS/sw/lib:/
usr/lib:/usr/dt/lib:/usr/openwin/lib:/usr/ucblib:/usr/ecs/antlr-2.7.1/
lib:/usr/ecs/specman-4.0.2/sn_rel4.0.2/solaris:/usr/ecs/lib:/usr/sfw/
lib:/usr/local/lib
Click to expand...
THIS SHOULD BE:

$ echo $LD_LIBRARY_PATH
Unset. Nothing. No output. Forget about LD_LIBRARY_PATH


http://xahlee.org/UnixResource_dir/_/ldpath.html
 
PM wrote, on 01/09/09 09:38:
Adam wrote:

echo $LD_LIBRARY_PATH

/usr/sge/lib/sol-sparc64:/usr/ecs/ldv51/tools.sun4v/lib:/SunOS/sw/lib:/
usr/lib:/usr/dt/lib:/usr/openwin/lib:/usr/ucblib:/usr/ecs/antlr-2.7.1/
lib:/usr/ecs/specman-4.0.2/sn_rel4.0.2/solaris:/usr/ecs/lib:/usr/sfw/
lib:/usr/local/lib


THIS SHOULD BE:

$ echo $LD_LIBRARY_PATH
Unset. Nothing. No output. Forget about LD_LIBRARY_PATH


http://xahlee.org/UnixResource_dir/_/ldpath.html
Click to expand...
I assumed that was the case - because the LD_LIBRARY_PATH was for Solaris, but
the assura debug output was for Linux, and didn't have any of these paths in...

Next test is to do:

cd /Linux/sw/request/cadence/assura317/tools/assura/bin/64bit
ldd assura

Note that you must be running on the machine to do this. I suspect that the
program may be being run via some wrapper script which sends it onto a compute
farm? (hence the Solaris/Linux discrepancy).

You should get something like:

libm.so.6 => /lib64/tls/libm.so.6 (0x000000321ac00000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003220400000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000321a700000)
libelf.so.1 => /usr/lib64/libelf.so.1 (0x000000321ba00000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x000000321b400000)
libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x0000002a95589000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000321d000000)
libc.so.6 => /lib64/tls/libc.so.6 (0x000000321a900000)
/lib64/ld-linux-x86-64.so.2 (0x000000321a500000)

Regards,

Andrew.
 
Adam wrote, on 01/09/09 16:35:
On Jan 9, 9:16 am, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm
wrote:
PM wrote, on 01/09/09 09:38:



Adam wrote:
echo $LD_LIBRARY_PATH
/usr/sge/lib/sol-sparc64:/usr/ecs/ldv51/tools.sun4v/lib:/SunOS/sw/lib:/
usr/lib:/usr/dt/lib:/usr/openwin/lib:/usr/ucblib:/usr/ecs/antlr-2.7.1/
lib:/usr/ecs/specman-4.0.2/sn_rel4.0.2/solaris:/usr/ecs/lib:/usr/sfw/
lib:/usr/local/lib
THIS SHOULD BE:
$ echo $LD_LIBRARY_PATH
Unset. Nothing. No output. Forget about LD_LIBRARY_PATH
http://xahlee.org/UnixResource_dir/_/ldpath.html
I assumed that was the case - because the LD_LIBRARY_PATH was for Solaris, but
the assura debug output was for Linux, and didn't have any of these paths in...

Next test is to do:

cd /Linux/sw/request/cadence/assura317/tools/assura/bin/64bit
ldd assura

Note that you must be running on the machine to do this. I suspect that the
program may be being run via some wrapper script which sends it onto a compute
farm? (hence the Solaris/Linux discrepancy).

You should get something like:

libm.so.6 => /lib64/tls/libm.so.6 (0x000000321ac00000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003220400000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000321a700000)
libelf.so.1 => /usr/lib64/libelf.so.1 (0x000000321ba00000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x000000321b400000)
libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x0000002a95589000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000321d000000)
libc.so.6 => /lib64/tls/libc.so.6 (0x000000321a900000)
/lib64/ld-linux-x86-64.so.2 (0x000000321a500000)

Regards,

Andrew.

Hi Andrew,

You are right. I am using qshell on my unix machine to log into a
Linux machine where Cadence is running.
I did the test:

cd /Linux/sw/request/cadence/assura317/tools/assura/bin/64bit
ldd assura
libm.so.6 => /lib64/libm.so.6 (0x0000003a4a800000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003a50800000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003a4a400000)
libelf.so.1 => /usr/lib64/libelf.so.1 (0x0000003a4b000000)
libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x00002b5fc82dc000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003a4ac00000)
libstdc++.so.5 => not found
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003a4bc00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003a4a000000)
/lib64/ld-linux-x86-64.so.2 (0x0000003a49800000)


Thanks,
Adam
Click to expand...
What OS distribution/version are you running on?

Anyway, I've checked on both RHEL (4 and 5) and SuSE (10) machines and see that
libstdc++.so.5 is in /usr/lib64 on both - and comes in the compat-libstdc++ rpm
package. In SuSE 9 it's in the libstdc++ rpm package.

Looks as if the machine may not have a complete installation of the require OS
pieces. Unfortunately in older releases (IC5141-based releases, including the
ASSURA317/ASSURA32 for IC5141), 64 bit version of libstdc++.so.5 was not shipped
with the installation - it was assumed to be installed as part of the OS.

Best Regards,

Andrew.
 
On Jan 9, 9:16 am, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
PM wrote, on 01/09/09 09:38:



Adam wrote:

echo $LD_LIBRARY_PATH

/usr/sge/lib/sol-sparc64:/usr/ecs/ldv51/tools.sun4v/lib:/SunOS/sw/lib:/
usr/lib:/usr/dt/lib:/usr/openwin/lib:/usr/ucblib:/usr/ecs/antlr-2.7.1/
lib:/usr/ecs/specman-4.0.2/sn_rel4.0.2/solaris:/usr/ecs/lib:/usr/sfw/
lib:/usr/local/lib

THIS SHOULD BE:

$ echo $LD_LIBRARY_PATH
Unset. Nothing. No output. Forget about LD_LIBRARY_PATH

http://xahlee.org/UnixResource_dir/_/ldpath.html

I assumed that was the case - because the LD_LIBRARY_PATH was for Solaris, but
the assura debug output was for Linux, and didn't have any of these paths in...

Next test is to do:

cd /Linux/sw/request/cadence/assura317/tools/assura/bin/64bit
ldd assura

Note that you must be running on the machine to do this. I suspect that the
program may be being run via some wrapper script which sends it onto a compute
farm? (hence the Solaris/Linux discrepancy).

You should get something like:

libm.so.6 => /lib64/tls/libm.so.6 (0x000000321ac00000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003220400000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000321a700000)
libelf.so.1 => /usr/lib64/libelf.so.1 (0x000000321ba00000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x000000321b400000)
libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x0000002a95589000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000321d000000)
libc.so.6 => /lib64/tls/libc.so.6 (0x000000321a900000)
/lib64/ld-linux-x86-64.so.2 (0x000000321a500000)

Regards,

Andrew.
Click to expand...
Hi Andrew,

You are right. I am using qshell on my unix machine to log into a
Linux machine where Cadence is running.
I did the test:

cd /Linux/sw/request/cadence/assura317/tools/assura/bin/64bit
ldd assura
libm.so.6 => /lib64/libm.so.6 (0x0000003a4a800000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003a50800000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003a4a400000)
libelf.so.1 => /usr/lib64/libelf.so.1 (0x0000003a4b000000)
libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x00002b5fc82dc000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003a4ac00000)
libstdc++.so.5 => not found
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003a4bc00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003a4a000000)
/lib64/ld-linux-x86-64.so.2 (0x0000003a49800000)


Thanks,
Adam
 
On Jan 9, 12:34 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
Adam wrote, on 01/09/09 16:35:



On Jan 9, 9:16 am, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm
wrote:
PM wrote, on 01/09/09 09:38:

Adam wrote:
echo $LD_LIBRARY_PATH
/usr/sge/lib/sol-sparc64:/usr/ecs/ldv51/tools.sun4v/lib:/SunOS/sw/lib:/
usr/lib:/usr/dt/lib:/usr/openwin/lib:/usr/ucblib:/usr/ecs/antlr-2.7.1/
lib:/usr/ecs/specman-4.0.2/sn_rel4.0.2/solaris:/usr/ecs/lib:/usr/sfw/
lib:/usr/local/lib
THIS SHOULD BE:
$ echo $LD_LIBRARY_PATH
Unset. Nothing. No output. Forget about LD_LIBRARY_PATH
http://xahlee.org/UnixResource_dir/_/ldpath.html
I assumed that was the case - because the LD_LIBRARY_PATH was for Solaris, but
the assura debug output was for Linux, and didn't have any of these paths in...

Next test is to do:

cd /Linux/sw/request/cadence/assura317/tools/assura/bin/64bit
ldd assura

Note that you must be running on the machine to do this. I suspect that the
program may be being run via some wrapper script which sends it onto a compute
farm? (hence the Solaris/Linux discrepancy).

You should get something like:

libm.so.6 => /lib64/tls/libm.so.6 (0x000000321ac00000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003220400000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000321a700000)
libelf.so.1 => /usr/lib64/libelf.so.1 (0x000000321ba00000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x000000321b400000)
libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x0000002a95589000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000321d000000)
libc.so.6 => /lib64/tls/libc.so.6 (0x000000321a900000)
/lib64/ld-linux-x86-64.so.2 (0x000000321a500000)

Regards,

Andrew.

Hi Andrew,

You are right. I am using qshell on my unix machine to log into a
Linux machine where Cadence is running.
I did the test:

cd /Linux/sw/request/cadence/assura317/tools/assura/bin/64bit
ldd assura
libm.so.6 => /lib64/libm.so.6 (0x0000003a4a800000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003a50800000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003a4a400000)
libelf.so.1 => /usr/lib64/libelf.so.1 (0x0000003a4b000000)
libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x00002b5fc82dc000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003a4ac00000)
libstdc++.so.5 => not found
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003a4bc00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003a4a000000)
/lib64/ld-linux-x86-64.so.2 (0x0000003a49800000)

Thanks,
Adam

What OS distribution/version are you running on?

Anyway, I've checked on both RHEL (4 and 5) and SuSE (10) machines and see that
libstdc++.so.5 is in /usr/lib64 on both - and comes in the compat-libstdc++ rpm
package. In SuSE 9 it's in the libstdc++ rpm package.

Looks as if the machine may not have a complete installation of the require OS
pieces. Unfortunately in older releases (IC5141-based releases, including the
ASSURA317/ASSURA32 for IC5141), 64 bit version of libstdc++.so.5 was not shipped
with the installation - it was assumed to be installed as part of the OS.

Best Regards,

Andrew.
Click to expand...
Hi Andrew,

Thanks a lot for you kind help. The information in such a detail
you provided helps a lot.

I will check this issue with the administrator and see if they can
reinstall the OS for the missing libraries.

Thanks again.

Regards,
Lu
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top