New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LD_RUNPATH_SEARCH_PATHS set on macOS target for Cocoapods 1.11.0 fail XProtectService check on Mojave #10954
Comments
Thanks for the great issue report! Should we not be adding those for macOS projects? |
Thanks, it was a team effort connecting all the dots of what was causing this. My opinion would be no-- we should not add rpath references for outside the bundle, at least not by default. Especially something that is a reference to the Xcode Swift toolchain ( |
The PR you linked allows to build and run app specs or test specs that do not contain Swift but their libraries do. Having a are you using app specs for a macOS target? |
I figured there must be some kind of use case for it so adding a condition to preserve it would make sense. I'm not familiar with using app specs, we're not using them to my knowledge. Here's the
|
A bit more detail why adding paths outside the bundle is not a good idea (macOS target, not iOS) if dynamic library validation is disabled; then macOS will do a extensive check for any libraries outside the bundle. In my case, dynalic lv is disabled because I need to load external plugins. Apple DTS have written about this in depth, here: https://developer.apple.com/forums/thread/706414 In short though, if you do a otool -l | grep -B 1 -A 2 LC_RPATH and you see anything that is an external reference outside the bundle, the app will not load (it'll be prevented by gatekeeper) here's an example from a brand new swift project with one pod (as framework) addded:
Which will cause the resulting app to fail to load/run Here's my Podfile, for reference (basically you just need at least one framework)
Update: In my specific case, I had another bug in my build causing LC_RPATH's into /User. However; above comment is still technically correct (thus a problem) even though right now a signed, notarized binary will actually work. Apple recommend that your binary should have zero paths pointing outside of itself. |
…PATHS` referencing outside the App bundle for macOS targets. (CocoaPods#10954)
Recently I encountered exactly the same issue after upgrading CocoaPods to 1.11.3. I've made a PR to address this issue and the following snippet in work_dir = Dir.pwd
installer.aggregate_targets.each do |target|
if target.name == 'Pods-AppTarget'
target.user_build_configurations.each do |key, name|
if key == "Debug" || key == "Release"
xcconfig_filename = "#{work_dir}/Pods/Target Support Files/#{target}/#{target}.#{name}.xcconfig"
xcconfig = File.read(xcconfig_filename)
xcconfig = xcconfig.gsub(/(LD_RUNPATH_SEARCH_PATHS = .*?)"\${DT_TOOLCHAIN_DIR}\/usr\/lib\/swift\/\${PLATFORM_NAME}"(.*)/, "\\1\\2")
File.open(xcconfig_filename, "w") { |file| file << xcconfig }
end
end
end
end |
…PATHS` referencing outside the App bundle for macOS targets. (CocoaPods#10954)
…PATHS` referencing outside the App bundle for macOS targets. (CocoaPods#10954)
…PATHS` referencing outside the App bundle for macOS targets. (CocoaPods#10954)
Report
What did you do?
Upgraded Cocoapods from 1.10.2 to 1.11.0.
What did you expect to happen?
LD_RUNPATH_SEARCH_PATHS
in the xconfig generated bypod install
does not contain rpaths outside the main executable.From the xconfig generated by
pod install
:What happened instead?
LD_RUNPATH_SEARCH_PATHS
have references outside the bundle, which prevents the application from opening on Mojave.From the xconfig generated by
pod install
:I've traced the change to this pull request. The connection between reported objective of this PR and this particular change isn't quite clear to me.
When I try launching the executable, I get the following error from the
XProtectService
process via the Console.app:A couple important notes:
Here's a similar issue that was solved by removing rpath references outside the bundle.
CocoaPods Environment
Project that demonstrates the issue
This configuration output should be reproducible with any macOS project, as long as your Cocoapods version is >= 1.11.0
The text was updated successfully, but these errors were encountered: