Em ter., 3 de mai. de 2022 às 12:40, Roman Haefeli <[email protected]> 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
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
