DYLD_LIBRARY_PATH and make

Recently upgraded to the latest El Cap beta 15A216g. I have several build steps (Qt/clang/make/etc) that rely on DYLD_LIBRARY_PATH being set so that the proper libraries can be found. If I do this:


$ DYLD_LIBRARY_PATH=/path/to/libicu make

uic /Users/gtoronto/build/test/test.ui

dyld: Library not loaded: libicui18n.46.dylib

Referenced from: /usr/local/Qt-5.2.1/lib/QtCore.framework/Versions/5/QtCore

Reason: image not found


However if I do this:


$ DYLD_LIBRARY_PATH=/path/to/libicu uic /Users/gtoronto/build/test/test.ui


Then the file gets generated correctly. This started happening only when upgrading El Cap.

Replies

It may have been changed in the name of security. On Yosemite:


bash-3.2$ DYLD_PRINT_LIBRARIES=1 X=1 /usr/bin/printenv
dyld: loaded: /usr/bin/printenv
dyld: loaded: /usr/lib/libSystem.B.dylib
dyld: loaded: /usr/lib/system/libcache.dylib
...
dyld: loaded: /usr/lib/libc++.1.dylib
dyld: loaded: /usr/lib/libDiagnosticMessagesClient.dylib
X=1
DYLD_PRINT_LIBRARIES=1
TERM_PROGRAM=Apple_Terminal
...


But on El Capitan, all the `dyld: loaded:` messages are not printed and DYLD_PRINT_LIBRARIES is not in the list of variables, but X is. I have the same problem with makefiles that you do.

I'm seeing similar problems with a build system that consists entirely of shell scripts and C programs. I'll post again if/when I figure it out.

OK, I have at least part of the story. If a script file begins with "#!/bin/bash", or any other #!/path/to/interpreter, the DYLD environment variables are omitted from the set of environment variables passed to that interpreter. This applies even if the current and new interpreters are instances of the same interpreter.


This doesn't seem to apply to executables. Here's a really minimal program to print an environment variable:


#include <stdio.h>
#include <stdlib.h>
int main( int argc, char *argv[])
    {
    if( argc >= 2)
        {
        printf( "$ENV{%s} is \"%s\"\n", argv[1], getenv( argv[1]));
        }
    return 0;
    }


and that can see $DYLD_FALLBACK_LIBRARY_PATH quite happily.


I don't know about the "uic" command the OP was using: is that a script?


John

The DYLD_FALLBACK_LIBRARY_PATH feature is still in 10.11 Beta 4.

... and is reported in Apple Bug Reporter.

Having exactly the same issue. Our cross-platform build system (written in Python and using Qt qmake + make) is broken on El Capitan, disabling system integrity protection doesn't prevent this. Is there any way to allow passing of the DYLD_ variables to shells and using them from there? At least I would expect this behavior to respect the system integrity protection settings!

filed as bug report 22300976

Since I ran into this too, from the System Integrity Protection Guide:



Spawning children processes of processes restricted by System Integrity Protection, such as by launching a helper process in a bundle with NSTask or calling the exec(2) command, resets the Mach special ports of that child process. Any dynamic linker (dyld) environment variables, such as DYLD_LIBRARY_PATH, are purged when launching protected processes.