[PD-dev] building fluidsynth~ (was: building fluid~ on Linux)

[Alexandre Torres Porres]

Em ter., 3 de mai. de 2022 às 12:40, Roman Haefeli <reduzent at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20220503/095b6f3e/attachment.htm>