Hi Ali,
If I set LD_LIBRARY_PATH AND LIBRARY_PATH env variables, then executing results
in:
Traceback (most recent call last):
File "<string>", line 1, in ?
File
"/share/projects10/IPproject/workspace/kalai.rajah/gem5/gem5-56610ab73040/src/python/importer.py",
line 73, in load_module
exec code in mod.__dict__
File
"/share/projects10/IPproject/workspace/kalai.rajah/gem5/gem5-56610ab73040/src/python/m5/__init__.py",
line 35, in ?
import internal
File
"/share/projects10/IPproject/workspace/kalai.rajah/gem5/gem5-56610ab73040/src/python/importer.py",
line 73, in load_module
exec code in mod.__dict__
File
"/share/projects10/IPproject/workspace/kalai.rajah/gem5/gem5-56610ab73040/src/python/m5/internal/__init__.py",
line 31, in ?
import event
File
"/share/projects10/IPproject/workspace/kalai.rajah/gem5/gem5-56610ab73040/src/python/importer.py",
line 73, in load_module
exec code in mod.__dict__
File
"/share/projects10/IPproject/workspace/kalai.rajah/gem5/gem5-56610ab73040/build/ARM/python/swig/event.py",
line 107, in ?
class Event(m5.internal.serialize.Serializable):
AttributeError: 'module' object has no attribute 'internal'
But I see that ldd on the executable has the intended library being picked up:
ldd ./build/ARM/gem5.opt
linux-vdso.so.1 => (0x00007fffcce99000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030a4e00000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000030a4600000)
libutil.so.1 => /lib64/libutil.so.1 (0x00000030b0400000)
libpython2.4.so.1.0 => /usr/lib64/libpython2.4.so.1.0
(0x00000030b6c00000)
libz.so.1 => /share/projects/IP/local_2/lib64/libz.so.1
(0x00002b8630324000)
librt.so.1 => /lib64/librt.so.1 (0x00000030a8a00000)
libstdc++.so.6 => /share/projects/IP/local_2/lib64/libstdc++.so.6
(0x00002b863053d000)
libm.so.6 => /lib64/libm.so.6 (0x00000030a4a00000)
libgcc_s.so.1 => /share/projects/IP/local_2/lib64/libgcc_s.so.1
(0x00002b8630842000)
libc.so.6 => /lib64/libc.so.6 (0x00000030a4200000)
/lib64/ld-linux-x86-64.so.2 (0x00000030a3a00000)
I’ll also run with the –verbose option to see the linker commands.
-Kalai
From: gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org] On
Behalf Of Ali Saidi
Sent: Wednesday, January 09, 2013 2:29 PM
To: gem5 users mailing list
Subject: Re: [gem5-users] LD_LIBRARY_PATH & LIBRARY_PATH
Hi Kalai,
I haven't seen that error before, but I'd guess it would might have something
to do with how gcc was configured. You might want to turn on the verbose option
(--verbose) and take a look at the command lines being generated by the linker.
Additionally, you probably need to set LD_LIBRARY_PATH before running gem5 so
the dynamic linker looks for libraries in the correct location.
Ali
On 09.01.2013 13:51, Kalai Narayanan-SSI wrote:
Hi,
My command for building is:
../../scons/scons-2.2.0/build/scripts/scons build/ARM/gem5.opt
SWIG=/share/projects10/IPproject/workspace/kalai.rajah/swig/swig-2.0.9/bin/swig
CXX=/share/projects/IP/local_2/bin/g++ --no-colors
LD_LIBRARY_PATH=/share/projects/IP/local_2/lib64/
LIBRARY_PATH=/share/projects/IP/local_2/lib64/
The compile goes fine.
But when I execute, I see the GLIBCXX_3…. Not found error.
When I do ldd on build/ARM/gem5.opt, I see that it uses /usr/lib64 for
libstdc++.so.6
Why is scons picking up the libraries from /usr/lib64 and not from what is
passed on the command line for LIBRARY_PATH/LD_LIBRARY_PATH?
Thanks,
Kalai
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
