Compiling issue with libosrm v5.3.3

[vroom-project]

Compiling issue with libosrm v5.3.3

[chesty]

Thanks @jcoupey , fix-libosrm-compiling builds and works great with v5.4.0-rc.7

[jcoupey]

You're correct, pkg-config does come into play here to know whether libosrm stuff should be included (and how). What are the results for:

pkg-config --libs libosrm
pkg-config --cflags libosrm

on your setup? Those two commands should provide the relevant compilation options when you run make (see check in the makefile). Is this how the build command you posted was generated? (Just want to make sure).

Regarding the error itself, it looks like the compiler is unable to deduce the correct type for the lambda parameter at https://github.com/VROOM-Project/vroom/blob/release-v1.0.0/src/loaders/tsplib_loader.h#L213. Using auto in this case should be all right with C++14 though. I wonder if the -std=c++1y found in your command is not messing up with the initial -std=c++14 flag.

[chesty]

root@osrm:/src/vroom/src# pkg-config --libs libosrm
-L/usr/local/lib -losrm
root@osrm:/src/vroom/src# pkg-config --cflags libosrm
-DBOOST_TEST_DYN_LINK -DBOOST_SPIRIT_USE_PHOENIX_V3 -DBOOST_RESULT_OF_USE_DECLTYPE -DBOOST_FILESYSTEM_NO_DEPRECATED -flto=4 -Wall -Wextra -pedantic -Wuninitialized -Wunreachable-code -Wstrict-overflow=1 -D_FORTIFY_SOURCE=2 -fdiagnostics-color=auto -fPIC -ffunction-sections -fdata-sections -std=c++1y -fopenmp -I/usr/local/include -I/usr/local/include/osrm -I/src/osrm-backend/third_party/libosmium/include -I/usr/include/luabind -I/usr/include/lua5.2
root@osrm:/src/vroom/src# 

Is this how the build command you posted was generated?

yes, from running make

I wonder if the -std=c++1y

I reran the command without -std=c++1y , i got the same error.

this is the relevant bits from the Dockerfile,

FROM ubuntu:xenial

