search

swiftlang / swift-foundation

The Foundation project
Apache License 2.0
2.4k stars 159 forks source link

[6.0.1] Set SWIFT_SYSTEM_NAME for macro project in CMake #899

Closed jmschonfeld closed 2 months ago

jmschonfeld commented 2 months ago

Explanation: A configuration change that updates the rpath value of libFoundationMacros.so to be correct Scope: Only impacts the rpath value of libFoundationMacros.so Original PR: https://github.com/apple/swift-foundation/pull/896 Risk: Low - scope is narrow, and fixes a regression that causes the macro to not be loadable so it can't really make anything worse :) Testing: Testing done via local testing Reviewer: @parkera

jmschonfeld commented 2 months ago

@swift-ci please test

jmschonfeld commented 2 months ago

@swift-ci please test linux platform

jmschonfeld commented 2 months ago

@swift-ci please test

jmschonfeld commented 2 months ago

@swift-ci please test macOS platform

finagolfin commented 1 month ago

@jmschonfeld, I think you should have gotten this onto the 6.0.0 branch also at that time, as it is currently wrong for the patch releases:

> readelf -d swift-6.0*RELEASE*/usr/lib/swift/host/plugins/libFoundationMacros.so|ag "runpath|File:"
File: swift-6.0.1-RELEASE-fedora39/usr/lib/swift/host/plugins/libFoundationMacros.so
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../../../swift/:$ORIGIN/..]
File: swift-6.0-RELEASE-fedora39/usr/lib/swift/host/plugins/libFoundationMacros.so
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../../../swift/:$ORIGIN/..]

I don't know how much it matters though, as the glibc dynamic linker may just pick it up from an rpath from the compiler executable instead, so we can just wait till 6.0.2 till it's fixed.