I have a strange issue with an application that uses libtool to load plugins at runtime. When run directly from the shell, it operates correctly. But when run as a child process of any kind (e.g. Python subprocess, /bin/sh -c <appname>) it fails to load the plugins with the error message lt_dlopen(<plugin.so>) returned NULL, lt_dlerror() = file not found.
The files certainly do exist, and they’re referenced by absolute paths so I don’t think it’s an RPATH-type issue. I’ve followed along in the debugger and whatever goes wrong happens after hitting assembly (inside dlopen()). This is also on a Mac, so I don’t have access to things like LD_DEBUG. And the build process for both the main application and the plugins is a big pile of Autotools which I can’t claim to understand.
So I am unsure how to debug this. Focusing on what (to me at least) is the most unusual factor, my question is thus: what could cause dlopen() to fail only when executed from a child process?
what could cause dlopen() to fail only when executed from a child process?
There are only a few things which may differ between the parent and child process (which affect dlopen). The ones which come to mind are:
- environment variables
- current working directory
uidandgid- current root (could be changed by
chroot(3)).
However, I would expect /bin/sh -c <appname> to leave everything intact, so it’s unclear why that fails.
I suggest changing the appname to print all of the above info on startup, and comparing what is printed by running /bin/sh -c <appname> and <appname> — maybe the difference will become apparent.