RackSDK.cmake bugs?

[Doom2fan]

I'm making this issue here as a heads-up for potential issues:

In my own plugin, I had issues when trying to update the toolchain for the CI where the Windows builds would fail to load.
This seems to be caused by the link flag for statically linking libstdc++ not actually being set properly. While investigating this, I've also found out some other compilation flags (namely, -march) weren't getting set properly either.

I opened an issue in qno's repo here.
This seems to be caused by RackSDK.cmake using add_link_options and add_compile_options after add_library(${RACK_PLUGIN_LIB} MODULE), moving those commands before that line seems to fix the issues.
I've fixed this in my plugin, feel free to use it if desired.

[baconpaul]

This sounds like the exact same issue as this one: VCVRack/rack-plugin-toolchain#41

has the SDK and toolchain been changed to static? If so then yes we will need to update our cmake based workflow too.

Tagging in @cschol also

[Doom2fan]

This sounds like the exact same issue as this one: VCVRack/rack-plugin-toolchain#41

has the SDK and toolchain been changed to static? If so then yes we will need to update our cmake based workflow too.

Tagging in @cschol also

I think that one is the opposite issue, the normal VCV plugin Makefile has always had -static-libstdc++ set correctly (and now there's problems with different versions of libstdc++ between VCV and plugins), whereas qno's CMake file wasn't setting it properly.
I used Bloodbat's updated Docker image to get the updated toolchain, and that seems to have a downgraded version of crosstool-ng. I don't think it's the same issue, since my plugin was still failing to load...

[baconpaul]

OK so clearly the cmake should do what the sdk does; you are saying it doesn't it seems because of that ordering?

@cschol do we know if the rack sdk is changing this flag?

[Doom2fan]

That's indeed what I'm saying. If you instruct CMake to generate Makefiles and search in the build directory's files, you can see that -static-libstdc++ is missing, and -march=nehalem is only present for code included after RackSDK.cmake has been included, and not the plugin's own source files.

With my own plugin, using Bloodbat's modified updated toolchain with downgraded crosstool-ng, the plugin fails to load without statically linking libstdc++, but does work if it is statically linked.

Just to be sure, I just tested building my plugin with a "standard" Rack plugin Makefile, and my "clean" Docker image of the new toolchain. Filtering out -static-libstdc++ from LDFLAGS after including Rack's plugin.mk makes the plugin fail to load with the official build of Rack 2.6.3, just like with the incorrectly-ordered CMake file... But not filtering it out crashes, as reported in VCVRack/rack-plugin-toolchain#41.

[baconpaul]

oh i see we need that option for all of surge as well. I get it.

wonder why it works until now?

[baconpaul]

OK I merged this change.

Does it fix the problem you saw do you know?

[Doom2fan]

On my plugin, it fixed the library load error. I haven't tested it with Surge (I don't use the toolchain locally and would need to somehow make a CI build with an updated toolchain), but I reported the issue in that thread about the -static-libstdc++ issues and Andrew confirmed it.