... That is, put a little shell script in the application bundle, and invoke
it (in Release, though not Debug where it interferes with Xcode debugging)
See commit 07661c186f
The shell nulls the environment variable DYLD_LIBRARY_PATH and then executes
the main program.
This is needed because changes to DYLD_LIBRARY_PATH during the main program's
run fail to affect the loading of dynamic libraries afterward.
We need null in DYLD_LIBRARY_PATH to make absolute paths to libraries take
priority.
More info:
Documentation of workings of the macOS dynamic loader
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html
The same problem and solution is discussed here
https://stackoverflow.com/questions/6713692/problems-with-using-setenv-and-then-making-the-dlopen-call
It is claimed there that Firefox did the same trick with a shell, which I do
not observe in my version, but GIMP 2.8.16 does this, as I can see by examining
package contents
Also note the mention in this commit's comments (where the script was removed
because bug543's fix left it unused), that the script also used to
interfere with signing. I hope that there will be a way around that.
98186b9317
This should fix the detection problems on the Mac and may even help with issues
on Windows and Linux.
On any of the platforms, the main issue is the search path for libraries and
how absolute path names are handled. The Mac seems to be especially
susceptible since there isn't one concrete location where libraries are stored.
Windows handles absolute paths differently and allows runtime updates to the
environment variables (and if push comes to shove, provides the
SetDllDirectory() function), so if problems still exist, they should be easy to
circumvent.
This patch does three things:
1) It adds a shell script on OSX that takes care of starting Audacity after
reassigning and clearing the DYLD_LIBRARY_PATH environment variable. This will
allow loading of libraries from their absolute path rather than searching
DYLD_LIBRARY_PATH first. This script should be transparent to the user, but it
will affect people running Audacity with gdb as they will have to specifically
target Audacity.app/Contents/MacOS/Audacity instead of the Audacity.app bundle.
Not big deal really. If ppl no enough to use gdb from the command line, they
should be able to figure it out.
2) It corrects detection of a monolithic FFmpeg library. This is one where
avformat, avcodec, and avutil have all been linked into one large library. The
main issue here was that under OSX and Linux, looking for symbols that should
reside in avutil and avcodec, would always succeed since dlsym() on these
platforms not only scans the requested library, but any dependent libraries as
well. And when avformat was loaded, it would pull in it's dependent libraries
as well.
Another issue here was the if it was determined that the library was not
monolithic, the library was never unloaded, so those dependent libraries may
have come from the wrong location since they would have been loaded via the
normal search paths and not by absolute path name.
3) It adds a method to FileNames which returns the full path name of a loaded
module that contains an address. In the case of FFmpeg, it is used to verify
that a routine from a specific library is actually being used from that library
or not. It is also used to show (in Help->Show log) the directory from which a
library was actually loaded.
Paul Licameli
Leland Lucius
lllucius