-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Problem building osrm-backend with osrm-node on Debian Jessie #3978
Comments
Yep, can reproduce in a fresh
Seems like Debian comes with stdlibc++ version 3.4.20 but Mason packages require 3.4.21:
Trusty:
Debian Jessie:
I suspect that's the reason we see undefined references to some stdlib internals. @angelocavallet can you install pre-built binaries via @springmeyer this effectively means we can't build osrm and / or the node bindings with Mason on latest Debian. In contrast running pre-build packages (e.g. the node bindings via |
@daniel-j-h the pre-built seems to work fine on debian Jessie.
I tried to run app.js (which is basically the example.js just fixed the osrm lib dir and .osrm dir)
Is that a problem with .osrm data? |
Yes the problem you are seeing is the data files were generated with a different version. The easiest way to keep them in sync is using the binaries we bundle with the Node.js bindings:
|
Ok, I'll do that and return Just a doubt, what is the difference between ./node_modules/osrm/build/osrm-* and ./node_modules/osrm/lib/binding/osrm-* ? |
is where we put and publish the osrm binaries (generated by Travis). There should be no |
It is an undefined behavior in the pre-built osrm, but works because it does not hit
The problem will be visible when boost or osrm will throw an exception |
@daniel-j-h The pre-built version worked like a charm after regenerate osrm files Thanks for the help and thanks all for this awesome project |
@daniel-j-h @oxidase - thanks for the flag. This feels like more evidence I need to move on mapbox/mason#267. I've started on boost packages that are built against libstdc++-4.8-dev at mapbox/mason#409. I can ping when these are ready and we could test again against debian jessie. Let me know if you have other ideas. |
@springmeyer even if
To switch off lazy bindings and check binary compatibility |
At the moment the loader will lazily resolve symbols at runtime when the first function call happens. This can lead to situations where the libs are not compatible but we are still able to run - until unresolveable symbols are encountered. This changeset tells the loader to resolve all symbols at startup, failing hard immediately if symbols are unresolveable. > now > > When generating an executable or shared library, mark it to tell the > dynamic linker to resolve all symbols when the program is started, > or when the shared library is linked to using dlopen, instead of > deferring function call resolution to the point when the function is > first called. https://linux.die.net/man/1/ld See #3978
@daniel-j-h do you think the issue can be closed? |
@oxidase 👋 I think it is worthwhile testing this again to see if it is resolved. Can someone try to replicate again and see if it is fixed? Context: As part of #4567 we upgraded to the boost 1.65.1 package from mason. That package is built against libstdc++4.8. So I think that |
@springmeyer just checked with |
Hello, first sorry for my awful English, I'm Brazilian.
Since I read that running osrm-routed on production environment is not recommended, I have been trying to install osrm module for nodejs with the new node-osrm merge into osrm-backend but I'm getting some problems with building this on Debian Jessie
Linux 3.16.0-4-amd64 # 1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux
g++ (Debian 4.9.2-10) 4.9.2
gcc (Debian 4.9.2-10) 4.9.2
./usr/lib/x86_64-linux-gnu/libstdc++.so.5.0.7
./usr/lib/x86_64-linux-gnu/libstdc++.so.6
./usr/lib/x86_64-linux-gnu/libstdc++.so.5
./usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20
So, I have to update cmake from default Debian Jessie 3.0.2 to 3.1+ (more specifically 3.7.2) because the building error messages told me to do that.
After update cmake, I tried to build osrm-backend again.
which output the following text:
But when I tried to run "cmake --build ." I got that error:
So, I really don't know whats going on, I'm kinda lost here.
The text was updated successfully, but these errors were encountered: