I'm trying to build a hand model library from libhand.org on Ubuntu 14.04. The library uses ogre and opencv libraries. I followed the instructions provided by the author that allowed me to successfully install ogre and opencv. There is no problem with cmake .. . but during execute command
make -j4
I get the following error:
[ 87%] Building CXX object source/CMakeFiles/hand_renderer.dir/hand_pose.cc.o
[ 91%] Building CXX object source/CMakeFiles/hand_renderer.dir/scene_spec.cc.o
Linking CXX static library libhand_renderer.a
[ 91%] Built target hand_renderer
Scanning dependencies of target pose_designer
[ 95%] Building CXX object source/CMakeFiles/pose_designer.dir/pose_designer_main.cc.o
[100%] Building CXX object source/CMakeFiles/pose_designer.dir/pose_designer.cc.o
Linking CXX executable pose_designer
/usr/bin/ld: cannot find -lNOTFOUND
/usr/bin/ld: cannot find -lNOTFOUND
libhand_utils.a(file_dialog.cc.o): In function
`libhand::FileDialog::TkExec(std::string const&)':
file_dialog.cc:(.text+0xead): warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
collect2: error: ld returned 1 exit status
make[2]: *** [source/pose_designer] Error 1
make[1]: *** [source/CMakeFiles/pose_designer.dir/all] Error 2
make: *** [all] Error 2
Does anyone know why this error occurs and what can be done?
I assume this error occurs because some required library was not found during the run of cmake but that incident was not correctly detected (ie. cmake did not abort with an error). More details on that should be available in a file named CMakeError.log or CMakeOutput.log in the CMakeFiles directory.
The solution to this problem is either installing the missing library (which name should be available from the aforementioned files) or fix the build process to find the library, if it is already installed (for autotools, this would be using the CFLAGS and LDFLAGS environment variables to point to the correct include paths, compiler options, library paths and libraries; that should also work with CMake).
As an alternative explanation, cmake found the library but somehow failed to write the correct Makefiles. Then the solution would be manually replacing -lNOTFOUND by -l<library name> in the Makefiles.
Related
I have no trouble building my application under Visual Studio's environment, but due to lack of experience, I am having trouble under Linux/GCC. Although GCC compiles my app successfully, but it reports linker errors.
The first thing I did was to build a shared library using CMakeLists.txt. The file has no ‘make install’ so I manually copied the shared library file to a global location as follows:
sudo cp libibpp.a /usr/local/lib/
Since applications built with the IBPP library require you to include a single header file, I copied it to a global location:
sudo cp ibpp.h /usr/local/include/
So far, so good but when I run CMake for my application, I am getting linker errors such as:
undefined reference to ‘isc_create_database’
I am successfully using many ‘shared libraries’ in my application (such as Boost Regex/Filesystem/Chrono/DateTime/Thread). The only ‘static library’ that I am using is IBPP (libibpp.a).
I suspect that I am missing something in my application’s CMakeListst.txt:
cmake_minimum_required(VERSION 3.10.2)
project(myapp)
file(GLOB src "*.h" "*.cpp")
add_executable(myapp ${src})
target_link_libraries(myapp ibpp icuuc icudata boost_regex boost_system boost_filesystem
boost_chrono boost_date_time boost_thread pthread)
add_definitions(-DIBPP_LINUX)
Can someone provide me with some hints as to why I get linker errors related to IBPP?
UPDATED:
User n.m. asked me to build using the VERBOSE option, so here is the output:
/usr/bin/cmake -E cmake_link_script CMakeFiles/myapp.dir/link.txt --verbose=1
/usr/bin/c++ CMakeFiles/myapp.dir/appServer.cpp.o CMakeFiles/myapp.dir/app_env.cpp.o CMakeFiles/myapp.dir/app_setting.cpp.o CMakeFiles/myapp.dir/authenticationServer.cpp.o CMakeFiles/myapp.dir/bustacheTestStencil.cpp.o CMakeFiles/myapp.dir/commonKeys.cpp.o CMakeFiles/myapp.dir/dataFetcher.cpp.o CMakeFiles/myapp.dir/fighterKeys.cpp.o CMakeFiles/myapp.dir/fighterProfileJsonGenerator.cpp.o CMakeFiles/myapp.dir/fighterProfileMarkupGenerator.cpp.o CMakeFiles/myapp.dir/fighterStorage.cpp.o CMakeFiles/myapp.dir/forwardProxyServer.cpp.o CMakeFiles/myapp.dir/headerProcessor.cpp.o CMakeFiles/myapp.dir/homepageStencil.cpp.o CMakeFiles/myapp.dir/httpUtils.cpp.o CMakeFiles/myapp.dir/locale.cpp.o CMakeFiles/myapp.dir/main.cpp.o CMakeFiles/myapp.dir/markupServer.cpp.o CMakeFiles/myapp.dir/myTools.cpp.o CMakeFiles/myapp.dir/stdafx.cpp.o CMakeFiles/myapp.dir/unicodeFunctions.cpp.o CMakeFiles/myapp.dir/utils.cpp.o -o myapp -libpp -licutu -licutest -licuio -licui18n -licuuc -licudata -lboost_regex -lboost_system -lboost_filesystem -lboost_chrono -lboost_date_time -lbustache -lboost_thread -lpthread
//usr/local/lib/libibpp.a(_ibpp.cpp.o): In function `ibpp_internals::GDS::Call()':
_ibpp.cpp:(.text+0x2c): undefined reference to `isc_create_database'
_ibpp.cpp:(.text+0x3b): undefined reference to `isc_attach_database'
....
_ibpp.cpp:(.text+0x2bd): undefined reference to `isc_service_start'
_ibpp.cpp:(.text+0x2cf): undefined reference to `isc_service_query'
collect2: error: ld returned 1 exit status
CMakeFiles/myapp.dir/build.make:640: recipe for target 'myapp' failed
make[2]: *** [myapp] Error 1
make[2]: Leaving directory '/home/carol/Documents/vm_shared/AppServer/build'
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/myapp.dir/all' failed
make[1]: *** [CMakeFiles/myapp.dir/all] Error 2
make[1]: Leaving directory '/home/carol/Documents/vm_shared/AppServer/build'
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
Problem solved thanks to comment by n.m. above. Since I was not including libfbclient, I was getting the "undefined references to 'isc_create_database', and other 'isc_...' messages.
Using the settings below, I am now able to use my precompiled/built IBPP library instead of having to include the source code into my application!
Here is a simplified, very barebones CMakeLists.txt that demonstrates what is required to get your IBPP.a implemented into your app without having to include the IBPP source into your app:
file(GLOB src "*.cpp")
add_executable(myapp ${src})
target_link_libraries(myapp ibpp fbclient)
Make note of the order, libibpp must be before libfbclient.
I have python2.7.9 on my new Xubuntu installation, albeit it's 14.04.
PySide installation stuck with Shiboken
Linking CXX shared library libshiboken-python2.7.so
/usr/bin/ld: /usr/local/lib/libpython2.7.a(abstract.o): relocation R_X86_64_32S against `_Py_NotImplementedStruct' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libpython2.7.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [libshiboken/libshiboken-python2.7.so.1.2.2] Error 1
make[1]: *** [libshiboken/CMakeFiles/libshiboken.dir/all] Error 2
make: *** [all] Error 2
error: Error compiling shiboken
After some "googling" I concluded that the problem could be solved with add --enable-shared at ./configure options.
Following docs tried to installed Shiboken in several ways, but after failed, tried to find configure in source files which I couldn't.
Please help. Thank you.
The output is showing that it's trying to link against a static python library, rather than a shared one - i.e. libpython2.7.a, rather than libpython2.7.so.
Thus, it's python that needs to be re-compiled with --enable-shared, not shiboken.
So, I'm trying to build something in make. I produced the files via cmake, went to the appropriate folder for the build file, and:
make
Scanning dependencies of target Spenvis
[ 33%] Building CXX object source/CMakeFiles/Spenvis.dir/pySpenvisCSV.cc.o
[ 66%] Building CXX object source/CMakeFiles/Spenvis.dir/SpenvisCSV.cc.o
[100%] Building CXX object source/CMakeFiles/Spenvis.dir/SpenvisCSVCollection.cc.o
Linking CXX shared library libSpenvis.so
/usr/bin/ld: /usr/local/lib64/libpython2.7.a(abstract.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib64/libpython2.7.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [source/libSpenvis.so] Error 1
make[1]: *** [source/CMakeFiles/Spenvis.dir/all] Error 2
make: *** [all] Error 2
I'm a bit of a novice as far as make/cmake goes. I'm uncertain where to go from here. I've looked at several suggestions, but I'm uncertain which are relevant to my particular problem and how to implement the suggested fixes in the first place.
Halp!
There are two CMakeLists.txt files within the python_utilities directory. I'll include both. One from spenvis_csv/source:
# Make sure the compiler can find include files
include_directories (${PYSPENVIS_SOURCE_DIR})
# get boost
set(Boost_USE_STATIC_LIBS OFF)
#set(Boost_USE_MULTIEADED ON)
find_package(Boost COMPONENTS
python
REQUIRED)
include_directories(${Boost_INCLUDE_DIRS})
link_directories(${Boost_LIBRARY_DIRS})
# get python
include(FindPythonLibs)
set(PythonLibs_USE_STATIC_LIBS OFF)
find_package(PythonLibs REQUIRED)
include_directories(${PYTHON_INCLUDE_DIRS})
link_directories(${PYTHON_LIBRARIES})
#
add_library(Spenvis SHARED pySpenvisCSV.cc SpenvisCSV.cc SpenvisCSVCollection.cc)
TARGET_LINK_LIBRARIES(Spenvis ${Boost_LIBRARIES} ${PYTHON_LIBRARIES})
And then the second much shorter one:
cmake_minimum_required (VERSION 2.6)
set (Boost_NO_BOOST_CMAKE=ON)
project (PYSPENVIS)
add_subdirectory ("source")
You are linking against the static python library which, I believe, is typically not going to be built with -fPIC so it's code won't be relocatable. Your Spenvis target, on the other hand, is a shared library and will be built with -fPIC, but linking in non-PIC code isn't going to work like this. This is what the linker is saying to you.
If it is possible, can you link against the shared version of the python library (i.e. libpython.so.2.7 or something similar, depending on how your system names it)? I would have expected CMake to prefer linking to the shared library by default, so I'm wondering if either:
You are missing the shared libpython library on your system (unlikely, but possible).
You've included some CMake options which tell it to prefer linking in static libraries.
You've explicitly given CMake the static python library to link in somehow.
If you are using the FindPythonLibs CMake module, I would have expected that to be giving you the shared python library in the PYTHON_LIBRARIES variable, if it is available on your system. If you update your question to include your CMakeLists.txt file, that may help identify the problem.
I want to build a project using make in Ubuntu. This project includes VTK, Xerces and Cmake libraries. While builing I get the following error:
Linking CXX static library libMA_LaTIM.a
[ 96%] Built target MA_LaTIM
Scanning dependencies of target MA_LaTIM_entrainement
[100%] Building CXX object applications/CMakeFiles/MA_LaTIM_entrainement.dir/entrainement.cxx.o
Linking CXX executable MA_LaTIM_entrainement
/usr/bin/ld: ../algorithmes/libMA_LaTIM.a(LecteurImage.cxx.o): undefined reference to symbol 'vtkImageAlgorithm::GetOutput()'
/usr/bin/ld: note: 'vtkImageAlgorithm::GetOutput()' is defined in DSO /usr/lib/libvtkFiltering.so.5.8 so try adding it to the linker command line
/usr/lib/libvtkFiltering.so.5.8: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
How can I fix this problem? Here is my CMakeLists.txt, and here is my Makefile.
If you happen to not use cmake to build your application, here is the solution to resolve the linker error undefined reference to symbol with VTK!
The libraries have to be chosen manually. The problem is, that e.g. with my version VTK 6.1 there are 377 shared libs to choose from. Well, some are as before with version 5 but split in Core and special libs.
Others can be found if you check the header of the module the compiler complains about: there is a macro between "class" and the class name: "class VTK_......_EXPORT" , which gives you a hint how the lib is named.
E.g. class VTKRENDERINGCORE_EXPORT vtkRenderer needs library libvtkRenderingCore. Here an example (Linux) which worked for my application:
-L/usr/lib64/vtk -lvtkCommonCore -lvtkFiltersCore -lvtkRenderingCore -lvtkImagingCore -lvtkCommonExecutionModel -l vtkCommonDataModel \
-lvtkFiltersSources -lvtkFiltersGeometry -lvtkFiltersGeneral -lvtkIOCore -lvtkIOImage -lvtkRenderingOpenGL
I have installed boost along with other dependencies needed for Cassandra cpp driver on my ubuntu 12.04 LTS. When I try to run command below it ends up with two errors. I have looked for solutions but can't find any. Some say to link in the libboost_system by adding the option -lboost_system which I tried, but doesn't help.
Here is the cmd: cmake . && make && make cql_demo && make cql_test && make test && make install -lboost_system
All i want to do is to run the demo from the driver and to communicate with the cassandra database!
Errors:
-- info CMAKE_BINARY_DIR: /home/pi/experiments/cpp-driver-master2
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pi/experiments/cpp-driver-master2
[ 42%] Built target cql
[ 85%] Built target cql_static
[ 87%] Built target CCMBridge
Linking CXX executable cql_integration_tests
/usr/bin/ld: warning: libboost_thread.so.1.55.0, needed by /usr/local/lib/libboost_log.so, may conflict with libboost_thread.so.1.46.1
/usr/bin/ld: CMakeFiles/cql_integration_tests.dir/src/test_utils.cpp.o: undefined reference to symbol 'boost::future_category()'
/usr/bin/ld: note: 'boost::future_category()' is defined in DSO /usr/local/lib/libboost_thread.so.1.55.0 so try adding it to the linker command line
/usr/local/lib/libboost_thread.so.1.55.0: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[2]: *** [test/integration_tests/cql_integration_tests] Error 1
make[1]: *** [test/integration_tests/CMakeFiles/cql_integration_tests.dir/all] Error 2
make: *** [all] Error 2
The following error:
/usr/bin/ld: warning: libboost_thread.so.1.55.0, needed by /usr/local/lib/libboost_log.so, may conflict with libboost_thread.so.1.46.1
is basically saying that you have two versions of Boost installed:
Custom built one in /usr/local/lib/, probably version 1.55.0.
Another one in system directories, probably version 1.46.1.
and when they both get linked to your binary version 1.46.1 wins.
You need to see all complete command lines that CMake invokes for you to tell exactly where the problem is.