"libicui18n.so.67: cannot open shared object file" when building FrozenWasteland

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[1]: *** [/usr/really-local/rack-plugin-toolchain/Rack-SDK/compile.mk:59: plugin.dylib] Error 255
make[1]: 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!

Which macOS SDK version did you use to build the toolchain?

Are you building the toolchain locally or in a Docker image?

Looking in the osxcross directory, it looks like MacOSX10.15.sdk. And I’m running natively on on up-to-date arch system (not via docker containers – spend too much time in docker for work :wink: ).

Only the 10.13 SDK is supported, see the README.md.

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.

When they switched to the new build system four of my plugins crashed on windows. Had to get rid of some crashing constructs.

Could you post some examples? Or link to the GitHub commit(s)?

I’m worried that I might doing the same thing, and I bet I’m not the only one…

1 Like

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.

  1. 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.

  2. 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.

1 Like

Thanks - very helpful. In my case I use Azure DevOps to build all my production releases, but I was worried that the same problem might affect that.

It looks like it doesn’t - I use both expected exceptions and stringstream for numbers, but both happen on startup and the modules are working fine.

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.

1 Like

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.

1 Like

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.

Two very admittedly idiosyncratic reasons…

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.

1 Like

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.