backends: Add missing dependencies

[orbea]

When building the backends with slibtool they will fail with undefined references to libmatemixer.la. This is because they use -no-undefined which slibtool explicitly supports while GNU libtool will silently ignore it.

Gentoo Bug: https://bugs.gentoo.org/785232

[thesamesam]

Heh, this might even fix #25.

[orbea]

Seems very plausible.

[vkareh]

I cannot reproduce this issue (Fedora 35), but this builds just fine without any issues.

[orbea]

I cannot reproduce this issue (Fedora 35), but this builds just fine without any issues.

It should be possible to reproduce this with GNU libtool by changing the instances of -no-undefined in the backend Makefile.am files to -Wl,--no-undefined so that the flag is explicitly passed to the linker instead of being consumed silently by libtool. Of course not every linker supports this argument.

Also slibtool is trivial to compile and test locally.

https://dev.midipix.org/cross/slibtool

./configure
make

And for libmatemixer it can tested by making sure the slibtool wrapper scripts are in the $PATH and exporting the MAKE variable.

export MAKE='make LIBTOOL=rdlibtool'

Where rlibtool is the standard slibtool wrapper that works with most build systems and rdlibtool adds extra debugging output.

[rbuj]

ldd shows libmatemixer.so.0 afer this PR. LGTM, even if there aren't symbol resolution errors at runtime, i.e. LD_DEBUG=all mate-volume-control. However, it makes no sense to keep -no-undefined, IMHO it should be replaced with -Wl,--no-undefined.

Before

$ ldd /usr/lib64/libmatemixer/libmatemixer-alsa.so
linux-vdso.so.1 (0x00007fffe25bc000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007fbbf80a7000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007fbbf80a0000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007fbbf8073000)
libasound.so.2 => /lib64/libasound.so.2 (0x00007fbbf7f63000)
libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007fbbf7f5e000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007fbbf7e22000)
libc.so.6 => /lib64/libc.so.6 (0x00007fbbf7c1e000)
libffi.so.8 => /lib64/libffi.so.8 (0x00007fbbf7c12000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbbf7bf2000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbbf813a000)
libm.so.6 => /lib64/libm.so.6 (0x00007fbbf7b14000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fbbf7a9a000)

After

$ ldd /usr/lib64/libmatemixer/libmatemixer-alsa.so
linux-vdso.so.1 (0x00007fff09b70000)
libmatemixer.so.0 => /lib64/libmatemixer.so.0 (0x00007f8c4822c000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f8c481cd000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f8c481c6000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f8c48199000)
libasound.so.2 => /lib64/libasound.so.2 (0x00007f8c48089000)
libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007f8c48084000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f8c47f46000)
libc.so.6 => /lib64/libc.so.6 (0x00007f8c47d44000)
libffi.so.8 => /lib64/libffi.so.8 (0x00007f8c47d38000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8c47d18000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8c48280000)
libm.so.6 => /lib64/libm.so.6 (0x00007f8c47c3a000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f8c47bc0000)

[rbuj]

LGTM

[orbea]

Thanks for the merge!

IMHO it should be replaced with -Wl,--no-undefined.

That should be fine on linux at least, I'm not sure if mate is concerned about other platforms?

[rbuj]

Ok, thanks for the tip. Yes, it can lead to probability issues.

[lukefromdc]

Do we have anyone here who can test this on one of the BSD's?