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

Roman Haefeli reduzent at gmail.com
Tue May 3 17:39:27 CEST 2022


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20220503/00a14fe7/attachment.sig>


More information about the Pd-dev mailing list