View Issue Details

IDProjectCategoryView StatusLast Update
0008417ardourbugspublic2020-09-21 20:12
Reportermvf Assigned To 
Status newResolutionopen 
Platformx86_64, glibcOSLinuxOS Versionany
Product Version6.3 
Summary0008417: Plugins can't start programs due to LD_LIBRARY_PATH
DescriptionIn 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 ReproduceNote: 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 (
3. In the plugin editor, click the "Menu" button in the far bottom right
4. Select "Surge Manual" from the menu

Nothing happens.

Browser opens Surge Manual.
Additional InformationThe '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 shipped with Ardour is missing a symbol:

$ LD_LIBRARY_PATH=/opt/Ardour-6.3.0/lib xdg-open
XPCOMGlueLoad error for file /usr/lib/firefox/
/usr/lib/ 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 (0x00007ffd38fde000) => 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 (0x00007fff77b11000) => /opt/Ardour-6.3.0/bin/../lib/ (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

TagsNo tags attached.



2020-09-21 15:55

administrator   ~0025045

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.


2020-09-21 20:12

reporter   ~0025047

> 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.

Issue History

Date Modified Username Field Change
2020-09-21 15:45 mvf New Issue
2020-09-21 15:55 x42 Note Added: 0025045
2020-09-21 20:12 mvf Note Added: 0025047