On Sun, 2022-05-01 at 12:56 -0300, Alexandre Torres Porres wrote:
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.
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.
Then there is the issue with codesigning that I don't see completely through yet. 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.
You still ship both archs together by using different extension for the external (.d_arm64 and .d_amd64) and but the dependent libraries into their arch-specific directories (e.g. 'arm64' and 'amd64'). It's just a suggestion, I haven't tried it myself yet.
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.
Maybe I need to have dependencies for both architectures and make them fat manually? I wonder if that's it and if it's easy. Moreover, I guess I'd need help with people with M1 macs around... (anyone?).
One last problem and question is that newer versions of macOS are really rejecting loading the external because they think the dynamic lib has malware or something. How can I make it seem notarized?
I don't know the details, but once you start with signed code, it seems obvious that the whole chain needs to follow, otherwise signing wouldn't make much sense, if you still could easily inject unsigned code.
And I know we may have discussed this earlier but I can't find it. How come isn't it just easier to create an external with an included static lib instead of downloading an external with almost a dozen dynamic libs?
I finally somewhat figured out how to to stuff with dynamic libraries. Don't know what new culprits static libraries would bring. Maybe someone more knowledgeable could answer that?
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.
Roman