swift 6.2 #245341
swift 6.2 #245341
Conversation
cho-m
added
the
CI-no-fail-fast
github-actions
bot
added
python
cho-m
force-pushed
the
swift-6.2
branch
4 times, most recently
from
f4c9662 to
1631a38
Compare
This comment was marked as resolved.
This comment was marked as resolved.
|
macOS (Sonoma) is still failing on audit which will prevent bottle upload: Not sure why yet. EDIT: could be Sonoma specific? Tahoe looks okay (only the May need to check Sequoia run to see if we need a workaround to avoid resolving the library here given it should use the copy inside formula. |
|
Xcode doesn't seem to ship I guess we could either hack it for Historically we'd skip the stdlib entirely but it's a bit more complicated nowadays to make that work. Apple probably do something special to get it to work in Xcode.app builds. |
|
With |
|
Ah looks like that option is bugged in Swift 6.2 it seems. Easiest option then it just to let it build and remove the executable. |
|
macOS is ready while Linux is getting closer. Seems to have gotten past where gold failed for me locally. I think Linux may have previously worked from shim Maybe some |
|
|
|
Running with following patches. Will keep draft until can confirm everything works: |
|
Yeah the llbuild stuff is basically from them not using If I understand your issue correctly, the patch could be extended with: #if os(Linux)
if let target = package.targets.first(where: { $0.name == "llvmSupport" }) {
target.linkerSettings = [
.linkedLibrary("ncurses"),
.unsafeFlags(["-LHOMEBREW_PREFIX/opt/ncurses/lib"])
]
}
#endifIn a similar fashion to the sqlite3 patch, except there isn't an existing BSD block to hijack so would be an addition. The generic solution here is actually just to make it use |
|
Ah posted that just as you linked that PR - looks like you had the same idea! |
|
Just linkage failure on missing library left. Will need to check bottle where this is happening: |
|
Maybe: ❯ objdump -p libexec/lib/swift/host/compiler/lib_InternalSwiftScan.so | rg libswiftCore.so
NEEDED libswiftCore.so
❯ objdump -p libexec/lib/swift/host/compiler/lib_InternalSwiftScan.so | rg '\s*RPATH\s*(.*)' -r '$1' | tr ':' '\n' | rg ORIGIN
$ORIGIN
$ORIGIN/./swift/linux
$ORIGIN/../linux
$ORIGIN/swift/host/compiler
$ORIGIN/compiler
❯ fd libswiftCore.so
libexec/lib/swift/linux/libswiftCore.soAfter library was moved in swiftlang/swift@7f67eb3 |
|
Given the comment here says It seems that's where it's outdated and should have Because of the symlink it's possible it may need both old ( |
cho-m
added
CI-no-fail-fast-deps
|
If builds pass but some dependents fail, may just go ahead with merge and fix those separately. Too slow to have to risk rebuilds of Swift (if bottle cache is invalidated). Dependents are mainly on Linux where Swift formulae are less commonly installed. Still waiting to see if x86_64 Linux is okay (previous run didn't have enough disk space). arm64 Linux was successful. EDIT: Follow ups: https://github.com/Homebrew/homebrew-core/actions/runs/18007973778/job/51265002516?pr=245341#step:4:606 |
|
I think SourceKitten doesn't like the exec scripts. When I rebuild, the current error goes away but it fails to get path to I added them as Swift internally doesn't like our symlinks and complains: Though above at least falls back whereas SourceKitten has trouble. Since SourceKitten is a pretty common dependency, will likely need to use symlinks. EDIT: still expected to fail until rebuild, but locally confirmed to work after rebuild when using symlinked swift. |
|
Caution Please do not push to this PR branch before the bottle commits have been pushed, as this results in a state that is difficult to recover from. If you need to resolve a merge conflict, please use a merge commit. Do not force-push to this PR branch. |
github-actions
bot
added
the
CI-published-bottle-commits
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where<formula>is the name of the formula you're submitting?brew test <formula>, where<formula>is the name of the formula you're submitting?brew audit --strict <formula>(after doingHOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it passbrew audit --new <formula>?Will try working out issues with Swift build. macOS at least built locally. Cleaned up a few warnings.
Last local Linux run failed, so still experimenting with to fix linker problems.
Closes #244944