Hello!
I found that TLS 1295 LEA (.so, linux version, TLS 1295 LEA - Plugin Nation) doesnt work in Ardour 8.12 on LiveCD Ubuntu Studio 25.04 (and Fedora Jam 42). In Plugin Manager plugin marked as Error. At the same time in Reaper everything is fine, plugin works.
In Ardour 8.4 on USt 24.04 everything is fine too.
why can it be?
What is the error message shown there?
Could be anythingā¦
One explanation would be that the plugin is dynamically linked, depends on external resources, and those conflict with Ardourās or other plugins.
ldd /path/to/the/plugin.so
would provide some clue if that is the case.
Iām also having the problem. Iām not at home right now. When I get there, Iāll test again, post any information about the bug, and run the command @x42 suggested.
I use it in ubuntu 24.10 and ardour 8.6
it works for me
1 Like
It works for me on debian 12 and ardour 8.12
[Info]: Scanning: /home/feddie/.vst/TLs-1295-LEA_64bit.so
[ERROR]: Could not load VST2 plugin ā/home/feddie/.vst/TLs-1295-LEA_64bit.soā: /home/feddie/.vst/TLs-1295-LEA_64bit.so: cannot enable executable stack as shared object requires: Invalid argument
[WARNING]: Cannot open VST2 module ā/home/feddie/.vst/TLs-1295-LEA_64bit.soā
Scan Failed.
ldd TLs-1295-LEA_64bit.so
linux-vdso.so.1 (0x00007fdc17ea3000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007fdc16aba000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fdc16800000)
libm.so.6 => /lib64/libm.so.6 (0x00007fdc17d99000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fdc16a8e000)
libc.so.6 => /lib64/libc.so.6 (0x00007fdc1660e000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007fdc165e4000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdc17ea5000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007fdc17d91000)
And what does this mean?
for reference, this is on Fedora Jam 42
Are u sure that the file is there?.. sounds like the .so file is removed or u havent permissions to read it.
āthereā where?))) In /home/name/.vst-folder. Ardour sees it, but āErrorāā¦
-rwxrwxr-x for current user
Nah. It sounds more like some selinux/apparmor policy preventing running the binary because the .so library has executable stack bit set. Maybe clearing it using the execstack command (execstack -c /home/feddie/.vst/TLs-1295-LEA_64bit.so) will help. Not sure if it is available in 24.10 though.
2 Likes
I dont know what is it, but it It worked! You are genius!!! Thank You! (Fedora Jam 42)
1 Like
LOL, no Iām not, I assure you, but glad it worked. 
Although the proper solution would be reaching the developer and ask him to rebuild the plugin. Maybe Iāll try to do it because I like this compressor a lot.
Great that you found a solution!
Then how did this work in Reaper?
Since Reaper is installed as third party, a security policy preventing to run the plugin wasnāt in place in this case. Just guessing. Donāt have 24.10 handy to check what really is going on there.
it works without any problems
It will be a great contribution to the production of music on Linux.
Good luck!
Hello,
I have the TLS-1295-LEA plugin with Ardour 8.12.
It works very well.
Iām with a debian 12 KDE.
I have had similar problems since switching to debian trixie gnome (which I had to do to get stable graphics with nvidia), which i posted about
All these good plugins worked for me in Ardour 8.12 on debian stable (on a different machine), but now do not:
All TBT TL comps/limiters
Neuralnote
Decent sampler
Dragonfly reverbs
Recent airwindows
Songo found a solution with execstack, but execstack is not available for trixie.
Will Ardour be fixed to solve this problem or is there any other simple solution?
Many thanks
I took a closer look at this issue and it seems I was wrong suspecting security policies. It is actually a glibc feature added in versions landed on newer Debian based distros:
dlopen and dlmopen no longer make the stack executable if a shared
library requires it, either implicitly because of a missing GNU_STACK
ELF header (and default ABI permission having the executable bit set)
or explicitly because of the executable bit in GNU_STACK, and the
stack is not already executable. Instead, loading such objects will
fail.
https://lists.gnu.org/archive/html/info-gnu/2025-01/msg00014.html
If I understand above correctly it will fail if a linked library has the executable bit set and the program calling it has the bit cleared. And it is the case of Ardour. It would probably also explain why it works in Reaper. I suspect provided binaries are built with the executable stack bit set out of the box.
As for the best solution it hasnāt changed. I think the best way to deal with the problem is to persuade plugin developers to rebuild binaries. Pretty sure the executable stack is unnecessary in most if not all plugins.
And maybe, just maybe, it would be feasible to provide the official Ardour binaries with executable stack enabled, because the problem will only get worse over time as more people upgrade their distros. But there are probably security concernsā¦
Meanwhile, the execstack workaround still should work. Old packages are available in snapshots and can be installed in recent Debian bases distros including Trixie:
https://snapshot.debian.org/package/prelink/0.0.20131005-1.1/#execstack_0.0.20131005-1.1:2b:b1
Just checked above. Yes, this is exactly the case:
songo@stalker:~$ execstack -q ~/opt/reaper_linux_x86_64/REAPER/reaper
X /home/songo/opt/reaper_linux_x86_64/REAPER/reaper
songo@stalker:~$ execstack -q /opt/Ardour-8.12.0/bin/ardour-8.12.0
- /opt/Ardour-8.12.0/bin/ardour-8.12.0