top | item 10790524

(no title)

I'm idly curious: what were your "symlink issues with /usr/bin/"? As with other unices, /usr is system-owned and anything not under the /usr/local hierarchy may be modified or destroyed during OS upgrades.

Very few people should ever need to disable SIP – and that includes almost all developers! Are you building/running unsigned kexts? No? Then you almost certainly don't need to disable SIP.

Most instructions that no longer work with SIP enabled should be modified so they don't conflict with SIP. As a bonus: changes resulting from those instructions are far more likely to be preserved across OS X upgrades.

discuss

vitd|10 years ago

One completely normal developer thing I need to do that involved turning off SIP is setting library and framework paths to debug an executable outside of Xcode.

We archive our daily builds so we can regress problems to a specific check-in. Now I could just roll back my source and build from that, but that takes significantly longer than just copying the regression build from the server. (Not to mention that if the revision is old enough, I need to install an older OS and Xcode just to build it.)

But our archives are straight out of an Xcode development build - they contain separate libraries and frameworks that we build and that aren't moved into the executable like during an install. So to run them from a disk image you need to set DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH to get the OS to know where to look for them. But this doesn't work with SIP. This is not some low-level kext-related issue. This is pretty basic development stuff with Xcode.

gdavisson|10 years ago

SIP shouldn't interfere with DYLD variables for normal (non-"restricted") executables. Unless you're using something like Java, which normally runs via a restricted launcher; but in that case you can bypass the launcher (see https://bugs.openjdk.java.net/browse/JDK-8139288).

tristanj|10 years ago

Java troubles. A java application I needed required the latest java update but after running the Oracle updater, /usr/bin/java still pointed to the previous version. A simple solution is to point the symlink to the right place, but with SIP enabled that symlink can't be modified. Here's the stack overflow guide I was following: https://stackoverflow.com/questions/12757558/installed-java-...

Looking back, I think you are right, it would have been easier to just add a symlink under the /usr/local/bin folder. Though it didn't cross my mind at that point.