DYLD_LIBRARY_PATH and make

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:

This entitlement appears to be the answer:

https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-dyld-environment-variables?language=objc