[PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

On Fri, 2021-01-08 at 23:13 +0100, Roman Haefeli wrote:
> On Fri, 2021-01-08 at 12:47 +0100, Roman Haefeli wrote:
> > On Fri, 2021-01-08 at 12:29 +0100, IOhannes m zmölnig wrote:
> > Hopefully, we'll be able to create fluid~ that also supports sf3
> > files.
> 
> I got fluidsynth compiled with libsndfile support. When loading an
> SF3
> soundfont, there is no error, but I can't get any sound out of
> [fluid~]. So I am not sure whether I'm doing something wrong or SF3
> support is broken still (more likely).

As Alexndre already pointed out, my testing was bogus and playing SF3
works fine when choosing a non-silent program (and using a SF3-file
that actually works). 
> 
> Anyway, it turns out to be an adventure with many more stumbling
> blocks
> ahead, for me at least . When I build fluidsynth, it links to the
> system-wide installed libsndfile. So, I'm not sure how to go about
> about making everything local. Is this when static linking is used? 

Ok, I got around re-compiling everything and learning the
idiosyncracies of unfamilier build sytems by patching the binaries.

I sitll compiled fluidsynth so that it has the exact support I want,
not more, not less. Basically, I only want libsndfile support (for
loading SF3-files) and everything else disabled. I copied all
dependencies to the folder of fluid~·pd_linux and used the patchelf
command line utility to set RUNPATH to $ORIGIN. 

The result can be found here:
https://netpd.org/~roman/tmp/fluid~/fluid~%5bvtest-2~sf3-support%5d(Linux-amd64-32).zip

Read more about $ORIGIN and RUNPATH:
https://nehckl0.medium.com/creating-relocatable-linux-executables-by-setting-rpath-with-origin-45de573a2e98

That is a process I think is less work and for me easier to grab than
re-compiling the whole dependency chain. I might be able to turn this
into a linuxdep.sh script. Since I'm still learning a lot, I wonder if
this is the way to go or if it's considered hacky to fix things after
the fact? I'd like to hear some expert opinion.

What I'm still wondering is how to distinguish dependencies required to
be included into a Deken package from those that we assume are already
installed on the system. Is there a proper way for making that
distinction? Without that distintion, I'll probably have to hard-code
all those libs that shouldn't be included in the final package.

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/20210110/dacdf2b7/attachment.sig>