View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008417 | ardour | bugs | public | 2020-09-21 15:45 | 2020-09-21 20:12 |
| Reporter | mvf | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | x86_64, glibc | OS | Linux | OS Version | any |
| Product Version | 6.3 | ||||
| Summary | 0008417: Plugins can't start programs due to LD_LIBRARY_PATH | ||||
| Description | In official Ardour builds, plugins can't start some OS-supplied programs because Ardour puts its own, potentially incompatible libraries on the library search path (LD_LIBRARY_PATH). | ||||
| Steps To Reproduce | Note: These are just to illustrate the user experience. The root cause is observable in any build without loading plugins. 1. Start an official Ardour build 2. Load the Surge LV2 plugin (https://github.com/surge-synthesizer/surge) 3. In the plugin editor, click the "Menu" button in the far bottom right 4. Select "Surge Manual" from the menu Observed: Nothing happens. Expected: Browser opens Surge Manual. | ||||
| Additional Information | The 'ardour6' launch script sets LD_LIBRARY_PATH, putting the Ardour library directory first. OS programs are not always compatible with libraries in this path. In the repro case, Surge starts xdg-open, which on my machine tries to exec() firefox. This fails because the libatk-bridge-2.0.so.0 shipped with Ardour is missing a symbol: $ LD_LIBRARY_PATH=/opt/Ardour-6.3.0/lib xdg-open https://ix.de XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so: /usr/lib/libatk-bridge-2.0.so.0: undefined symbol: atk_component_scroll_to_point Couldn't load XPCOM. The same root cause, albeit with a different library, keeps plugins from starting zenity [1][2]. In [3], x42 suggested clearing LD_LIBRARY_PATH in the child process. This is fine for a local workaround, but not something plugins can ship. Suggested fix: LD_LIBRARY_PATH should be left alone. Instead, the library search path should be linked into all Ardour-shipped ELFs. Relative paths are supported via the $ORIGIN variable. Plugin-less proof of concept on the official Ardour demo: Observe that it doesn't work with empty LD_LIBRARY_PATH: $ ldd /opt/Ardour-6.3.0/bin/ardour-6.3.0 linux-vdso.so.1 (0x00007ffd38fde000) libardourcp.so => not found ... Remove LD_LIBRARY_PATH handling from launcher script: $ sudo sed -i '/LD_LIBRARY_PATH/d' /opt/Ardour-6.3.0/bin/ardour6 Patch RPATH into binaries: $ sudo patchelf --set-rpath '$ORIGIN/../lib' /opt/Ardour-6.3.0/bin/ardour-6.3.0 $ sudo patchelf --set-rpath '$ORIGIN/..' /opt/Ardour-6.3.0/lib/backends/*.so $ sudo patchelf --set-rpath '$ORIGIN' /opt/Ardour-6.3.0/lib/*.so* Verify linker picks up the path: $ ldd /opt/Ardour-6.3.0/bin/ardour-6.3.0 linux-vdso.so.1 (0x00007fff77b11000) libardourcp.so => /opt/Ardour-6.3.0/bin/../lib/libardourcp.so (0x00007fc6c73e1000) ... With Ardour running, observe that LD_LIBRARY_PATH is now unset, i.e. the following produces no output: $ grep LD_LIBRARY_PATH= /proc/$(pidof ardour-6.3.0)/environ Links: [1] https://github.com/sfztools/sfizz/issues/416 [2] https://github.com/surge-synthesizer/surge/issues/2455 [3] https://github.com/sfztools/sfizz/issues/416#issuecomment-690908174 | ||||
| Tags | No tags attached. | ||||
|
|
This is correct and a won't fix. As I've commented on both github issues in the past, it's hard to make to make forking realtime-safe. Furthermore plugins should be self-contained and not rely on external resources. |
|
|
> plugins should be self-contained and not rely on external resources. Oh yes, they should _definitely_ do better than using zenity. But things like opening a website in the browser can still occasionally necessitate starting programs. > it's hard to make forking realtime-safe There's not much the host can do if a plugin is poorly written and forks all the time. But the fork/exec doesn't even have to be in the plugin itself. Even when using something like GTK directly, LD_LIBRARY_PATH can still hurt the user experience. Example: Right-click -> "Open in Editor" from a "File Open" dialog. RPATH/$ORIGIN is intended precisely for this use case. It should be painless to deploy and would really make life easier for everyone, not least for Ardour subscribers. Ultimately _they_ are the ones affected by this. Distro builds don't ship a separate set of libraries. |
