1

I re-organized the directory tree of an existing project, making relevant Sconscript changes, and in so-doing I introduced the following linker error:

/bin/ld: note: '__cxa_free_exception@@CXXABI_1.3' is defined in DSO /usr/lib64/libstdc++.so.6 so try adding it to the linker command line /usr/lib64/libstdc++.so.6: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status

I found this thread and if I follow that advice and attempt to be explicit about the system libs it just kicks the can down the road (the ensuing error will be about libm and so on with other system libs).

Since this compiles fine without my reorganization, what could have been done to scons where it no longer links to system libs?

Nowhere in the existing SConstruct/Sconscript fileset is there any reference to linking against any of the system libs. This was automagically done by scons, but now that I have rearranged a few subprojects, I encounter the above error.

The libpath and rpath both include the following: '/usr/lib64', '/usr/lib64/mysql', '/usr/local/lib',

Linker Command

gcc -o build/debug/icln/src/foo/fooCert/build/scons/fooCertFromFiles -Wl,-rpath=/usr/lib64 -Wl,-rpath=/usr/lib64/mysql -Wl,-rpath=/usr/local/lib -Wl,-rpath=/ws/build/debug/icmn/src/common -Wl,-rpath=../../../../engine/build/scons -Wl,-rpath=../../../../foo/build/scons -Wl,-rpath=../../../../kb/build/scons -Wl,-rpath=../../../../bar/build/scons -Wl,-rpath=../../../../tables/build/scons -Wl,-rpath=../../../../utils/build/scons -L/usr/lib64 -L/usr/lib64/mysql -L/usr/local/lib -Lbuild/debug/icmn/src/common -L/ws/icmn/src/common -Lbuild/debug/icln/src/engine/build/scons -Lsrc/engine/build/scons -Lbuild/debug/icln/src/foo/build/scons -Lsrc/foo/build/scons -Lbuild/debug/icln/src/kb/build/scons -Lsrc/kb/build/scons -Lbuild/debug/icln/src/bar/build/scons -Lsrc/bar/build/scons -Lbuild/debug/icln/src/tables/build/scons -Lsrc/tables/build/scons -Lbuild/debug/icln/src/utils/build/scons -Lsrc/utils/build/scons -lcengine -lbar -lfoo -lkb -lcutils -lCommon -ltables -lglog -lboost_date_time -lboost_serialization -lboost_system -lboost_filesystem -lmongoclient -lboost_thread -lpthread -lmysqlcppconn -lmysqlclient

Update: I noticed the call to build the final binary was to gcc, and not g++. I am still trying to determine why it suddenly switched to gcc instead of g++, but I think this is heading towards root cause.

How does scons determine whether to invoke CC vs CXX?

Community
  • 1
  • 1
rkemp
  • 278
  • 3
  • 14
  • What is your linker line? Maybe you have a library which wants to link to an older (newer) libstdc++ you currently have. – erenon Mar 02 '15 at 18:41
  • @erenon: possibly the libmongoclient since that's who's emitting the undefined reference. However, this hasn't changed from before and after my re-org. – rkemp Mar 02 '15 at 18:48
  • Did you tried call scons with `--implicit-deps-changed` or removing `.sconsign.dblite`? SCons caches some dependencies in internal database so it won't check them again, so after refactoring they may be still in place. – myaut Mar 02 '15 at 19:25
  • Yes, I completely wiped out the build directory. – rkemp Mar 02 '15 at 19:36
  • @rkemp, `.sconsign.dblite` is located in the same directory where you invoke `scons`. Anyway, regarding >How does scons determine whether to invoke CC vs CXX?< - it does it based on source's file extension: .cpp, .cc, .cxx, .c++, .C++, .mm, .C - are considered C++ sources. I had weird problem when one of file had .d extension and SCons called D linker on entire library. – myaut Mar 02 '15 at 19:47

1 Answers1

0

Solved: So because of the re-organization I performed, a call to Glob() was resolving to an empty list since I had changed the path to where the source files are.

The fix: I needed to update the Glob call to use new path to the source (the Sconscript and source files no longer co-reside in the same directory as they did before).

BEFORE

source = Glob('*.cc')

AFTER

source = Glob('../../src/*.cc')
rkemp
  • 278
  • 3
  • 14