hi guys.
I have a problem building osrm on my centos 7 server. I previously have built it successfully on ubuntu 14.04.
I do similar steps explained in https://github.com/Project-OSRM/osrm-backend/wiki/Building-OSRM and run the following command in order to build the package:
cmake .. -DCMAKE_CC_COMPILER=/usr/local/bin/gcc -DCMAKE_CXX_COMPILER=/usr/local/bin/g++ -DSTXXL_LIBRARY=/usr/lib/libstxxl.a
However the making process fails with the following message:
`-- Building on a 64 bit system
-- Using GNU gold as linker.
-- Disabling gc-sections on gold binutils < 2.26, see: https://sourceware.org/bugzilla/show_bug.cgi?id=17639
-- No build type specified, defaulting to Release
-- Configuring OSRM in release mode
-- Configuring release mode optimizations
-- Setting linker optimizations
CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:1138 (message):
Unable to find the requested Boost libraries.
Boost version: 1.53.0
Boost include path: /usr/include
Detected version of Boost is too old. Requested version was 1.54 (or
newer).
Call Stack (most recent call first):
CMakeLists.txt:451 (find_package)
-- Found Intel TBB
-- TBB interface version: 6103
-- Looking for STXXL...
-- Found STXXL: /usr/lib/libstxxl.a
-- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version "5.2")
-- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version "5.1")
-- Using Lua 5.3.3
-- Looking for protozero
-- Looking for protozero - found
-- OpenMP support found. Linking just in case for stxxl
-- Configuring incomplete, errors occurred!
See also "/home/hadi/osrm-backend/build/CMakeFiles/CMakeOutput.log".
See also "/home/hadi/osrm-backend/build/CMakeFiles/CMakeError.log".
`
And this what is written in CMakeError.log:
`Determining if the pthread_create exist failed with the following output:
Change Dir: /home/hadi/osrm-backend/build/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/gmake "cmTryCompileExec2975653299/fast"
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec2975653299.dir/build.make CMakeFiles/cmTryCompileExec2975653299.dir/build
gmake[1]: Entering directory /home/hadi/osrm-backend/build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report /home/hadi/osrm-backend/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec2975653299.dir/CheckSymbolExists.c.o
/usr/bin/cc -o CMakeFiles/cmTryCompileExec2975653299.dir/CheckSymbolExists.c.o -c /home/hadi/osrm-backend/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c
Linking C executable cmTryCompileExec2975653299
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec2975653299.dir/link.txt --verbose=1
/usr/bin/cc CMakeFiles/cmTryCompileExec2975653299.dir/CheckSymbolExists.c.o -o cmTryCompileExec2975653299 -rdynamic
CMakeFiles/cmTryCompileExec2975653299.dir/CheckSymbolExists.c.o: In functionmain':
CheckSymbolExists.c:(.text+0x16): undefined reference to pthread_create'
collect2: error: ld returned 1 exit status
gmake[1]: *** [cmTryCompileExec2975653299] Error 1
gmake[1]: Leaving directory/home/hadi/osrm-backend/build/CMakeFiles/CMakeTmp'
gmake: * [cmTryCompileExec2975653299/fast] Error 2
File /home/hadi/osrm-backend/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
int main(int argc, char** argv)
{
(void)argv;
return ((int*)(&pthread_create))[argc];
(void)argc;
return 0;
}
Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /home/hadi/osrm-backend/build/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/gmake "cmTryCompileExec3522224044/fast"
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec3522224044.dir/build.make CMakeFiles/cmTryCompileExec3522224044.dir/build
gmake[1]: Entering directory /home/hadi/osrm-backend/build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report /home/hadi/osrm-backend/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec3522224044.dir/CheckFunctionExists.c.o
/usr/bin/cc -DCHECK_FUNCTION_EXISTS=pthread_create -o CMakeFiles/cmTryCompileExec3522224044.dir/CheckFunctionExists.c.o -c /usr/share/cmake/Modules/CheckFunctionExists.c
Linking C executable cmTryCompileExec3522224044
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec3522224044.dir/link.txt --verbose=1
/usr/bin/cc -DCHECK_FUNCTION_EXISTS=pthread_create CMakeFiles/cmTryCompileExec3522224044.dir/CheckFunctionExists.c.o -o cmTryCompileExec3522224044 -rdynamic -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
gmake[1]: *** [cmTryCompileExec3522224044] Error 1
gmake[1]: Leaving directory/home/hadi/osrm-backend/build/CMakeFiles/CMakeTmp'
gmake: * [cmTryCompileExec3522224044/fast] Error 2
`
I understand that the problem is with -lpthreads. But I dont know how to fix it. Any help will be appreciated. Thanks.
@hadi332 the configuration problem is in
Unable to find the requested Boost libraries.
Boost version: 1.53.0
Boost include path: /usr/include
Detected version of Boost is too old. Requested version was 1.54 (or newer).
you have to update the Boost version. The message is misleading because Boost threadcomponent adds -lpthread
Also if you're fine with a pre-made Docker container, check out:
https://hub.docker.com/r/osrm/osrm-backend/
Thank you very much for the responses. I haven't notice that error. I update my boost library and the cmake command is now OK.
Perfect - happy routing! :)
@oxidase , @daniel-j-h
Sorry to continue the thread. In the next step, on calling make command, the process exited with this error:
Linking CXX executable osrm-extract
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../liblua.a(loadlib.o):loadlib.c:function lookforfunc: error: undefined reference to 'dlsym'
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../liblua.a(loadlib.o):loadlib.c:function lookforfunc: error: undefined reference to 'dlerror'
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../liblua.a(loadlib.o):loadlib.c:function lookforfunc: error: undefined reference to 'dlopen'
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../liblua.a(loadlib.o):loadlib.c:function lookforfunc: error: undefined reference to 'dlerror'
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../liblua.a(loadlib.o):loadlib.c:function gctm: error: undefined reference to 'dlclose'
collect2: error: ld returned 1 exit status
make[2]: * [osrm-extract] Error 1
make[1]: [CMakeFiles/osrm-extract.dir/all] Error 2
make: ** [all] Error 2
Any Idea what the problem is?
This is a linker issue and seems to require libdl to be linked in (via -ldl). A quickfix (I think) is to
env LDFLAGS='-ldl' cmake ..
make
From what I can see the Lua .so links against libdl, the .a contains an undefined dlopen symbol.
$ pkg-config --cflags --libs --static lua5.2
-I/usr/include/lua5.2 -llua5.2 -lm -ldl
Could you
cat build/CMakeFiles/osrm-extract.dir/link.txt
and show us the output? There is probably -ldl missing.
Here is the output:
/usr/local/bin/g++ -Wall -Wextra -pedantic -Wuninitialized -Wunreachable-code -Wstrict-overflow=1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fdiagnostics-color=auto -fPIC -ftemplate-depth=1024 -std=c++1y -fopenmp -O3 -DNDEBUG -fuse-ld=gold -Wl,--disable-new-dtags -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common CMakeFiles/osrm-extract.dir/src/tools/extract.cpp.o -o osrm-extract -rdynamic libosrm_extract.a -lboost_program_options -lbz2 -lboost_regex -lboost_date_time -lboost_chrono -lboost_filesystem -lboost_iostreams -lboost_thread -lboost_system -lpthread -lexpat -Wl,-Bstatic -llua -Wl,-Bdynamic -lz -Wl,-Bstatic -lstxxl -Wl,-Bdynamic -ltbb -ltbbmalloc -lbz2 -lboost_regex -lboost_date_time -lboost_chrono -lboost_filesystem -lboost_iostreams -lboost_thread -lboost_system -lpthread -lexpat -Wl,-Bstatic -llua -Wl,-Bdynamic -lz -Wl,-Bstatic -lstxxl -Wl,-Bdynamic -ltbb -ltbbmalloc
I also tried this:
env LDFLAGS='-ldl' cmake ..
make
and nothing changed.
@hadi332 try also to clean cmake cache
rm CMakeCache.txt
env LDFLAGS='-ldl' cmake .. && make
EDIT: from -- Using Lua 5.3.3 -> Lua 5.3 is not supported, probably you can try with lua 5.2, but it is not related to static linking of lua and missing '-ldl'
/cc @daniel-j-h
Thanks. After cleaning cmake cache the make command is done with no error. But when i call the osrm-extract command it fails with this error:
osrm-extract: /lib64/libstdc++.so.6: version GLIBCXX_3.4.20' not found (required by osrm-extract)
osrm-extract: /lib64/libstdc++.so.6: versionCXXABI_1.3.8' not found (required by osrm-extract)
:-(
From the command above
/usr/local/bin/g++
and now
osrm-extract: /lib64/libstdc++.so.6
I guess you have a local more recent gcc / stdlib installation in /usr/local and a global older one in /lib64/. Then your loader does not look into /usr/local/ and tries the old global one, which now fails since it's the old one. Try
env LD_LIBRARY_PATH='/usr/local/lib' ./osrm-extract -p ../profiles/car.lua map.osm.pbf
(I think you can add these paths permanently via /etc/ld.so.conf - this may be system dependant)
Using this command
env LD_LIBRARY_PATH='/usr/local/lib' ./osrm-extract -p ../profiles/car.lua map.osm.pbf
nothing changed. I again get those errors:
./osrm-extract: /lib64/libstdc++.so.6: version GLIBCXX_3.4.20' not found (required by ./osrm-extract)
./osrm-extract: /lib64/libstdc++.so.6: versionCXXABI_1.3.8' not found (required by ./osrm-extract)
I also check the default location of gcc on my server and see that the newer local gcc is used:
[root@localhost build]# which gcc
/usr/local/bin/gcc
@hadi332 It looks like you've got conflicting installs of GCC/libstdc++, or some libraries linked against old versions of those. This is not an OSRM-specific problem, it's something wrong on your system.
Can you please try again with a fresh CentOS install?
A simpler way to get up and running would be to use the pre-built Docker images at https://hub.docker.com/r/osrm/osrm-backend/.
Closing as not actionable on our side. We should upstream the FindLua fixes with CMake anyway.
Feel free to report back how things go and / or re-open if osrm itself fails to build.
I know we had some outdated CentOS documentation on our Wiki and it was a pain to set up with recent compilers, boost, etc. - if you can use the Docker images linked above I would recommend using them.