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

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.