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