-
-
Notifications
You must be signed in to change notification settings - Fork 39
boost:1.68: undefined symbol: library depending on boost and build with c++14 #43
Comments
I am sticking with boost-cpp 1.67 for now. But maybe it's possible to use c++14 for the latest bost-cpp. |
I tend to agree with this, archlinux uses c++14 for boost too. |
Switching to boost 1.67 didn't help as -std=c++17 is added by the compiler switch and therefor all gcc-based builds are compiled with c++17. Doing this for boost-cpp 1.69 should be fine as conda-forge-pinnings still list 1.68 as the current boost version. |
Could this be raised more globally (on one of the main conda-forge project repos)? I guess this is not only relevant for Boost? |
You are meant to mask -std=c++17 out in recipes where it is problematic. However I don't believe it's at all related to your issue here. |
Your issue is a missing symbol AFAICT, nothing to do with the language level.
|
I've seen this error before and it's related to the language level because that symbol is defined only if __cplusplus has a certain value |
Right, in that case a simple patch to LaughlinResearch/SMESH would seem appropriate. C++ consider dynamic exception spec. to be a misstep they wish they'd never taken. |
Because boost is build with c++17 all dependencies of boost (especially if build against boost.system) must use c++17 too. I guess boost should be more compatible if build with -std=c++14 (But I am not sure)
Maybe it is possible to build with -std=c++14? (Allthough I don't like the idea. Better make all boost-depending packages c++17 compatible. But this is again a lot of work...)
the reported error at runtime:
runtime error: undefined symbol: _ZN5boost6system6detail24system_category_instanceE
The text was updated successfully, but these errors were encountered: