I was trying to build the latest FrozenWasteland plugin commit with rack-plugin-toolchain and the build fails on the MacOS version:
x86_64-apple-darwin19-clang++-libc++ -o plugin.dylib build/src/BPMLFO2.cpp.o build/src/BPMLFO.cpp.o build/src/BPMLFOPhaseExpander.cpp.o build/src/CDCSeriouslySlowLFO.cpp.o build/src/DamianLillard.cpp.o build/src/DrunkenRampage.cpp.o build/src/EverlastingGlottalStopper.cpp.o build/src/FrozenWasteland.cpp.o build/src/HairPick.cpp.o build/src/HyperMeasures.cpp.o build/src/JustAPhaser.cpp.o build/src/LissajousLFO.cpp.o build/src/ManicCompression.cpp.o build/src/ManicCompressionMB.cpp.o build/src/Midichlorian.cpp.o build/src/MrBlueSky.cpp.o build/src/PhasedLockedLoop.cpp.o build/src/PNChordExpander.cpp.o build/src/PortlandWeather.cpp.o build/src/ProbablyNoteArabic.cpp.o build/src/ProbablyNoteBP.cpp.o build/src/ProbablyNote.cpp.o build/src/ProbablyNoteIndian.cpp.o build/src/ProbablyNoteMN.cpp.o build/src/PWAlgorithmicExpander.cpp.o build/src/PWGridControlExpander.cpp.o build/src/PWTapBreakoutExpander.cpp.o build/src/QARGrooveExpander.cpp.o build/src/QARIrrationalityExpander.cpp.o build/src/QARProbabilityExpander.cpp.o build/src/QARWarpedSpaceExpander.cpp.o build/src/QARWellFormedRhythmExpander.cpp.o build/src/QuadAlgorithmicRhythm.cpp.o build/src/QuantussyCell.cpp.o build/src/RouletteLFO.cpp.o build/src/SeedsOfChange.cpp.o build/src/SeedsOfChangeCVExpander.cpp.o build/src/SeedsOfChangeGateExpander.cpp.o build/src/SeriouslySlowEG.cpp.o build/src/SeriouslySlowLFO.cpp.o build/src/StringTheory.cpp.o build/src/TheGardener.cpp.o build/src/TheOneRingModulator.cpp.o build/src/VoxInhumana.cpp.o build/src/VoxInhumanaExpander.cpp.o build/src/filters/biquad.cpp.o build/src/dsp-compressor/SimpleComp.cpp.o build/src/dsp-compressor/SimpleEnvelope.cpp.o build/src/dsp-compressor/SimpleGate.cpp.o build/src/dsp-compressor/SimpleLimit.cpp.o build/src/dsp-noise/noise.cpp.o -static-libstdc++ -shared -undefined dynamic_lookup -stdlib=libc++ -mmacosx-version-min=10.7
/usr/really-local/rack-plugin-toolchain/local/osxcross/bin/x86_64-apple-darwin19-ld: error while loading shared libraries: libicui18n.so.67: cannot open shared object file: No such file or directory
clang-10: error: unable to execute command: No such file or directory
clang-10: error: linker command failed due to signal (use -v to see invocation)
make: *** [/usr/really-local/rack-plugin-toolchain/Rack-SDK/compile.mk:59: plugin.dylib] Error 255
make: Leaving directory '/usr/really-local/Rack-Plugins/FrozenWasteland'
make: *** [Makefile:122: plugin-build-mac] Error 2
The build works OK for the Linux and WIndows target. It also compiles cleanly on the mac natively.
Does anyone have any ideas about how to do about fixing this? Does the tool chain installation need to be updated or refreshed as OS update come out? Debugging cross-compilation errors is a bit beyond my skill set!
I realize that, as it was discussed in the announcement thread:
but as I was able to get the tool chain to work and compile hundreds of modules (I’ve been using it exclusively for the past three months to keep my modules up to date) I figured it was actually supported-ish, although not officially.
But if you think that’s the issue, I’ll assume that it is! Strange that I didn’t have any issues on any of the other modules in my collection. Perhaps one of the modules in the Frozen Wasteland collection uses internationalization support in a way that none of the others do.
well, ymmv (as we say). Like I said, I couldn’t really repro outside my own complex code.
First of all, I strongly suggest you set up your own build toolchain environment so you can test the same build that the library is going to make. I set it up in a VM running Ubuntu, and only build the part that builds windows plugins. It’s not difficult at all to setup: GitHub - VCVRack/rack-plugin-toolchain.
Secondly, I don’t think I have a commit with those changes, I think they were on a deleted branch. But I certainly remember them.
I found that my code that catches exceptions crashed in this environment, and unfortunately one of my plugins would always throw and catch an “expected” exception in the first draw call, so it crashed the plugin browser.
I use stringstream all over the place to build up strings that have numbers in them, and this is where most of the crashes were.
Since I didn’t really know what the problem was, my solution was pretty brute force. I removed all the instances of these constructs. At least all the crashing ones that I found.
BTW, in case you’re curious, this was not the issue.
The issue was that in the host OS pacman had upgraded the icu package to version 68. The linked version was 67, so the dynamic linker complained.
A make toolchain-clean && make toolchain-all fixed it up.
Near as I can tell, 10.15 works fine for the cross compilation. As I mentioned, I’ve successfully compiled hundreds of modules. This was the only glitch, and it seems unrelated to SDK version.
The take-away is that if you’re running outside of docker, you need to make sure that the linking stays up-to-date. As the tool-chain lays outside of the package management system, you’ll need to do that yourself.
Interesting. That’s the exact reason why I created the Docker image. It decouples your host environment, which in most cases is subject to change, from your build environment, which never changes unless you want to. You still develop in your host environment, but you always get a reliable environment in the Docker image, which you only use to sanity check right before shipping it off to integration into the library or when issues (like yours) arise in the host environment.
I would definitely recommend the docker solution for people interested in the tool chain. It would be best for most use-cases, especially since Arch isn’t an appropriate distribution for the lots of folks that really aren’t interested in what it provides (ie., straightforward but manual configuration).
I like docker a lot, but I chose to use the host version because a) I happen to run Arch on my main laptop already, and b) I spend a lot of time exec-ed into docker containers for work, and sometimes it’s good to maintain work/play boundaries.
Just one note here: you will not be exec-ed in the Docker environment. The source code resides on the host system and is mounted in the Docker container and the compilation is executed. The result appears in the host system. If I don’t tell you, you wouldn’t even know that Docker is used.
going with docker all the time may be the less distasteful option. At least that way if the “official build” can’t handle some (valid) c++ constructs I’ll find out when I use them, rather than at the very end. I still think there is something wrong with the way the libraries are linked in the official build. writing my own version of std::stringstream seems like a heavyweight solution to having my modules crash the plugin browser.