boost:1.68: undefined symbol: library depending on boost and build with c++14

[looooo]

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

[looooo]

I am sticking with boost-cpp 1.67 for now. But maybe it's possible to use c++14 for the latest bost-cpp.
@jschueller @isuruf and other boost-maintainers.

[jschueller]

I tend to agree with this, archlinux uses c++14 for boost too.

[looooo]

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.

[xhochy]

Could this be raised more globally (on one of the main conda-forge project repos)? I guess this is not only relevant for Boost?

[mingwandroid]

Switching to boost 1.67 didn't help as -std=c++17

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.

[mingwandroid]

Your issue is a missing symbol AFAICT, nothing to do with the language level.

c++filt _ZN5boost6system6detail24system_category_instanceE
boost::system::detail::system_category_instance

[isuruf]

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

[mingwandroid]

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.