-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Fix some frameworks not linking macos #17531
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
Conversation
|
For context, in the loop iterating over extensions was changed when that logic was moved to the frontend: for (&[_][]const u8{ ".tbd", ".dylib", "" }) |ext| {
if (try MachO.resolveFramework(arena, dir, f_name, ext)) |full_path| {
const info = options.frameworks.get(f_name).?;
try libs.put(full_path, .{
.needed = info.needed,
.weak = info.weak,
.path = full_path,
});
continue :outer;
}
}for (&[_][]const u8{ "tbd", "dylib" }) |ext| {
test_path.clearRetainingCapacity();
try test_path.writer().print("{s}" ++ sep ++ "{s}.framework" ++ sep ++ "{s}.{s}", .{
framework_dir_path,
framework_name,
framework_name,
ext,
});
try checked_paths.writer().print("\n {s}", .{test_path.items});
fs.cwd().access(test_path.items, .{}) catch |err| switch (err) {
error.FileNotFound => continue,
else => |e| fatal("unable to search for {s} framework '{s}': {s}", .{
ext, test_path.items, @errorName(e),
}),
};
return true;
}This change restores the previous behavior in main.zig. |
926137e to
df8458d
Compare
Pull request ziglang#16888 removed searching for libraries with no extensions when linking frameworks... this adds that feature back.
df8458d to
8870ead
Compare
kubkon
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
accessLibPath now has a `noextension` block to search for extension-less libraries.
|
I'm not entirely sure the full context of how things are supposed to work when linking MachO, but hopefully I applied the changes in the right way! (if the changes to |
|
Framework primary artifacts are usually named as follows:
Do we have any concrete examples of macOS SDK (new and old) or 3rd-party frameworks with following pattern?
|
|
So should this change remove the .dylib path also? TBH I've not dived into enough frameworks to know! (and it's obviously very hard to prove the non-existence of something, especially if it's just very rare!). |
|
This only mentions the primary artifacts having no extension, so is definetely good to go. I presume the .tbd extension is newer than this documentation? (Which was last updated in 2013 - so I presume that very well may be the case!). So @kubkon in light of this - what changes would you like to see this PR contain? (what is |
|
these are all the folders containing files with find /Applications/Xcode.app/Contents -name "*.dylib" -type f -exec dirname {} \; | grep Framework
/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVSimulator.platform/Developer/SDKs/AppleTVSimulator.sdk/System/Library/Frameworks/OpenGLES.framework
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks/OpenGLES.framework
/Applications/Xcode.app/Contents/SharedFrameworks/SwiftPM.framework/Versions/A/SharedSupport/PluginAPI
/Applications/Xcode.app/Contents/SharedFrameworks/SwiftPM.framework/Versions/A/SharedSupport/PluginAPI
/Applications/Xcode.app/Contents/SharedFrameworks/SwiftPM.framework/Versions/A/SharedSupport/ManifestAPI
/Applications/Xcode.app/Contents/SharedFrameworks/SwiftPM.framework/Versions/A/SharedSupport/ManifestAPI
/Applications/Xcode.app/Contents/SharedFrameworks/SwiftPM.framework/Versions/A/SharedSupport/ManifestAPI
/Applications/Xcode.app/Contents/SharedFrameworks/SourceKit.framework/Versions/A/XPCServices/com.apple.dt.SKAgent.xpc/Contents/Frameworks
/Applications/Xcode.app/Contents/SharedFrameworks/SourceKit.framework/Versions/A/XPCServices/com.apple.dt.SKAgent.xpc/Contents/Frameworks
/Applications/Xcode.app/Contents/SharedFrameworks/SourceKit.framework/Versions/A/XPCServices/com.apple.dt.SKAgent.xpc/Contents/Frameworks
/Applications/Xcode.app/Contents/SharedFrameworks/SourceKit.framework/Versions/A/XPCServices/com.apple.dt.SKAgent.xpc/Contents/Frameworks
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Libraries/usr/lib/swift/host
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Libraries/usr/lib/swift/host
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Libraries/usr/lib/swift/host
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Libraries/usr/lib/swift/host
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Libraries/usr/lib/swift/host
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Libraries/usr/lib/swift/host
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Libraries/usr/lib/swift/host
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Libraries/usr/lib/swift/host
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Libraries/usr/lib/swift/host
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Libraries/usr/lib/swift/host
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Libraries/usr/lib/swift/host
/Applications/Xcode.app/Contents/SharedFrameworks/DVTInstrumentsFoundation.framework/Versions/A/Resources
/Applications/Xcode.app/Contents/SharedFrameworks/DVTInstrumentsFoundation.framework/Versions/A/Resources
/Applications/Xcode.app/Contents/SharedFrameworks/AppIntentsSupport.framework/Versions/A/Resources
/Applications/Xcode.app/Contents/SharedFrameworks
/Applications/Xcode.app/Contents/SharedFrameworks/CoreSymbolicationDT.framework/Versions/A/Resources
/Applications/Xcode.app/Contents/SharedFrameworks/CoreSymbolicationDT.framework/Versions/A/Resources/libatos/libs
/Applications/Xcode.app/Contents/Frameworks
/Applications/Xcode.app/Contents/Frameworks |
diff --git a/src/main.zig b/src/main.zig
index 4b8061a52..5d7665356 100644
--- a/src/main.zig
+++ b/src/main.zig
@@ -6929,7 +6929,7 @@ fn accessFrameworkPath(
) !bool {
const sep = fs.path.sep_str;
- for (&[_][]const u8{ ".tbd", ".dylib", "" }) |ext| {
+ for (&[_][]const u8{ ".tbd", "" }) |ext| {
test_path.clearRetainingCapacity();
try test_path.writer().print("{s}" ++ sep ++ "{s}.framework" ++ sep ++ "{s}{s}", .{
framework_dir_path,... for also I'd like to add the reason why I am scrutinizing |
yup and seems to be consistent with SDKs all the way back to 10.3.9 . |
|
I want all three extensions handled including |
What about So, { |
That one needs more thought - does search strategy impact search here? I would like to leave that one be for the moment until we actually thoroughly investigate static frameworks. |
Yeah so I already tested with just patching main.zig and that fixed the motivating use case for me. |
|
So I want to confirm, in terms of this PR, we want this commit (exactly as-is.. leaving the .dylib stuff there): So I should go ahead and remove that second one? Is that the correct takeaway from this conversation @kubkon @mikdusan? I did validate that the first one was all that I needed to get SDL linking again. |
kubkon
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks!
Pull request #16888 removed searching for libraries with no extensions when linking frameworks... this adds that feature back.
This fixes #17294.