You are not logged in.
I'm writing a program which uses the boost_filesystem library. I added it to lonker options in my CMake configuration script and everything worked smoothly until today. Now, the linker complains about missing library:
Linking CXX executable GGSPenny
/usr/bin/ld: CMakeFiles/GGSPenny.dir/GGSPenny.cpp.o: undefined reference to symbol 'boost::system::system_category()'
/usr/bin/ld: note: 'boost::system::system_category()' is defined in DSO /usr/lib/libboost_system.so.1.48.0 so try adding it to the linker command line
/usr/lib/libboost_system.so.1.48.0: could not read symbols: Invalid operation
It seems that I also have to add boost_system to linker options. My question is: why should I? Since:
$ ldd /usr/lib/libboost_filesystem.so
linux-gate.so.1 => (0xb78ac000)
libboost_system.so.1.48.0 => /usr/lib/libboost_system.so.1.48.0 (0xb786a000)
librt.so.1 => /lib/librt.so.1 (0xb7861000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7778000)
libm.so.6 => /lib/libm.so.6 (0xb774d000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb7730000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7715000)
libc.so.6 => /lib/libc.so.6 (0xb7598000)
/lib/ld-linux.so.2 (0xb78ad000)
I thought that adding boost_filesystem should be sufficient, and indeed it worked up to today; but now I have to explicitly link also boost_system. I tried to reconfigure the build from scratch and to downgrade to boost 1.47.0 but it didn't help. So what's wrong? Is it in some way related to the recent binutils upgrade to 2.22?
Thanks
Last edited by snack (2011-12-09 22:31:28)
Offline
We'll need the CMake code that is used to build the program, mainly the part in which you find and include the boost package, to give you any help.
Last edited by lunar (2011-12-09 15:53:44)
Offline
CMake code is not necessary. I think this is more or less what is happening:
http://fedoraproject.org/wiki/Understan … LinkChange
Does anyone know if the DSO link change in the above link has been effectively implemented? Their proposed error message looks a lot like the one I'm getting...
Offline
@snack: You're using CMake to configure linking, and you have a linker error now. The CMake code is necessary to help you because it is causing the error, and because it is the place to fix this issue.
ld 2.22 changes the default behaviour to not longer recursively resolve symbols in libraries, meaning that it does by default not longer try to resolve symbols in libraries needed by directly linked libraries. But if you're affected by this change, you're linking indirectly to boost::filesystem although your program uses boost::filesystem directly (as you've said in your first posting). In this case your build system setup is broken regardless of the linker behaviour.
Last edited by lunar (2011-12-09 16:37:14)
Offline
OK, I'm sorry for my misunderstanding. My executable is called GGSPenny and here is its target_link_libraries:
target_link_libraries(GGSPenny #target
GGSVGeometryConstruction
GGSInputParser
GGSMaterials
GGSUserActionsManager
GGSUserActions
GGSServices
GGSPluginManagers
GGSNameDecoder
GGSGenerators
)
The libraries it links are all libraries from my project. One of them, GGSServices, is the one that actually use boost_filesystem:
target_link_libraries(GGSServices GGSTSimInfo boost_filesystem)
This worked up to past week (I've not been able to work on my code for a while), but today it began to give me the errors I reported. Currently, I fix it with:
target_link_libraries(GGSServices GGSTSimInfo boost_filesystem boost_system)
I think and hope this information is sufficient, but I can provide more if needed. I really can't figure out what caused this...
Edit
@lunar: I posted before seeing the edit of your previous post. I think everything is clear now: I was indirectly linking and binutils 2.22 doesn't like this. My fix above works because CMake propagates the linking options of my GGSServices library to whatever links to it, I think. Do you see any other potential pitfall in my fix?
Thanks for your help!
Last edited by snack (2011-12-09 16:43:37)
Offline
@snack: Yes, CMake automatically handles transitive dependencies.
I'd say that you shouldn't directly specifiy the boost library names, but instead use the boost package provided by CMake (e.g. "find_package(Boost filesystem REQUIRED)" and "target_link_libraries(foo ${Boost_LIBRARIES})".)
Offline
Thanks for the hint. I don't want to link all boost libraries, just filesystem (and related) and eventually python if present. These are my find_package lines:
# Optional components (one find_package for each)
find_package(Boost 1.46 QUIET COMPONENTS python)
#Required components
find_package(Boost 1.46 REQUIRED COMPONENTS filesystem)
If i link ${Boost_LIBRARIES}, will I end up linking all Boost libraries or only those I explicitly searched for?
Offline
Boost_LIBRARIES only contains libraries you've searched for. Otherwise you wouldn't need to specify the required libraries in the find_package line, would you?
Offline
Yes, you're right. I'm pretty a CMake noob, and even if your statement is absolutely logical I often don't catch obviousness when dealing with CMake...
Thanks again, marking as solved.
Offline