Work-around System Integrity Protection on El Capitan. #808
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@groutr, @ilanschnell, @kalefranz I'd appreciate a review when you guys have a chance, I'm not sure why travis is failing, the same test succeeded locally. |
mingwandroid
force-pushed
the
macho-otool-improvements
branch
5 times, most recently
from
d030c68
to
29808e5
Compare
|
I'm not sure exactly why the test is failing either. The code looks good to me, though. |
mingwandroid
force-pushed
the
macho-otool-improvements
branch
from
29808e5
to
111688b
Compare
|
Tests are failing because Python 3.3 is not supported by conda 4. So, must install conda 3. Also, the error message has changed for one test failure on conda 4. For the fix to these issues, see this PR ( #812 ). |
|
@mingwandroid I think this needs to be rebased off master again to pick up the changes from #812 |
Use otool -l instead of otool -L This is foundational work to provide richer information about Mach-O binary files for subsequent work and it also allowed some clean-up opportunities. otools -l lists all of the load commands in detailed form whereas otool -L is a very blunt tool indeed, so blunt it doesn't distinguish between the totally different concepts LC_ID_DYLIB (self) and LC_LOAD_DYLIB (other). Now, all the load commands are read and those that pass the filter callback are made into a list of dictionaries and returned. It allowed removing a hack from mk_relative_osx in post.py where it would run install_name_change -change on the LC_ID_DYLIB load command because it couldn't know not to and then ran install_name_change -id to effect the change needed. Now this is all done in a single pass of install_name_change/osx_ch_link. Moved add_rpath from being inline code in post.py to its own function in macho.py
Since El Capitan introduced System Integrity Protection, the DYLD_* environment variables can not be used and DYLD_FALLBACK_LIBRARY_PATH cannot augment the dynamic loader search path: http://apple.stackexchange.com/q/212945 .. so add an extra -rpath instead. This is removed once the build has completed, prior to testing. A number of packages contain dylibs with LC_ID_DYLIB load commands whose name contains nothing but the filename. These need to be rebuilt so that they contain @rpath/ unfortunately. The majority are fine however.
Wanted to perform some global queries on all dylibs in my Anaconda installations to get the id names and refactoring this seemed like an appropriate approach. Added macho.get_id(path) for the same end.
mingwandroid
force-pushed
the
macho-otool-improvements
branch
from
111688b
to
1d73b4f
Compare
|
@groutr thanks, done. |
groutr
added a commit
that referenced
this pull request
Mar 9, 2016
Work-around System Integrity Protection on El Capitan.
|
Thanks |
This was referenced Mar 10, 2016
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The first commit is about making otool more useful / informative, then removing a hack and a bit of refactoring.
The 2nd commit builds on it and is important. Any package that depends on DYLD_FALLBACK_LIBRARY_PATH on OS X can't be built currently on 10.11 and this change addresses that. My approach is to add an -rpath to LDFLAGS during the build and then remove it from the executables at the end.
I went down a different path for fixing this initially (modifying the LC_ID_DYLIB load command names in the dylib files in the build environment) but backed it out when I realized it would've required copying instead of hard-linking when installing packages into the build environment. Also doing it as-per this PR involves less code (but it does rely on people not overriding LDFLAGS in build.sh)
We could mark packages that need this work-around explicitly, but I feel that it needs to work in every case anyway.
Finally, some packages that have dylibs with incorrect LC_ID_DYLIB load command names (they are missing '@rpath/') and they need to be rebuilt. I'm going to get a list together.