1

I'm running into a symbol lookup error whenever I run a specific version/configuration of the simulator Gem5, using commit c5ca3ef6b9ff967722b07bc160fa9068e0d9e39c.

The building is done by a SConscript (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)), and after running the program

./build/X86/gem5.opt ./configs/example/se.py -<test program> <configs>

the following error is generated:

symbol lookup error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: undefined symbol: _ZNKSt9type_info11__do_upcastEPKN10__cxxabiv117__class_type_infoEPPv, version GLIBCXX_3.4

Checking nm's output, I notice the symbol is there

nm -D /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep _ZNKSt9type_info11__do_upcastEPKN10__cxxabiv117__class_type_infoEPPv
000000000008e4d0 T _ZNKSt9type_info11__do_upcastEPKN10__cxxabiv117__class_type_infoEPPv

Then, as suggested by another answer, I check ldd:

ldd build/X86/gem5.opt

linux-vdso.so.1 =>  (0x00007fff8b5d9000)
libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007fe4b4534000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe4b4317000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe4b40fd000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe4b3ef5000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe4b3b73000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe4b386a000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe4b3654000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe4b328a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe4b3086000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fe4b2e83000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe4b4ac2000)

And as can be seen, libstdc++ is being chosen correctly. Would anyone have a suggestion to fix this linking problem?

Daniel Carvalho
  • 473
  • 1
  • 5
  • 17
  • what do you get with: objdump -T /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep _ZNKSt9type_info11__do_upcastEPKN10__cxxabiv117__class_type_infoEPPv – Erik Elmgren Mar 28 '18 at 13:26
  • @ErikElmgren 000000000008e4d0 g DF .text 0000000000000003 GLIBCXX_3.4 _ZNKSt9type_info11__do_upcastEPKN10__cxxabiv117__class_type_infoEPPv – Daniel Carvalho Mar 28 '18 at 14:02
  • is the message from the host or the simulated machine? – Erik Elmgren Mar 28 '18 at 14:36
  • I'd say host, but not due to the the simulated program, as it runs smoothly without the simulator, and when using the simulator only one config breaks it. – Daniel Carvalho Mar 28 '18 at 14:38
  • Maybe I misunderstand something, but if the same build/X86/gem5.opt runs with other parameters I'd suspect your error is from inside the simulation and try to run nm etc. inside the simulator to see what's available there. Or some other method to be sure that it's really from the host "side". – Erik Elmgren Mar 28 '18 at 14:45
  • Yes, the error is because the configuration uses a child class that was not being used previously, and it may generate other calls. I'm pretty sure the error is on the host side, while executing simulator's code. I don't understand what you mean by running nm inside the simulator. Do you mean passing it as a program to be run by the simulator? – Daniel Carvalho Mar 28 '18 at 14:48
  • Yes, passing it as a program to be run by the simulator is what I mean. – Erik Elmgren Mar 28 '18 at 14:51
  • I'm unable to do so, as nm can't be loaded. – Daniel Carvalho Mar 28 '18 at 15:05

0 Answers0