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-am...
Read more about $ORIGIN and RUNPATH: https://nehckl0.medium.com/creating-relocatable-linux-executables-by-setting...
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