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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
