[Ardour-Users] ambix LV2 vs ardour?

ycollette.nospam at free.fr ycollette.nospam at free.fr
Thu Feb 21 05:21:16 PST 2019


Instead of just ldd, can you try "ldd -r" sometime ldd doesn't show every problem and forcing a reloc will show the problem.

Best regards,


----- Mail original -----
De: "Robin Gareus" <robin at gareus.org>
À: ardour-users at lists.ardour.org
Envoyé: Jeudi 21 Février 2019 14:11:23
Objet: Re: [Ardour-Users] ambix LV2 vs ardour?

On 2/21/19 8:06 AM, Fernando Lopez-Lezcano wrote
> # ldd /usr/lib64/lv2/ambix_converter_o1.lv2/ambix_converter_o1.so
>     linux-vdso.so.1 (0x00007ffff87fa000)
>     libzita-convolver.so.3 => /lib64/libzita-convolver.so.3
> (0x00007f8f1047f000)
>     libX11.so.6 => /lib64/libX11.so.6 (0x00007f8f1033a000)
>     libXext.so.6 => /lib64/libXext.so.6 (0x00007f8f10325000)
>     libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007f8f10320000)
>     libasound.so.2 => /lib64/libasound.so.2 (0x00007f8f10218000)
>     libdl.so.2 => /lib64/libdl.so.2 (0x00007f8f10212000)
>     libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f8f10152000)
>     librt.so.1 => /lib64/librt.so.1 (0x00007f8f10148000)
>     libglut.so.3 => /lib64/libglut.so.3 (0x00007f8f10090000)
>     libXmu.so.6 => /lib64/libXmu.so.6 (0x00007f8f10073000)
>     libXi.so.6 => /lib64/libXi.so.6 (0x00007f8f10061000)
>     libGL.so.1 => /lib64/libGL.so.1 (0x00007f8f0ffcd000)
>     libGLU.so.1 => /lib64/libGLU.so.1 (0x00007f8f0ff59000)
>     libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8f0ff37000)
>     libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8f0fd9f000)
>     libm.so.6 => /lib64/libm.so.6 (0x00007f8f0fc1b000)
>     libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8f0fc00000)
>     libc.so.6 => /lib64/libc.so.6 (0x00007f8f0fa3a000)
>     libfftw3f.so.3 => /lib64/libfftw3f.so.3 (0x00007f8f0f827000)
>     libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f8f0f7fc000)
>     /lib64/ld-linux-x86-64.so.2 (0x00007f8f10991000)
>     libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f8f0f7e9000)
>     libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f8f0f7b3000)
>     libz.so.1 => /lib64/libz.so.1 (0x00007f8f0f799000)
>     libICE.so.6 => /lib64/libICE.so.6 (0x00007f8f0f779000)
>     libXxf86vm.so.1 => /lib64/libXxf86vm.so.1 (0x00007f8f0f772000)
>     libXt.so.6 => /lib64/libXt.so.6 (0x00007f8f0f707000)
>     libGLX.so.0 => /lib64/libGLX.so.0 (0x00007f8f0f6d3000)
>     libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f8f0f616000)
>     libXau.so.6 => /lib64/libXau.so.6 (0x00007f8f0f60f000)
>     libSM.so.6 => /lib64/libSM.so.6 (0x00007f8f0f604000)
>     libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f8f0f5fb000)
> (so lots of things...)

Ok. I'm pretty sure that this is the issue. In particular if qtractor
loads it.

The solution is to statically link the plugin and hide its symbols
except for the entry point. Plugins should not depend on any external libs.

The short explanation is that Plugins cannot know about each other, and
hence must be self-contained.

Say you write a plugin that needs ffmpeg and uses the newer
libswresample2 interface, and another author writes a plugin that uses
the older libswresample1 API. Now you dynamically link both.

Distros may even package both library versions, and you can compile and
link, but if you load both at the same time in the same host, there is a

[ from

In your case likely libfftw3f or zita-convolver that conflicts with
Ardour's use of it, but it could be any lib, including libstdc++ (except


Ardour-Users mailing list
ardour-users at lists.ardour.org
To unsubscribe  or change your mailing preferences please visit:

More information about the Ardour-Users mailing list