Runtime linking issues - GLIBCXX_3.4.21 not found & possible support for GLIBCXX_3.4.19 ?

[vvzen]

Hi,

and thanks for open sourcing your work!
I'm trying to build the plugin manually for nuke11.3v4 on Centos 7.7.1908, but our version of /lib64/libstdc++.so.6 only goes up to GLIBCXX_3.4.19, which means I get this error at runtime when trying out the DeepC nodes:

RuntimeError: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /my/custom/path/to/plugins/DeepCPNoise.so)

Is there anything specific in your code that needs to be using the GLIBCXX_3.4.21 symbols? I was wondering if somehow the cmake file (and the code, if needed) could be updated to work with a lower version of libstdc++.

Or am I getting this wrong?
I premise I'm not an expert of the cmake and c++ toolchains.
I'm build with cmake using this command, since otherwise FindNuke.cmake didn't see to find nuke:

cmake -DNuke_ROOT=/opt/foundry/nuke-11.3v4 -D CMAKE_INSTALL_PREFIX="`pwd`/../install" ..

Thanks!

Valerio

[charlesangus]

Do you have devtoolset installed and sourced when you build? That's my first guess.

It's also possible there are multiple versions of libstdc++, try running:

locate libstdc++

[charlesangus]

Basically, it seems like you're compiling with one version of libstdc++ but nuke isn't finding that version, so locate could help us track down where the different ones are, so you can either compile with the one nuke is using, or get nuke to use the one you compiled with.

[vvzen]

Thanks for the prompt reply.
I wish I had more CMake knowledge, but let's say that I've managed to run nuke with the "same" environment that I'm using to compile the plugins. So now some node works!

But others crash with a SIGILL:

#0  0x00007fbb40211949 in FastNoise::SetSeed(int) () at /my/path/to/DeepCPNoise.so

I wonder if it's caused by this line in the FastNoise.cpp : std::mt19937_64 gen(seed); ?

[charlesangus]

That would seem to be the case, that's a C++ 11 function, so it's possible you're using a compiler which is too old.

Which version of GCC and devtoolset are you using?

[charlesangus]

Just checked, looks like last time I compiled this I used devtoolset-6 and gcc-6.3.1 - is it possible for you to try with devtoolset-6 installed and enabled? (Also looks like I need to update the readme if devtoolset-3 doesn't work anymore).

[vvzen]

I'm on gcc 5.5.0, cmake version 3.5.2. Not sure how to check the version of the toolset since I can't run any sudo yum commands on that specific workstation.

I also added a add_definitions(-D_GLIBCXX_USE_CXX11_ABI=0) to the CMakeLists.txt file after stumbling upon TheFoundryVisionmongers/nuke-ML-server#15 since I was running into the same error (undefined symbol: _ZNK2DD5Image2Op15input_longlabelB5cxx11Ei) and that flag seemed to have sorted it. Do you think it's related?

[charlesangus]

Yeah, I think your problems are probably related to not having devtoolset installed and enabled and/or the wrong devtoolset installed/enabled.

Run:

yum list installed | grep devtoolset

And see if it's installed, and if so, which version. If it is, try running:

source /opt/rh/devtoolset-6/enable

And then trying to build. (I can confirm devtoolset-6 works, others may as well, if you have a different one, just change the number and try it). This will enable the devtoolset tools which you need to build successfully on CentOS/RH.