Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

linking tests fails with CMAKE_BUILD_TYPE=Debug #117

Closed
dirk-thomas opened this issue Jan 30, 2019 · 7 comments
Closed

linking tests fails with CMAKE_BUILD_TYPE=Debug #117

dirk-thomas opened this issue Jan 30, 2019 · 7 comments
Assignees
Labels

Comments

@dirk-thomas
Copy link
Member

dirk-thomas commented Jan 30, 2019

Without specifying the build type Poco_LIBRARIES contains /usr/lib/libPocoFoundation.so;dl. When building debug the variable only contains dl - I assume because no debug libraries are available on the system.

As a result building the tests fails with unresolved symbols:

../devel/lib/libclass_loader.so: undefined reference to `typeinfo for Poco::RuntimeException'
../devel/lib/libclass_loader.so: undefined reference to `Poco::SharedLibrary::isLoaded() const'
../devel/lib/libclass_loader.so: undefined reference to `Poco::SharedLibrary::suffix[abi:cxx11]()'
../devel/lib/libclass_loader.so: undefined reference to `typeinfo for Poco::LibraryLoadException'
../devel/lib/libclass_loader.so: undefined reference to `typeinfo for Poco::LibraryAlreadyLoadedException'
../devel/lib/libclass_loader.so: undefined reference to `Poco::SharedLibrary::SharedLibrary(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
../devel/lib/libclass_loader.so: undefined reference to `typeinfo for Poco::NotFoundException'
../devel/lib/libclass_loader.so: undefined reference to `Poco::SharedLibrary::unload()'
@nuclearsandwich nuclearsandwich self-assigned this Feb 15, 2019
@nuclearsandwich
Copy link
Member

I'm not able to reproduce this. Can you please share more information about the workspace, environment, and build parameters.

@dirk-thomas
Copy link
Member Author

I'm not able to reproduce this.

Can you describe how you have tried it?

Can you please share more information about the workspace, environment, and build parameters.

Just straight forward building the tests with build type Debug:

source /opt/ros/melodic
cd /tmp
git clone https://github.com/ros/class_loader.git
mkdir class_loader/build
cd class_loader/build
cmake .. -DCMAKE_BUILD_TYPE=Debug
make
make tests

@nuclearsandwich
Copy link
Member

Can you describe how you have tried it?

I built it in a melodic workspace based on a prerelease container I had lying around with catkin_make_isolated.

catkin_make_isolated --cmake-args -DCMAKE_BUILD_TYPE=Debug -DCATKIN_ENABLE_TESTING=ON

@nuclearsandwich
Copy link
Member

I see now. The issue title said building tests fails. But the tests build fine they just don't link correctly when run. Thanks for clarifying your workflow.

@dirk-thomas dirk-thomas changed the title building tests fails with CMAKE_BUILD_TYPE=Debug linking tests fails with CMAKE_BUILD_TYPE=Debug Feb 15, 2019
@nuclearsandwich
Copy link
Member

nuclearsandwich commented Feb 15, 2019

The issue seems to be coming from cmake_modules.

The logic here handles debug libraries. I haven't traced where it's falling down yet.

I did create a little test package that exhibits successful results when finding poco without the cmake_modules package.

Consider

cmake_minimum_required(VERSION 3.5)
project(test_poco CXX)

find_package(catkin REQUIRED COMPONENTS cmake_modules)
find_package(Poco REQUIRED COMPONENTS Foundation)
message(STATUS "Poco_LIBRARIES ${Poco_LIBRARIES}")
$ cmake .. -DCMAKE_BUILD_TYPE=Debug
-- Using CATKIN_DEVEL_PREFIX: /tmp/ws/src/class_loader/test_poco/build/devel
-- Using CMAKE_PREFIX_PATH: /opt/ros/melodic
-- This workspace overlays: /opt/ros/melodic
-- Using PYTHON_EXECUTABLE: /usr/bin/python
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: /tmp/ws/src/class_loader/test_poco/build/test_results
-- Found gmock sources under '/usr/src/googletest': gmock will be built
-- Found gtest sources under '/usr/src/googletest': gtests will be built
-- Using Python nosetests: /usr/bin/nosetests-2.7
-- catkin 0.7.14
-- Searching for Poco library...
--   Found Poco!
-- components found: Foundationd.
-- Poco_LIBRARIES dl
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/ws/src/class_loader/test_poco/build

versus

cmake_minimum_required(VERSION 3.5)
project(test_poco CXX)

#find_package(catkin REQUIRED COMPONENTS cmake_modules)
find_package(Poco REQUIRED COMPONENTS Foundation)
message(STATUS "Poco_LIBRARIES ${Poco_LIBRARIES}")
$ cmake .. -DCMAKE_BUILD_TYPE=Debug
-- The CXX compiler identification is GNU 7.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Poco_LIBRARIES Poco::Foundation
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/ws/src/class_loader/test_poco/build

Which raises the question of whether or not the FindPoco.cmake module is still desired if the cmake config in the upstream package is generally more successful.

@nuclearsandwich
Copy link
Member

ros/cmake_modules#50 is open which is my proposed fix for Melodic.

@dirk-thomas
Copy link
Member Author

ros/cmake_modules#50

Fixed with the latest release of cmake_modules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants