Unable to setenv DYLD_LIBRARY_PATH using launchctl command on El Captian.

You haven't asked a question here, making me suspect that you'd be better off filing a bug report rather than posting here on DevForums.

If you do file a bug, please post your bug number, just for the record.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

My question is why is that DYLD_LIBRARY_PATH variable is not set by launchctl setenv, when I can set it for a dummy variable.

My question is why is that

DYLD_LIBRARY_PATH

variable is not set by launchctl setenv, when I can set it for a dummy variable.

This is the first time you've mentioned a dummy variable. Can you explain what you mean by that?

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi,

Dummy varaible I mean "TEST_PATH". The following commands work

$ launchctl setenv TEST_PATH /Path/to/my/dynamic/libraries

$ launchctl getenv TEST_PATH

Regards,

Rashmi

OK, that's much clearer, thanks.

It seems that this restriction is a deliberate change (r. 18744994) made to enhance security. Right now the restriction applies to:

• LD_LIBRARY_PATH

• anything starting with

  DYLD_

Disabling system integrity protection will also disable this check.

What are you using this feature for? I'm curious about the context of your question because, well, it seems to me that this restriction might be overly broad.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi,

I am using this variable to launch an application built on MatLab Compiler Runtime (MCR). The MCR includes a set of dynamic libraries whose path needs to be added to the DYLD_LIBRARY_PATH. Without these path set, the application would not launch.

An bug has been file on this regard, bug Id for the same is 22227990.

Regards

Rashmi

The MCR includes a set of dynamic libraries whose path needs to be added to the

DYLD_LIBRARY_PATH

.

That seems like an odd way to build an app. There are two alternatives, both of which avoid this pitfall:

• Put the runtime libraries in some fixed location on disk (

  /usr/local/YourCompanyName

  is traditional, but

  /Library/Frameworks/YourFrameworkName

  works as well) and then reference them via an absolute path.

• Put the runtime libraries within the app and then reference them via

  @loader_path

  ,

  @executable_path

  or

  @rpath

  . This is how Swift bundles its runtime libraries within an app.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

> That seems like an odd way to build an app.

Sure, but I would have assumed that people with long experience in the software field know that there are lots of very complicated ways to build large software packages out there. And no, it is not a good idea to install stuff during the build phase in their final destinations, like some /usr/local/YourCompanyName or /Library/Frameworks/YourFrameworkName. This LD_LIBRARY_PATH issue bites especially multi-platform software, that has a build mechanism that until now, with relatively small platform dependencies, has worked fine on several Unix-like systems. We see the same root cause now preventing building LibreOffice on OS X 10.11.

Is this change in behavior documented anywhere we'd have access to? I too have a dependent application that requires DYLD_LIBRARY_PATH to be set. I'd really like to be able to point the developer to an Apple doc that describes the change.

Yeah, they don't believe me :-)

Details:

to run said app, I use setenv to put DYLD_LIBRARY_PATH into the environement then exec /bin/sh to run the app. Used to work now not so much :-(

Meaning, setenv seems to have been 'improved' in the name of security too and exec'd applications don't pick up the path.

From the System Integrity Protection Guide: Runtime Protections article:

-----

When a process is started, the kernel checks to see whether the main executable is protected on disk or is signed with an special system entitlement. If either is true, then a flag is set to denote that it is protected against modification. … Any dynamic linker (dyld) environment variables, such as DYLD_LIBRARY_PATH, are purged when launching protected processes.

-----

Since all system-provided script interpreters (bash, perl, python, etc.) are protected processes, dyld environment variables are purged when you run any script (even if the script itself is not protected). Personally, I think this part is a bad policy or an oversight, but such is life.

Just to voice my discontent, this has to be one of the craziest (I replaced the word I really wanted to use) "security" changes. For the longest time I've advocated OSX-based macs as excellent development platforms for multi-platform, Linux software. In one fell swoop Apple seems to have killed this for now. Do I own a powerful linux-like laptop or a phone with a big screen? If at least the manpage for dyld would mention this little fact about now not ever exporting dyld_library_path, I might have saved a day or two of troubleshooting this.

I haven't tested it (since it turns out @executable_path/... is working sufficiently in my case), but for those who need it, I believe the answer is this entitlement:

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