We want to add soundfile support in our faust2supercollider tool, that creates foo.sc and foo.scx files by compiling a foo.dsp Faust program.
Our soundfile handling code uses libsndfile (so we usually have to link the binary to libsndfile code), but it seems that the libsndfile is already linked in the server code, is that correct? In this case should we avoid to link to libsndfile in the generated foo.scx file ? And how to do that?
Scsynth dynamically links to libsndfile, so the symbols should be available. However, you cannot really make any assumptions about which version of libsndfile that would be. I think that libsndfile versions stay ABI compatible, so you may just query the version at runtime, in case you depend on newer functionality.
When building your UGen on On Linux/macOS, you can either link against libsndfile – or leave the symbols undefined (on macOS you would need to pass -undefined dynamic_lookup, I think). On Windows, you must link against the import library (lib)sndfile.lib (strictly speaking, with MinGW you could also directly link against libsndfile.dll).
The other solution is to use your own version of libsndfile, build it as a static library and then link statically. This way your UGen does not have a runtime dependency on libsndfile.
Thanks, then statically linking is probably the safer path.
I finally tried the -undefined dynamic_lookup way, it is easier since we compile UB (arm/Intel), UGens.
But now the compiled UGen works when SC is started under Rosetta (so properly use the libsndfile code part of Scsynth) but crashed at at load time on arm, with the following trace: Supercollider crash · GitHub
Any idea ?
Well, something is wrong on my system for whatever reason. Just removing and copying again the compiled UGens now works 
I see it’s a code signing / security access failure. Copying files via finder removes OS quarantine flags, via CLI does not. Unlikely that is the reason it worked, but within the realm of possibility.
I just want to add that this shouldn’t be an issue. At least with CMake universal binaries are handled pretty much transparently. I have several projects with static libraries that I build from source; I just run cmake with -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" and that’s it!
But if the dynamic linking solution seems to work fine, just keep it 