8614 Views 8 Replies
      Latest reply: Oct 9, 2015 7:24 AM by khoyt RSS
      gtoronto Level 1 Level 1 (0 points)
      gtoronto Jul 10, 2015 5:21 AM

        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.

        • Tags:
        • Re: DYLD_LIBRARY_PATH and make
          aburgh Level 1 Level 1 (0 points)
          aburgh Jul 14, 2015 3:55 PM (in response to gtoronto)

          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.

            • Re: DYLD_LIBRARY_PATH and make
              JGD Level 1 Level 1 (0 points)
              JGD Jul 17, 2015 8:23 AM (in response to aburgh)

              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.

              • Re: DYLD_LIBRARY_PATH and make
                JGD Level 1 Level 1 (0 points)
                JGD Jul 17, 2015 9:35 AM (in response to aburgh)

                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

              • Re: DYLD_LIBRARY_PATH and make
                khoyt Level 1 Level 1 (0 points)
                khoyt Oct 9, 2015 7:24 AM (in response to gtoronto)

                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.