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

IOhannes m zmölnig zmoelnig at iem.at
Fri Jan 8 12:29:04 CET 2021

On 1/8/21 10:16 AM, Roman Haefeli wrote:
> I took the liberty to move this over to pd-dev
> On Fri, 2021-01-08 at 03:48 -0300, Alexandre Torres Porres wrote:
>> Em qui., 7 de jan. de 2021 às 20:07, Roman Haefeli <
>> reduzent at gmail.com> escreveu:
>>> On Thu, 2021-01-07 at 00:14 -0300, Alexandre Torres Porres wrote:
>>>> we still need to sort this for linux,
>>> Since you seem you got it sorted (and I figured out how to compile
>>> fluidsynth with no additional deps)
>> how did that go?
> I just updated pd-fluidsynth repo to get your and Lucas' most recent
> changes. I didn't have to modify anything for the build process to
> work.
> ~~~sh
> cd pd-fluidsynth
> make pkglibdir=$HOME/pd-src/workspace/Linux-arm7-32
> make pkglibdir=$HOME/pd-src/workspace/Linux-arm7-32 install
> cd $HOME/pd-src/workspace/Linux-arm7-32/fluid~
> sh linuxdep32.sh
> rm linuxdep32
> ~~~
> However, the crucial part is that the included libfluidsynth.so should
> not be "tainted" with support for all kinds of things. This means, you
> can't take the one shipped by the distro.
>>   Can you describe the steps and put it in our readme (with a PR)?
> You mean what steps were necessary to compile fluidsynth? I didn't have
> to do anything suprising or special. I just had  to figure out how to
> disable everything by reading the docs about building. This is what I
> came up with (I hope it is correct and complete):
> ~~~sh
> git clone https://github.com/FluidSynth/fluidsynth/
> cd fluidsynth
> mkdir build
> cd build
> cmake -Denable-libsndfile=off -Denable-jack=off -Denable-alsa=off -Denable-oss=off -Denable-pulseaudio=off -Denable-ladspa=off -Denable-aufile=off  -Denable-network=off  -Denable-ipv6=off -Denable-getopt=off -Denable-sdl2=off ..
> make
> sudo make install
> ~~~
> After this, I compiled fluid~ with steps from above.
> tot
> Regarding the makefile of pd-fluidsynth, I don't understand the purpose
> of this section:
> ---
> define forLinux
> ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686)
>          datafiles += scripts/linuxdep32.sh
>          else
>          datafiles += scripts/linuxdep64.sh
> endif
> endef

> ---
> Depending on which arch is detected, it'll add one or the other script
> in the build result. 

that seems all wrong:
why would you want to install one of these script based on the build 

apart from that: the linuxdep*.sh scripts seem to be quite bogus.
you  really should evaluate the dependencies of the fluid~.pd_linux file 
to see where these libraries are to be found.
rather than assuming they are installed in /usr/local/lib/ resp 
/usr/local/lib64/ (the latter directory is only used on fedora based 
systems), use `ldd`.
this will allow you to get libraries from /usr/lib/, 
/usr/local/lib/i386-linux-gnu/ or wherever your dynamic linker would 
take the libfluidsynth-library from.

> I think what this is meant to do is to _execute_
> the arch specific script, so that libraries get included. I'm not yet

if you follow my advise, there is no need to use *arch* specific scripts 
(you need different scripts for different dynamic linking mechanisms, so 
that's why my original scripts are for windows (dll), macOS (dylib),...; 
but there's no need for the scripts to be aware of the CPU-type - as 
long as you use the system provided tools to resolved dependencies.

> familiar with makefiles to tell you just right away how this is done,
> but according to the snippet, I'd suppose something like this:
> ---
> define forLinux
> ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686)
>          $(shell /bin/sh scripts/linuxdep32.sh)
>          else
>          $(shell /bin/sh scripts/linuxdep32.sh)
> endif

now there are a couple of things with this:
- first you don't need the complicated architecture evaluation, if you 
do the same thing regardless of the result
- then, there is no proper definition *when* the script is run. 
basically it is run whenever you execute `make`, even if you run e.g. 
`make clean`.
- finally, the collection of dependencies should *never* be part of the 
ordinary build process (`make`, `make all`, `make install`, `make 
uninstall`, `make clean`,...).
if you think you *must* include the code in the Makefile, then it should 
be a separate target, that is only called explicitely, e.g. via
`make installdependencies`.

most likely, this should be a post-install operation (respecting DESTDIR 
and similar variables).

for the sake of simplicity, i would do something like:

install+dependencies: install
     ./scripts/dependendencies "${installpath}" "${extension}"

in in ./scripts/dependencies search all files with the 
${extension}-suffix in "${installpath}" and run an OS-dependent script 
on them.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20210108/4016253b/attachment.sig>

More information about the Pd-dev mailing list