ENV OSRM_BACKEND_VERSION v5.3.3
RUN apt-get update && \
    apt-get install -y \
        build-essential \
        cmake \
        git-core \
        libboost-all-dev \
        libboost-filesystem1.58.0 \
        libboost-iostreams1.58.0 \
        libboost-program-options1.58.0 \
        libboost-regex1.58.0 \
        libboost-system1.58.0 \
        libboost-thread1.58.0 \
        libbz2-dev \
        libexpat1 \
        libgomp1 \
        liblua5.1-dev \
        liblua5.2-0 \
        libluabind-dev \
        libluabind0.9.1v5 \
        libluajit-5.1-dev \
        libosmpbf-dev \
        libpng16-dev \
        libprotobuf-dev \
        libprotobuf9v5 \
        libprotoc-dev \
        libstxxl-dev \
        libstxxl1v5 \
        libtbb-dev \
        libtbb2 \
        libxml2-dev \
        libzip-dev \
        lua5.1 \
        luajit \
        pkg-config \
        protobuf-compiler && \
    mkdir /src && \
    cd /src && \
    git clone --depth 1 https://github.com/Project-OSRM/osrm-backend && \
    cd osrm-backend && \
    mkdir -p build && \
    cd build && \
    cmake .. -DCMAKE_BUILD_TYPE=Release && \
    cmake --build . && \
    cmake --build . --target install && \
    mkdir -p /usr/local/share/osrm/profiles && \
    cp -a /src/osrm-backend/profiles/* /usr/local/share/osrm/profiles
#    apt-get purge -y \
#        *-dev \
#        build-essential \
#        cmake \
#        krb5-locales \
#        make \
#        wget && \
#    apt-get autoremove --purge -y && \
#    apt-get clean && \
#    cd / && \
#    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* /src

#RUN dpkg -l > /b.a
#RUN find / -xdev > /b.f
ENV VROOM_BRANCH develop
RUN mkdir -p /src && \
    cd /src && \
    apt-get update && \
    apt-get install -y \
        build-essential \
        g++ \
        git-core \
        libboost-log-dev \
        libboost-regex-dev \
        libboost-system-dev \
        libboost-thread-dev \
        pkg-config \
        make && \
    git clone --depth 1 --branch $VROOM_BRANCH https://github.com/VROOM-Project/vroom.git && \
    cd vroom && \
    mkdir -p /src/vroom/bin && \
    cd /src/vroom/src

You might be able to see what's going on from the above, but If you wanted to test in the same env as me and you haven't played with docker before, after installing docker, paste the above in a file called Dockerfile in an empty directory, and run

docker build -t vroom .
docker run --rm -ti vroom

the second command will put you in a bash shell inside the container. Of course I'm happy to try anything else you want to me to try.

[jcoupey]

Thanks for the details. I can't see anything wrong with your setting so far...

What puzzles me is that the compiler raises an error about something in loaders/tsplib_loader.h, which is always used in the build, no matter if libosrm is installed or not.

Can you try to re-build without libosrm installed to make sure this part of the code builds all right? The "basic" compiler flags generated when running make should look like:

g++ -std=c++14 -Wextra -Wpedantic -Wall -O3 -DBOOST_LOG_DYN_LINK -c main.cpp -o main.o

[chesty]

I just ran that g++ command, and it worked, also if I remove pkg-config, I can build it ok.

root@9ce94c9c4651:/src/vroom/src# apt-get purge pkg-config
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  pkg-config*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 177 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 35171 files and directories currently installed.)
Removing pkg-config (0.29.1-0ubuntu1) ...
Purging configuration files for pkg-config (0.29.1-0ubuntu1) ...
root@9ce94c9c4651:/src/vroom/src# make
/bin/sh: 1: pkg-config: not found
g++ -std=c++14 -Wextra -Wpedantic -Wall -O3 -DBOOST_LOG_DYN_LINK -c heuristics/mst_heuristic.cpp -o heuristics/mst_heuristic.o
g++ -std=c++14 -Wextra -Wpedantic -Wall -O3 -DBOOST_LOG_DYN_LINK -c heuristics/heuristic.cpp -o heuristics/heuristic.o
g++ -std=c++14 -Wextra -Wpedantic -Wall -O3 -DBOOST_LOG_DYN_LINK -c heuristics/tsp_strategy.cpp -o heuristics/tsp_strategy.o
g++ -std=c++14 -Wextra -Wpedantic -Wall -O3 -DBOOST_LOG_DYN_LINK -c heuristics/christo_heuristic.cpp -o heuristics/christo_heuristic.o
g++ -std=c++14 -Wextra -Wpedantic -Wall -O3 -DBOOST_LOG_DYN_LINK -c heuristics/local_search.cpp -o heuristics/local_search.o
g++ -std=c++14 -Wextra -Wpedantic -Wall -O3 -DBOOST_LOG_DYN_LINK -c structures/tsp.cpp -o structures/tsp.o
g++ -std=c++14 -Wextra -Wpedantic -Wall -O3 -DBOOST_LOG_DYN_LINK -c utils/exceptions.cpp -o utils/exceptions.o
g++ -std=c++14 -Wextra -Wpedantic -Wall -O3 -DBOOST_LOG_DYN_LINK -c utils/logger.cpp -o utils/logger.o
g++ -std=c++14 -Wextra -Wpedantic -Wall -O3 -DBOOST_LOG_DYN_LINK -o ../bin/vroom main.o heuristics/mst_heuristic.o heuristics/heuristic.o heuristics/tsp_strategy.o heuristics/christo_heuristic.o heuristics/local_search.o structures/tsp.o utils/exceptions.o utils/logger.o -lboost_system -lboost_regex -lboost_log -lboost_log_setup -lpthread -lboost_thread
root@9ce94c9c4651:/src/vroom/src# 

[jcoupey]

Ok, so:

• the compiler error is not about libosrm but points to loaders/tsplib_loader.h;
• this file doesn't do anything related to libosrm;
• this file builds all right when removing the libosrm-related set of flags.

Seems like the problem lies in the build context introduced by one of the flags retrieved with pgk-config.

What if you reduce the command to:

 g++ -std=c++14 -Wextra -Wpedantic -Wall -O3 -DBOOST_LOG_DYN_LINK -I/usr/local/include -I/usr/local/include/osrm -D LIBOSRM=true -c main.cpp -o main.o

which is the line I get when I run make (I'm using libosrm v5.1.0).

[chesty]

if I delete -D LIBOSRM=true from the below command, it runs ok.

g++ -std=c++14 -Wextra -Wpedantic -Wall -O3 -DBOOST_LOG_DYN_LINK -DBOOST_TEST_DYN_LINK -DBOOST_SPIRIT_USE_PHOENIX_V3 -DBOOST_RESULT_OF_USE_DECLTYPE -DBOOST_FILESYSTEM_NO_DEPRECATED -flto=4 -Wall -Wextra -pedantic -Wuninitialized -Wunreachable-code -Wstrict-overflow=1 -D_FORTIFY_SOURCE=2 -fdiagnostics-color=auto -fPIC -ffunction-sections -fdata-sections -std=c++1y -fopenmp -I/usr/local/include -I/usr/local/include/osrm -I/src/osrm-backend/third_party/libosmium/include -I/usr/include/luabind -I/usr/include/lua5.2 -D LIBOSRM=true -c main.cpp -o main.o

[chesty]

What if you reduce the command to:

g++ -std=c++14 -Wextra -Wpedantic -Wall -O3 -DBOOST_LOG_DYN_LINK -DBOOST_TEST_DYN_LINK -DBOOST_SPIRIT_USE_PHOENIX_V3 -DBOOST_RESULT_OF_USE_DECLTYPE -DBOOST_FILESYSTEM_NO_DEPRECATED -flto=4 -Wall -Wextra -pedantic -Wuninitialized -Wunreachable-code -Wstrict-overflow=1 -D_FORTIFY_SOURCE=2 -fdiagnostics-color=auto -fPIC -ffunction-sections -fdata-sections -std=c++1y -fopenmp -I/usr/local/include -I/usr/local/include/osrm -I/src/osrm-backend/third_party/libosmium/include -I/usr/include/luabind -I/usr/include/lua5.2 -D LIBOSRM=true -c main.cpp -o main.o

/usr/local/include/osrm/util/coordinate.hpp:50:1: note: candidate: osrm::util::FloatLatitude::FloatLatitude()
 OSRM_STRONG_TYPEDEF(double, FloatLatitude)
 ^
/usr/local/include/osrm/util/coordinate.hpp:50:1: note:   candidate expects 0 arguments, 1 provided
/usr/local/include/osrm/util/coordinate.hpp:50:1: note: candidate: constexpr osrm::util::FloatLatitude::FloatLatitude(const osrm::util::FloatLatitude&)
/usr/local/include/osrm/util/coordinate.hpp:50:1: note:   no known conversion for argument 1 from 'const double' to 'const osrm::util::FloatLatitude&'
/usr/local/include/osrm/util/coordinate.hpp:50:1: note: candidate: constexpr osrm::util::FloatLatitude::FloatLatitude(osrm::util::FloatLatitude&&)
/usr/local/include/osrm/util/coordinate.hpp:50:1: note:   no known conversion for argument 1 from 'const double' to 'osrm::util::FloatLatitude&&'
In file included from main.cpp:24:0:
./loaders/libosrm_loader.h:122:61: error: no matching function for call to 'std::vector<osrm::util::Coordinate>::push_back(<brace-enclosed initializer list>)'
             osrm::util::FloatLatitude(_locations[step].lat)});
                                                             ^
In file included from /usr/include/c++/5/vector:64:0,
                 from /usr/include/c++/5/bits/random.h:34,
                 from /usr/include/c++/5/random:49,
                 from /usr/include/c++/5/bits/stl_algo.h:66,
                 from /usr/include/c++/5/algorithm:62,
                 from /usr/include/boost/smart_ptr/shared_ptr.hpp:37,
                 from /usr/include/boost/log/core/core.hpp:19,
                 from /usr/include/boost/log/core.hpp:20,
                 from main.cpp:12:
/usr/include/c++/5/bits/stl_vector.h:913:7: note: candidate: void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = osrm::util::Coordinate; _Alloc = std::allocator<osrm::util::Coordinate>; std::vector<_Tp, _Alloc>::value_type = osrm::util::Coordinate]
       push_back(const value_type& __x)
       ^
/usr/include/c++/5/bits/stl_vector.h:913:7: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'const value_type& {aka const osrm::util::Coordinate&}'
/usr/include/c++/5/bits/stl_vector.h:931:7: note: candidate: void std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, _Alloc>::value_type&&) [with _Tp = osrm::util::Coordinate; _Alloc = std::allocator<osrm::util::Coordinate>; std::vector<_Tp, _Alloc>::value_type = osrm::util::Coordinate]
       push_back(value_type&& __x)
       ^
/usr/include/c++/5/bits/stl_vector.h:931:7: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'std::vector<osrm::util::Coordinate>::value_type&& {aka osrm::util::Coordinate&&}'

[jcoupey]

I get the same here after installing libosrm v5.3.3.

[daniel-j-h]

./loaders/libosrm_loader.h:122:61: error: no matching function for call to 'std::vector<osrm::util::Coordinate>::push_back(<brace-enclosed initializer list>)'

From the error message it looks like you're doing something like

std::vector<osrm::util::Coordinate> v;
v.push_back({....});

Try instead either

v.push_back(osrm::util::Coordinate{....});

or

v.emplace_back(....);

[jcoupey]

@daniel-j-h thanks for the input. I'm a bit puzzled here as the quoted push_back line is fine with libosrm v5.1.0 but raises the mentioned error when linking to v5.3.3.

The reason why I didn't use emplace_back in the first place was that I then get this error (reproduced with previous commit e9d8346):

/usr/local/include/osrm/util/coordinate.hpp:134:5: note:   no known conversion for argument 1 from ‘const double’ to ‘osrm::util::FloatLongitude’

I fail to see the problem for constructing the object using https://github.com/Project-OSRM/osrm-backend/blob/master/include/util/coordinate.hpp#L134.

[daniel-j-h]

Ah, I see emplace does not work since the Lat / Lon types have explicit constructors, so you really have to wrap your doubles in these types first. This was done mainly to avoid the common lat <-> lon swap confusion, but makes things a bit more verbose for sure.

[jcoupey]

@daniel-j-h thanks for the explanation, emplace_back used with osrm::util::FloatLongitude({my_double}) gets rid of all coordinates constructions errors.

I also had to adapt the call to the osrm::RouteParameters constructor as the signature changes with v5.2 (Project-OSRM/osrm-backend@fa525ad). In order to support all v5.* versions of libosrm I might need a pkg-config --modversion-based hack.

It now all comes down to the extra -std=c++11 reported with pkg-config --cflags libosrm in v5.3, and v5.4 is fine.

[jcoupey]

So

• the current fix in 3059458 is not backward compatible with libosrm v5.1.
• with libosrm v5.2 and v5.3, building out of the box with pkg-config hits the -std=c++11 flag.
• everything is fine with v5.4.0-rc.7.

In my opinion, we should wait for v5.4 to ship before merging and only advertise libosrm support as of this version.

@chesty if you want to give it a try, you can install libosrm v5.4.0-rc.7 and checkout to the fix-libosrm-compiling branch.

[jcoupey]

Closing as this is solved as of libosrm v5.4.0. Related changes are merged in develop.