Bug290 (load LAME, FFmpeg from correct place): original fix again...

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

mac/scripts/create_info_header.sh

@@ -21,8 +21,14 @@ done
 cd ${TOPLEVEL}
 mkdir -p mac/build
 eval $(g++ -E -dM src/Audacity.h | awk '/#define *AUDACITY_(VERSION|RELEASE|REVISION|MODLEVEL) /{print $2 "=" $3}')
+if [ $CONFIGURATION == 'Debug' ]
+then
+    AUDACITY_EXECUTABLE=Audacity
+else
+    AUDACITY_EXECUTABLE=Audacity.sh
+fi
 cat >mac/build/Info.plist.h <<EOF
-#define AUDACITY_EXECUTABLE Audacity
+#define AUDACITY_EXECUTABLE ${AUDACITY_EXECUTABLE}
 #define AUDACITY_VERSION ${AUDACITY_VERSION}
 #define AUDACITY_RELEASE ${AUDACITY_RELEASE}
 #define AUDACITY_REVISION ${AUDACITY_REVISION}