Comments (15)
Thanks @jcoupey , fix-libosrm-compiling builds and works great with v5.4.0-rc.7
from vroom.
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.
from vroom.
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.
from vroom.
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
from vroom.
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#
from vroom.
Ok, so:
- the compiler error is not about
libosrm
but points toloaders/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).
from vroom.
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
from vroom.
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&&}'
from vroom.
I get the same here after installing libosrm
v5.3.3.
from vroom.
./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(....);
from vroom.
@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.
from vroom.
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.
from vroom.
@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.
from vroom.
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 withpkg-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.
from vroom.
Closing as this is solved as of libosrm
v5.4.0. Related changes are merged in develop
.
from vroom.
Related Issues (20)
- Max distance With relevance to tasks HOT 4
- Time-Windows for jobs or shipments has no effect HOT 1
- Add Parameter for Route Execution Order Based on Task Urgency HOT 6
- Strict access times - Best way to solve? HOT 2
- Solving progress indicator HOT 1
- Log solving profiles
- Wheels for arm64
- API documentation on distance information in output HOT 2
- ORS max waypoints and vroom request HOT 3
- Include setup/service time in cost and add cost per setup/service HOT 1
- Limit option understand HOT 4
- api not optimizing for weight and volume and is always assigning the largest vehicle HOT 2
- Valhalla matrix error (No suitable edges near location). HOT 1
- Shipments with unknown pickup points HOT 3
- Handling Shipments with multiple orders to the Same Address in VROOM HOT 12
- Hierarchical Skill Definitions HOT 2
- Help with shipments and time windows HOT 9
- new step to start at a specific time defined in previous step HOT 3
- Could not find route near location HOT 1
- Clarification Needed About Route Optimization HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vroom.