<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Could you PLEASE stop sending me fucking emails? I am not using ardour for 3 Years and you keep clogging up my inbox!</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Ardour-Users <ardour-users-bounces@lists.ardour.org> im Auftrag von ycollette.nospam@free.fr <ycollette.nospam@free.fr><br>
<b>Gesendet:</b> Donnerstag, 21. Februar 2019 14:21<br>
<b>An:</b> Robin Gareus<br>
<b>Cc:</b> ardour-users@lists.ardour.org<br>
<b>Betreff:</b> Re: [Ardour-Users] ambix LV2 vs ardour?</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hello,<br>
<br>
Instead of just ldd, can you try "ldd -r" sometime ldd doesn't show every problem and forcing a reloc will show the problem.<br>
<br>
Best regards,<br>
<br>
YC<br>
<br>
----- Mail original -----<br>
De: "Robin Gareus" <robin@gareus.org><br>
À: ardour-users@lists.ardour.org<br>
Envoyé: Jeudi 21 Février 2019 14:11:23<br>
Objet: Re: [Ardour-Users] ambix LV2 vs ardour?<br>
<br>
On 2/21/19 8:06 AM, Fernando Lopez-Lezcano wrote<br>
> # ldd /usr/lib64/lv2/ambix_converter_o1.lv2/ambix_converter_o1.so<br>
> linux-vdso.so.1 (0x00007ffff87fa000)<br>
> libzita-convolver.so.3 => /lib64/libzita-convolver.so.3<br>
> (0x00007f8f1047f000)<br>
> libX11.so.6 => /lib64/libX11.so.6 (0x00007f8f1033a000)<br>
> libXext.so.6 => /lib64/libXext.so.6 (0x00007f8f10325000)<br>
> libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007f8f10320000)<br>
> libasound.so.2 => /lib64/libasound.so.2 (0x00007f8f10218000)<br>
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f8f10212000)<br>
> libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f8f10152000)<br>
> librt.so.1 => /lib64/librt.so.1 (0x00007f8f10148000)<br>
> libglut.so.3 => /lib64/libglut.so.3 (0x00007f8f10090000)<br>
> libXmu.so.6 => /lib64/libXmu.so.6 (0x00007f8f10073000)<br>
> libXi.so.6 => /lib64/libXi.so.6 (0x00007f8f10061000)<br>
> libGL.so.1 => /lib64/libGL.so.1 (0x00007f8f0ffcd000)<br>
> libGLU.so.1 => /lib64/libGLU.so.1 (0x00007f8f0ff59000)<br>
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8f0ff37000)<br>
> libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8f0fd9f000)<br>
> libm.so.6 => /lib64/libm.so.6 (0x00007f8f0fc1b000)<br>
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8f0fc00000)<br>
> libc.so.6 => /lib64/libc.so.6 (0x00007f8f0fa3a000)<br>
> libfftw3f.so.3 => /lib64/libfftw3f.so.3 (0x00007f8f0f827000)<br>
> libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f8f0f7fc000)<br>
> /lib64/ld-linux-x86-64.so.2 (0x00007f8f10991000)<br>
> libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f8f0f7e9000)<br>
> libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f8f0f7b3000)<br>
> libz.so.1 => /lib64/libz.so.1 (0x00007f8f0f799000)<br>
> libICE.so.6 => /lib64/libICE.so.6 (0x00007f8f0f779000)<br>
> libXxf86vm.so.1 => /lib64/libXxf86vm.so.1 (0x00007f8f0f772000)<br>
> libXt.so.6 => /lib64/libXt.so.6 (0x00007f8f0f707000)<br>
> libGLX.so.0 => /lib64/libGLX.so.0 (0x00007f8f0f6d3000)<br>
> libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f8f0f616000)<br>
> libXau.so.6 => /lib64/libXau.so.6 (0x00007f8f0f60f000)<br>
> libSM.so.6 => /lib64/libSM.so.6 (0x00007f8f0f604000)<br>
> libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f8f0f5fb000)<br>
> <br>
> (so lots of things...)<br>
<br>
Ok. I'm pretty sure that this is the issue. In particular if qtractor<br>
loads it.<br>
<br>
The solution is to statically link the plugin and hide its symbols<br>
except for the entry point. Plugins should not depend on any external libs.<br>
<br>
The short explanation is that Plugins cannot know about each other, and<br>
hence must be self-contained.<br>
<br>
---<br>
Say you write a plugin that needs ffmpeg and uses the newer<br>
libswresample2 interface, and another author writes a plugin that uses<br>
the older libswresample1 API. Now you dynamically link both.<br>
<br>
Distros may even package both library versions, and you can compile and<br>
link, but if you load both at the same time in the same host, there is a<br>
conflict.<br>
<br>
[ from<br>
<a href="http://lists.ardour.org/pipermail/ardour-users-ardour.org/2018-November/028948.html">http://lists.ardour.org/pipermail/ardour-users-ardour.org/2018-November/028948.html</a><br>
]<br>
---<br>
<br>
In your case likely libfftw3f or zita-convolver that conflicts with<br>
Ardour's use of it, but it could be any lib, including libstdc++ (except<br>
X11).<br>
<br>
Cheers!<br>
robin<br>
<br>
<br>
_______________________________________________<br>
Ardour-Users mailing list<br>
ardour-users@lists.ardour.org<br>
To unsubscribe or change your mailing preferences please visit:<br>
<a href="http://lists.ardour.org/listinfo.cgi/ardour-users-ardour.org">http://lists.ardour.org/listinfo.cgi/ardour-users-ardour.org</a><br>
_______________________________________________<br>
Ardour-Users mailing list<br>
ardour-users@lists.ardour.org<br>
To unsubscribe or change your mailing preferences please visit:<br>
<a href="http://lists.ardour.org/listinfo.cgi/ardour-users-ardour.org">http://lists.ardour.org/listinfo.cgi/ardour-users-ardour.org</a><br>
</div>
</span></font></div>
</body>
</html>