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
I’ve just enabled that in Ardour 9.0-pre0-1187 (tomorrow’s nightly build).
For a software where it is common practice to load random 3rd party binaries, and run them in realtime context, there is no such thing as security concern on that level. You don’t need an executable stack for an exploit.
1 Like
Thanks x42
I will be moving on to Ardour 9 and shall try this out then.
Thankyou very much I will give it a try and report back
Thanks @songo I downloaded the execstack you linked but it wouildnt install on trixie because of dependencies.
x42 says Ardour is fixed for this from now so I will try that route.
That’s strange. Just installed it on Trixie and it works:
root@trixie-testing:~# dpkg -l execstack
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-===================-============-============================================
ii execstack 0.0.20131005-1.1+b1 amd64 ELF GNU_STACK program header editing utility
root@trixie-testing:~# cat /etc/debian_version
trixie/sid
What is dpkg telling you during installation attempt?
Yes, but Ardour 9 is still in development.
Here
Im not going to try to fix the unmet dependencies, I messed up my system too many times doing that.
Ardour being able to use these and other new plugins without my intervention is better.
Many thanks for your interest though, much appreciated. That’s one thing that makes using Ardour so good, people want to help with your difficulties.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.