You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This removes support for compiling files with bitcode from SWBuild, as this functionality is no longer supported. This removes a lot of functionally dead code.
Support for stripping bitcode from copied files remains, as there are extant libraries and XCFrameworks which contain bitcode, which must be stripped. Bitcode was only supported for a subset of platforms, to the assignment of STRIP_BITCODE_FROM_COPIED_FILES in Settings based on platform remains, so time isn't spent stripping nonexistent bitcode from other platforms.
Some interfaces which Xcode uses continue to refer to bitcode for compatibility, but effectively do nothing.
Note that the references to bitcode in the OpenCL support are a concept internal to that tool, and independent of the support being removed here.
rdar://148287993
Copy file name to clipboardExpand all lines: Sources/SWBCore/Settings/Settings.swift
+1-26Lines changed: 1 addition & 26 deletions
Original file line number
Diff line number
Diff line change
@@ -2617,7 +2617,7 @@ private class SettingsBuilder {
2617
2617
// FIXME: Why is this logic not part of loading the SDK in SDKRegistry.registerSDK()? I think all of the information currently used by this method should be available there.
self.targetDiagnostics.append(Diagnostic(behavior:.warning, location:.buildSetting(BuiltinMacros.ENABLE_BITCODE), data:DiagnosticData("Building with bitcode is deprecated. Please update your project and/or target settings to disable bitcode.")))
self.targetDiagnostics.append(Diagnostic(behavior:.warning, location:.buildSetting(BuiltinMacros.ENABLE_BITCODE), data:DiagnosticData("Ignoring ENABLE_BITCODE because building with bitcode is no longer supported.")))
4215
-
}
4216
-
}
4217
-
4218
4193
// If testability is enabled, then that overrides certain other settings, and in a way that the user cannot override: They're either using testability, or they're not.
4219
4194
if scope.evaluate(BuiltinMacros.ENABLE_TESTABILITY){
@@ -63,41 +61,22 @@ public final class CopyToolSpec : CompilerSpec, SpecIdentifierType, @unchecked S
63
61
guard stripBitcode else{
64
62
returnnil
65
63
}
66
-
// If we have been directed to strip bitcode, and bitcode is either disabled or is turned to a level less than 'bitcode' (i.e., less than full bitcode), then we should strip bitcode from binaries we copy.
67
-
if !enableBitcode || bitcodeGenerationMode !="bitcode"{
if cbc.scope.evaluate(BuiltinMacros.ENABLE_BITCODE) && supportsBitcode {
40
-
// LD_BITCODE_GENERATION_MODE is the linker setting which controls passing bitcode options to the linker; but since we're invoking the linker directly here, rather than the compiler driver, we pass -bitcode_bundle rather than -fembed-bitcode*.
41
-
commandLine +=["-bitcode_bundle"]
42
-
43
-
// If we're generating full bitcode, then we also want to pass -bitcode_verify to make sure all the objects it links against also contain full bitcode.
44
-
if cbc.scope.evaluate(BuiltinMacros.BITCODE_GENERATION_MODE)=="bitcode"{
45
-
commandLine +=["-bitcode_verify"]
46
-
}
47
-
}
48
-
49
37
// We do not pass the deployment target to the linker here. Instead the linker infers the platform and deployment target from the .o files being collected. We did briefly pass it to the linker to silence a linker warning - if we ever see issues here we should confer with the linker folks to make sure we do the right thing. See <rdar://problem/51800525> for more about the history here.
0 commit comments