Em ter., 3 de mai. de 2022 às 12:40, Roman Haefeli reduzent@gmail.com escreveu:
I guess I'll have to join the fluidsynth list and ask for that. Maybe they can also help me with the other issue where even a x86_64 fluidsynth installed for monterey via homebrew doesn't work in earlier versions of macOS.
I'm not sure this would be the right place to ask. What they provide, works. The issues that the homebrew team is trying to address with their way to do things are probably not related to the source code, but more related to how things work on new Macs.
but they provide pre built stuff at https://github.com/FluidSynth/fluidsynth/releases/tag/v2.2.7
and I already did ask for universal builds and there was some interest where someone said "I'm open to publish those universal binaries with the fluidsynth releases. I could sign them as well" see https://lists.nongnu.org/archive/html/fluid-dev/2022-05/msg00002.html
So, now I need to find a way to have in my system an universal fluidsynth~ dynamic lib.
This seems like an unnecessarily hard quest, since homebrew doesn't ship fat.
It doesn't. Fluidsynth people also told me about macPorts and how it could maybe provide universal binaries, but I couldn't figure it out.
Wouldn't it be more feasible to build it separately for separate archs? Then you wouldn't have to compile fluidsynth and all its dependencies just to get fat libraries.
I'm also open to that, of course if it just gets too hard.
Then there is the issue with codesigning that I don't see completely through yet.
tell me about it, me neither...
It seems on arm64/Monterey, I automatically get signed binaries (adhoc signed, equivalent to 'codesign -s -') when building externals. However, when I apply the localdep script to to such an external file, it cannot be loaded afterwards. Pd immediately quits as soon as it loads the external. An already signed binary cannot/shouldnot be modified afterwards.
I figured I had to remove the signature and sign all libraries in one go, the external itself, but also all dylib files that it depends on.
codesign --remove-signature fluidsynth~.pd_darwin *.dylib codesign -s - fluidsynth~.pd_darwn *.dylib
I'm not sure how/if that would work at all, if you have fat builds.
well, maybe we can get these from the fluidsynth release, but I hear you, I wouldn't have a clue, but I also don't one way or another.
It seems it would be ideal to me to have a single fat binary with the externals and the libs all together!
Shipping it together seems practical, I agree. I don't think it matters much whether it is separate files or fat bundles.
I also mean this for windows and linux, though I have to say I'm quite ignorant on Linux and don't know about the challenges and also I don't know if people succeeded in providing binaries with included dynamic libs for linux, please tell me if there are any issues.
I often find things are a bit easier on Linux, but that's what I got accustomed to. In the case of the fluidsynth~ external, using the dynamic libraries from my distro (Ubuntu 22.04) doesn't seem practical, as libfluidsynth.so.3 links against virtually half the system. After executing the localdep script, I end up with 53 *.so files. Most of them aren't actually used when libfluidsynth is used for the pd external. Creating a more stripped down build of libfluidsynth probably would make sense here.
Cool, but how? :)
Thanks
by the way, maybe you (or anyone else) may want to join a discussion about these things on my reporitory https://github.com/porres/pd-else/issues/1243