Assura LVS problem

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:

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

 

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:

What does

echo $LD_LIBRARY_PATH

show?

And what does:

assura -debug3264

output?

Regards,

Andrew.

 

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

 

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:

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

 

Adam wrote, on 01/09/09 16:35:

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.

 

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