Swift 3.1でぶっ壊れたSourceKit on Linuxを復活させるために、とりあえずLinuxでのテストを復活させるPRがマージされたのですが、ubuntu 14.04でのみ失敗するという想定外の展開に。 https://github.com/apple/swift/pull/8485

Enable SourceKit tests if building SourceKit by norio-nomura · Pull Request #8485 · apple/swift

Enable SourceKit's tests if building SourceKit Change packaging sourcekit-inproc from sourcekitdInProc.framework to libsourcekitdInProc.so on non Darwin platforms This will be required for #8189 ...

1:56 AM

手元ではubuntu 16.04で検証をしていたのですが、どなたか14.04と16.04での違いとか知っている方はいませんかね…

1

-- Exit Code: 134 Command Output (stderr): -- <snip> terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc pure virtual method called terminate called recursively /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/test-linux-x86_64/SourceKit/ExtractComment/Output/extract_comments.swift.script: line 19: 6097 Aborted (core dumped) /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/bin/sourcekitd-test -req=extract-comment -pass-as-sourcetext /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/test/SourceKit/ExtractComment/Inputs/DocCommentEmptyLine1.swift > /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/test-linux-x86_64/SourceKit/ExtractComment/Output/extract_comments.swift.tmp.DocCommentEmptyLine1.response

2:00 AM

メモリ関連？

terminate called after throwing an instance of 'std::bad_alloc'

what(): std::bad_alloc pure virtual method called terminate called recursively

次のビルドでは別のテストが同じエラーで失敗している。 non deterministic ですね。

2:04 AM

https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/2231/

初期化もれがあって、プラットフォームの違いで顕在化してる感じなのかな。

なるほどなあ

エラーで検索すると、未初期化

2:07 AM

のメモリにアクセスしている的な感じですね。

ありがとうございます。

それか、メモリ不足？

とりあえず、手元で再現できるようにしないと。

Packageは通ってる不思議 https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-14_04/627/

non-deterministic なので、 revert 前のいくつかのビルドでも通ってますよ。 https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/2232/ https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/2237/

なるほど…

とりあえず debug の tip として、特定のテストだけ走らせるには

# test/SourceKit ディレクトリ内だけ全部 $ utils/run-test --build-dir ../build/Ninja-DebugAssert/ test/SourceKit/ # 特定のテストケースだけ $ utils/run-test --build-dir ../build/Ninja-DebugAssert/ test/SourceKit/ExtractComment/extract_comments.swift # verbose出力 $ utils/run-test -v --build-dir ../build/Ninja-DebugAssert/ test/SourceKit/ExtractComment/extract_comments.swift

verbose 出力で実際の実行コマンド群が見えるのでそれをデバッガで見ていく感じです。

1

ありがとうございます。

全体で DebugAssert ビルドするときついので、 swift tool のデバッグするときは $ utils/build-script -R --debug-swift でビルドしてます。その場合は build-dir は ../build/Ninja-ReleaseAssert+swift-DebugAssert ですね。

以前使っていたubuntu 14.04のdockerイメージではビルドできなくなっていたので、そちらの更新からです。

なんとなく原因が見つかったぽい。

3:26 AM

SourceKitはLinux版とmacOS版でそれぞれInProcとXPCに一部実装が分かれていて、InProc版のテストが無効化されているせいで破壊的な変更がXPC版だけに入ってしまい、InProc版が壊れてきてた。

1

3:29 AM

そんなXPC版への変更が、PRをオープンして以降にさらに入ってた。 https://github.com/apple/swift/commit/65668c9d82fcb65f52172d4b1e25f47922744f82#diff-0ff30e883d2a6d6a213ed6714d4845e9

Cache Code Completion results from PCH files · apple/swift@65668c9

Add CompilerInvocation::getPCHHash This will be used when creating a unique filename for a persistent precompiled bridging header.
- Automatically generate and use a precompiled briding head...

3:32 AM

ビルドエラーやテストで即座に失敗するようなものはPRに反映できてたけど、これは気づかなかった。

SourceKitのInProc版が壊れていた事が原因で、そのテストが無効になっていたから発見が難しかった、という事？

テストが無効にされた時には壊れていなかったのですが、無効にされて以降共通部分とXPC版に変更が入り、InProc版が壊れたのです。

互換性を保たなきゃいけない2者のテストは切っちゃいけない気がする。

はい。Apple的にはInProc版を捨てたいのだと思います。

あ〜、なるほど。最終的には単一化するんですね。

あいや、先のコミットが原因ではないかも…

3:53 AM

LinuxにはXPC相当の仕組みってあるのかな

https://developer.apple.com/reference/xpc

3:55 AM

なるほど、macにこんなAPIがあったのか

App ExtensionとかがXPCを基にしているはずです

あ〜

ぬううん、手元で再現しないい。

結局 ubuntu 14.04 ではテストを実行しないという方向で進めることに。 https://github.com/apple/swift/pull/9025

Enable SourceKit tests if building SourceKit other than ubuntu 14.04 by norio-nomura · Pull Request #9025 · apple/swift

Continue from #8485 Disable sourcekit test on ubuntu 14.04 because of non-deterministic failures #8485 (comment) Resolves SR-1676, SR-4490, SR-4491

マジすか・・・

3:55 AM

LinuxでSwiftやってみようとおもったら、ubuntu 14.04は避けといたほうが良さそうですね

「ubuntu 14.04 はもうサポートしない」というアナウンスが以前あったのですが、何故かまだサポートされているのですよね。

一度 CI からも無くなったんですが、コミュニティからの要望で復活しましたね。

そうなのですね、知らなかった。Travisが14.04だからかな。

結局 ubuntu 14.04 ではテストを実行しないという方向で進めることに。

昨日マージされて 16.04, 16.10 では問題なく動いてる。

SourceKitをLinuxのToolchainパッケージに含めるPRが、CIでswiftpmのテストに何故か失敗。 https://ci.swift.org/job/swift-PR-Linux-smoke-test/7184/

7:39 AM

PRの変更とは関係ないはず〜と再テストをPRのコメントで要求するが、誰も反応してくれず。

7:39 AM

SwiftPMのテストだったので、SwiftPMのSlackでaciidさんに相談してCIをスタートしてもらった

(edited)

ぉ、なんかテスト中に SourceKit がクラッシュしたっぽい。再現性なし。 Ubuntu 16.04 です。

FAIL: Swift(linux-x86_64) :: SourceKit/CursorInfo/cursor_no_cancel.swift (443 of 9803) ******************** TEST 'Swift(linux-x86_64) :: SourceKit/CursorInfo/cursor_no_cancel.swift' FAILED ******************** Script: -- <省略> -- Exit Code: 1 Command Output (stderr): -- /home/rintaro/Documents/swift-oss/swift/test/SourceKit/CursorInfo/cursor_no_cancel.swift:39:11: error: expected string not found in input // RANGE: source.lang.swift.range.singleexpression ^ <stdin>:1:1: note: scanning from here #0 0x00007f124b02b0e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (BUILD_DIR/lib/libsourcekitdInProc.so+0x9850e8) ^ <stdin>:6:21: note: possible intended match here #5 0x00007f124b07024a SourceKit::SwiftLangSupport::~SwiftLangSupport() (BUILD_DIR/lib/libsourcekitdInProc.so+0x9ca24a) ^ -- ********************

おお。

6:18 AM

やっぱり僕のコミットでバグを入れてしまった気がするなあ…

6:23 AM

これ https://github.com/apple/swift/pull/8485/commits/278c9de5d4e6bfc8fe1e0a718afd8f2c488ee9e2 とこれ https://github.com/apple/swift/pull/8485/commits/8ca7c1dd80a35a79208befdb631da92514b2cbc3 がcppのコードを修正してて、自信がない。

Enable SourceKit tests if building SourceKit by norio-nomura · Pull Request #8485 · apple/swift

Enable SourceKit's tests if building SourceKit Change packaging sourcekit-inproc from sourcekitdInProc.framework to libsourcekitdInProc.so on non Darwin platforms This will be required for #8189 ...

Enable SourceKit tests if building SourceKit by norio-nomura · Pull Request #8485 · apple/swift

Enable SourceKit's tests if building SourceKit Change packaging sourcekit-inproc from sourcekitdInProc.framework to libsourcekitdInProc.so on non Darwin platforms This will be required for #8189 ...

とりあえず、swift-DEVELOPMENT-SNAPSHOT-2017-05-09-a のLinux版に libsourcekitdInProc.so がもれなく入っていることを確認。

ネストした NSDictionary の比較がLinuxで正しく動いていないことを知って、ガッカリ

https://github.com/jpsim/SourceKitten/issues/384

compareJSONString does not detect changes on Linux · Issue #384 · jpsim/SourceKitten

It seems comparing nested NSDictionary on Linux does not working at all since Swift 3.0.2.

It works as expected on macOS: ➜ 18:33:37 git:(master) ✗ swift swift_oss_helper command enabled. Welcom...

マッジすか・・・

9:42 AM

DictionaryのEquatabilityが壊れてるってやばくない？？

やばいと思うけど、全体で等しい、っていうのは実際の利用シーンでは少ない気がする。

まあ実際やったことはほぼ記憶に無い・・・

多分テスト以外にお目にかからないかと。

9:45 AM

たまたまmacOSのコンパイラだけクラッシュするバグでLinux版が先行していたために気づいた。

元々はJSON文字列を作って比較してたのだけど、Linux版のJSONSerializationによるJSON文字列作成結果がnondeterministicだったため、オブジェクト化して比較したのがあだになった。

あ、それはキーバリューペアの出て来る順番が

9:56 AM

Dictionaryの内部メモリの都合でイテレーション順序が不安定そう

macOS版は毎回同じになったはず。

キーをソートせずに書き出しているなら、ハッシュテーブルだと capacity が異なると違う結果になりそうですね。

https://bugs.swift.org/browse/SR-4903

ううう、swift-corelibs-foundationのバグを次々に見つけてしまって、嫌になってきた…

swift-corelibs-foundation のテストがXcodeでうまくいかないのでLinuxでやってみてるのだけど、ci.swift.orgで通ってるテストも手元では通らず。なんだこれ。

Foundation.TimeZone が /usr/share/zoneinfo の存在に依存していて、ubuntu だとデフォルトで存在しない場合があるからだった。 https://bugs.swift.org/browse/SR-4921

ネストした NSDictionary の比較がLinuxで正しく動いていないことを知って、ガッカリ

正確には、NSArray に Hashable でない _ObjectBridgeable な要素が入ってる時の比較がおかしかった。

12:50 PM

ObjectIdentifier(でしたっけ？)周りの不具合かな

修正するPR https://github.com/apple/swift-corelibs-foundation/pull/990

[NSArray] Add check to isEqual(to:) whether values is _ObjectBridgeable by norio-nomura · Pull Request #990 · apple/swift-corelibs-foundation

Fixes SR-4903

なるほど、修正前はBridgeableなら無差別にtrueになり得たわけですね

です。要素数が同じなら isEqual(to:) が真になってました。

2

Swift 3.0リリース前のswift-DEVELOPMENT-SNAPSHOT-2016-08-18-aかららしい… (edited)

swift-corelibs-foundationには、macOSでそのAPIが何を返すか？とか調べずに実装されているAPIが少なからずあるぽい。

またいだテストケースが無いってことですか？

いちおう、swift-corelibs-foundationのテストをmacOSのFoundationで実行する様な設定は作り込まれているぽいけど、ci.swift.orgでテストされていない。

なるほど・・

CoreFoundationはオープンソースになってるけど、CoreFoundationを呼び出しているObjective-CランタイムがLinuxにはなくて、それに依存しているswift/stdlib/public/SDK/(Dispatch|Foundation)/NS*辺りはLinuxで使えない。 (edited)

7:23 AM

Objective-Cランタイムで実現してる機能も、SwiftからCoreFoundationを直接使ってDispatchやFoundationを実現するのがswift-corelibs-*。

7:23 AM

で、出来上がったDispatchやFoundationのAPIは、swift本体でテスト実行されるからまだいい。 (edited)

7:26 AM

Objective-Cランタイムの機能を真似するために、swift本体では使われていないObjective-Cを真似た機能を使おうとすると、それがテストされていないからmacOSの挙動と異なってたりする。 (edited)

Objective-CがCoreFoundationをどの様に使っているのかわからないApple社外のcontributor達は、自分たちが欲しいけど動かないAPIを最短で治そうとするので、Objective-Cランタイムの挙動とは違う内部実装を書いてしまう。

7:39 AM

それがCoreFoundationを無視した実装になっていたりするので、「実はこっちでも同じものが使われてる〜」というものがあったりすると、整合が取れなくなる。

7:40 AM

swift-corelibs-*プロジェクトにはフルタイムで見てるAppleの開発者がいないらしくて、その辺り見過ごされて実装されていってしまってるぽい。

ふむふむ。

もうここまで露出してるんだからObjective-Cランタイムも全部公開したらいいのにって思ってしまうんですがAppleは頑なに全部は見せない姿勢なんですね

swift-corelibs-foundationのコードが…

プロトコルエクステンションのinitでクラスのselfを置き換える手法を使うことで、swift-corelibs-foundationのNSNumberをCFNumberCreate()で作成する様に変更するPRを書いた。 https://github.com/apple/swift-corelibs-foundation/pull/1093 (edited)

Use CFNumberCreate() as factory initializer on NSNumber by norio-nomura · Pull Request #1093 · apple/swift-corelibs-foundation

This replaces #1025 by further utilizing the Factory Initializer Method (SR-5255). Use CFNumberCreate() as factory initializer on NSNumber Remove NSNumber._objCType Change the properties of NSNu...

^マージされた。そしてswift-corelibs-foundationはFactory initializerパターンを活用する方向へ進みそう。 https://github.com/apple/swift-corelibs-foundation/pull/1095

Generalize factory patterns for use outside of NSValue by phausler · Pull Request #1095 · apple/swift-corelibs-foundation

おお〜

11:26 PM

言語機能としてconvenience initで値の注入が許可されるようにならないかな

11:26 PM

protocol経由するのは大変

まじか。 https://bugs.swift.org/browse/SR-5255 の allocation/deallocation が一回余計に走るって問題は、修正期待って事なんですかねぇ。

あ、やっぱ走ってるのか

11:47 PM

でもalloc走らないようにするの厳しくないですか？フィールドへの代入が可能と言うことはallocしないことには

convenience init だからその先の self.init で alloc すればいいはず。

protocol extensionで書いてるからconvenienceが見えなくなってて

protocol extension init 内で self 代入前にプロパティセットできます？

お、self作れって怒られる

11:51 PM

じゃあ動きとしては全く同じなのか

現状実タイプの convenience init 前に alloc されていて

11:53 PM

その self が置き換えられちゃうから無駄になっているのです。

swift-corelibs-foundationにとっては、そのデメリットを大幅に超えるメリットがあると認識されつつある様です。

Linux上のlldbでpoとか使おうとすると

(lldb) po empty warning: Swift error in module YamsPackageTests.xctest. Debug info from this module will be unavailable in the debugger. error: in auto-import: failed to get module 'YamsTests' from AST context

みたいなエラーが出て使えなかったのだけど、 https://bugs.swift.org/browse/SR-5524?focusedCommentId=27038&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-27038 に書かれてるC_INCLUDE_PATHとCPLUS_INCLUDE_PATHを設定したら、使える様になった。

https://github.com/apple/swift/pull/11635 protocolによるhackファクトリパターンに手が入ってさらなるハックが必要になるというよくわからない展開に

(Not for checkin) Fix convenience init to protocol extension init delegation by slavapestov · Pull Request #11635 · apple/swift

Consider a class initializer that delegates to a protocol extension initializer, for example protocol P {} extension P { init() { ... } } class C : P { convenience init(foo: Int) { self.init()...

これはどうなんだ

8:35 AM

unsafeBitCast入れればokってことかな？

そうみたいですね。

8:40 AM

protocol 内 init での Self の意味がちょっと変わったという理解。

SelfがGenericsな型として扱われますよということかな？

8:42 AM

今までだと基底クラスの扱いでかつ、コンパイルもチェックせずに通っていた…？

しばらく潜って考えて整理してみた。 slavaが指摘しているバグこの gist と合わせて解説 https://gist.github.com/omochi/ac7bfec6f0b3f92b74502bbfaf0563a7 あるクラスがが convenience init から、別の init メソッドを呼んでいるときは、静的な Selfではなく、 convenience init 実行中の動的な Self とともに呼ばねばならない。例えば、Animal.init(init0:)はそのようなパターンで、Cat.init(init0:)を呼び出すと、 Animalのconvenience initから、オーバライドされたCat.init()が呼び出されることがわかる。 (edited)

swift-pr11635-bug.swift

12:06 PM

しかし、 protocol の extension メソッドで定義された init を呼び出している場合には、動的な Self ではなく、静的な Self に対して呼び出してしまうバグがあった。これを検証しているのが Animal.init(init1:) である。この中から呼ばれる self.init(facotry:) は、 Self が Animal に固定されて型検査されているし、コンパイル後もそのように動作する。その結果として、 Cat.init(init1:) の呼び出しは、 Cat の初期化をなんら呼び出していない。実際に cat1.b を表示してみると、謎の値65が表示された。 (at IBM Swift sandbox) 本来は、 protocol から来ていたとしても、 convenience init から init を呼び出すところは、動的な Self として扱わねばならない。

12:07 PM

このような「バグでコンパイルできてしまう」パターンは、既存の NSNumber 実装が踏み抜いている。 https://github.com/apple/swift-corelibs-foundation/blob/87466c45462cba5a085d5cd41d785d681016542d/Foundation/NSNumber.swift#L266 この行は、 NSNumber の親、 NSValue が conformance する protocol _Factory によって定義された init(factory:) を呼び出している。ここでは unsafeBitCast で NSNumber にキャストしているので、 init(factory:) に対しては、 () -> NSNumber なクロージャを渡している。

apple/swift-corelibs-foundation

swift-corelibs-foundation - The Foundation Project, providing core utilities, internationalization, and OS independence

12:07 PM

slava の修正によって、このような場合でも動的な Self として型検査されるようになった。そうすると、 gist の例の場合では、 init(factory:) に渡しているクロージャの式が、 () -> Animal であるゆえに、コンパイルエラーとなる。ここは、 self　の式の型は Animal ではなく Self なので、 () -> Self 型のクロージャを渡さねばならないからだ。

12:07 PM

同様のコンパイルエラーを、 NSNumber が実際に踏み抜いた。これを回避するために、 slava は3つの選択肢をだしている。 1. swift5までとりあえず放置する 2. NSNumberをfinalにする 3. ジェネリクスを使う 1は無いとして、2については、もしこの問題になっているクラス (AnimalやNSNumber) が final class であれば、 convenience init をサブクラスから呼ぶ事自体が無いので、解決するというもの。(修正した型チェッカはそれも考慮している)

12:08 PM

実際には、この選択肢は取れない。 NSDecimalNumber のような、 NSNumber のサブクラスがすでに存在しているから。 https://github.com/apple/swift-corelibs-foundation/blob/856b8bcd9cae659f1ca48545b2ddb7f63da77171/Foundation/NSDecimalNumber.swift しかもこいつは下記フィールドを保持している。 fileprivate let decimal: Decimal ということは、現状でも convenience init 経由の NSDecimalNumber のコンストラクトで、メモリがぶっ壊れる可能性がある・・・？

apple/swift-corelibs-foundation

swift-corelibs-foundation - The Foundation Project, providing core utilities, internationalization, and OS independence

12:08 PM

3の選択肢は、現状の unsafeBitCast にジェネリクスを組み合わせて、 NSNumber固定ではなく、 Self へのキャストにすることで動かす、というもの。 slavaの実装例は下記で、返り値型推論を活用している。 func castCFNumber<T>() -> T { return unsafeBitCast(cfnumber, to: T.self) } slavaはこれを試してみるとこのこと。

I'll try the generics hack.

12:08 PM

これでとりあえず動くようになるけど、 NSDecimalNumber の decimal プロパティが初期化されない可能性は解決しないのでは・・・？？？

ふむ

そもそもCFNumberのキャストしてるじてんで、DecimalNumberに対応は無理筋

なんか internal と private を駆使して、巧妙にユーザサイドでそのその穴は封印してる気もする。

DecimalNumberで@available生やすとかしないと無理では

12:20 PM

ふーむ

https://github.com/apple/swift-corelibs-foundation/blob/87466c45462cba5a085d5cd41d785d681016542d/Foundation/NSNumber.swift#L348

apple/swift-corelibs-foundation

swift-corelibs-foundation - The Foundation Project, providing core utilities, internationalization, and OS independence

12:20 PM

これだけ死ぬ気がする。

12:21 PM

NSDecimalNumber(value: true)

だよね

12:30 PM

Stringで同じ事したときに、あれはConcreteClassなので死屍累々になるかな？とか思ったけど

12:33 PM

NSNumberもなんか色々なかったっけ

このような「バグでコンパイルできてしまう」パターンは、 既存の NSNumber 実装が踏み抜いている。 https://github.com/apple/swift-corelibs-foundation/blob/87466c45462cba5a085d5cd41d785d681016542d/Foundation/NSNumber.swift#L266

僕のcommitですね

これを元にphauslerさんがFactoryパターンで大幅に書き換えてるPR https://github.com/apple/swift-corelibs-foundation/pull/1095 がしばらく前から止まってるけど、非公開なブランチがApple内部で進んでるのかな？

Generalize factory patterns for use outside of NSValue by phausler · Pull Request #1095 · apple/swift-corelibs-foundation

1:31 AM

これに期待 https://github.com/apple/swift/pull/11637#discussion_r135388024 I have a whole branch that refractors almost ALL of the classes that follow the self replacement pattern. (edited)

Fix convenience init to protocol extension init delegation by slavapestov · Pull Request #11637 · apple/swift

Consider a class initializer that delegates to a protocol extension initializer, for example protocol P {} extension P { init() { ... } } class C : P { convenience init(foo: Int) { self.init()...

NSDecimalNumber の decimal プロパティが初期化されない可能性は解決しないのでは・・・？？？

NSDecimalNumber は super.init() しか使ってないから問題ないと思う。

@norio_nomura さんのコミットだったんですねｗ

1:41 AM

 open override func description(withLocale locale: Locale?) -> String { guard locale == nil else { fatalError("Locale not supported: \(locale!)") } return self.decimal.description }

1:41 AM

↑これとか大丈夫ですかね？

NSDecimalNumber は super.init() しか使ってないから問題ないと思う。

NSNumberで定義されている public convenience init(value: Bool) は、 NSDecimalNumber に対しても呼び出せると思う。

ああ、そういう意味か。

↑を書いた時簡単に試せる Linux Swift環境が無かったので試せてないですが・・・

使えないぽい

$ docker run --privileged -it --rm norionomura/swift:4020170827a swift -I /usr/lib/swift/clang/include Welcome to Swift version 4.0-dev (LLVM 2dedb62a0b, Clang b9d76a314c, Swift 0899bd328a). Type :help for assistance. 1> import Foundation 2> let b = NSDecimalNumber(value: true) error: repl.swift:2:9: error: argument labels '(value:)' do not match any available overloads let b = NSDecimalNumber(value: true) ^ ~~~~~~~~~~~~~ repl.swift:2:9: note: overloads for 'NSDecimalNumber' exist with these partially matching parameter lists: (decimal: Decimal), (string: String?), (coder: NSCoder), (floatLiteral: Double), (booleanLiteral: Bool), (integerLiteral: Int) let b = NSDecimalNumber(value: true) ^ 3>

(edited)

お。あれ、なぜだろう。

1:56 AM

class Animal { init() { } convenience init(init0 int: Int) { self.init() } } class Cat : Animal { override init() { } convenience init(init1 int: Int) { self.init() } } // Animal の convenience init が呼び出せる Cat.init(init0: 3)

Swift 4.0スナップショットのdockerイメージあります。 https://hub.docker.com/r/norionomura/swift/

Docker for macでやってみたらimport Foundationでエラーが出てしまいました

swift -I /usr/lib/swift/clang/include で。

おおいけました　norioさんの↑のコマンドラインをまるまるコピペすればよかったのか。

known issueです。 https://bugs.swift.org/browse/SR-3794

convenience init 通らないですね

publicだからかな？

[omochi@omochi-iMac temp]$ docker run --privileged -it --rm norionomura/swift:4020170827a swift -I /usr/lib/swift/clang/include Welcome to Swift version 4.0-dev (LLVM 2dedb62a0b, Clang b9d76a314c, Swift 0899bd328a). Type :help for assistance. 1> public class Animal 2. { 3. public init() {} 4. public convenience init(init0 int: Int) { self.init() } 5. } 6> public class Cat : Animal { 7. public override init() {} 8. } 9> Cat.init(init0: 33) $R0: Cat = { __lldb_expr_1.Animal = {} }

2:15 AM

required convenience init が混ざってると変わるのかな

2:15 AM

うーんいけるなあ

2:15 AM

なんだこれ・・・

REPL内は同じモジュールでは?

あー　別モジュールでってことですか

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AccessControl.html#//apple_ref/doc/uid/TP40014097-CH41-ID3

Open access applies only to classes and class members, and it differs from public access as follows: - Classes with public access, or any more restrictive access level, can be subclassed only within the module where they’re defined. - Class members with public access, or any more restrictive access level, can be overridden by subclasses only within the module where they’re defined. - Open classes can be subclassed within the module where they’re defined, and within any module that imports the module where they’re defined. - Open class members can be overridden by subclasses within the module where they’re defined, and within any module that imports the module where they’re defined.

(edited)

2:23 AM

サブクラスのメンバーとして使えるかどうか？の制限ってあるんだっけ？よくわからない…

2:24 AM

こっちか https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/access-level-modifier

### public Apply this modifier to a declaration to indicate the declaration can be accessed and subclassed by code in the same module as the declaration. Declarations marked with the public access-level modifier can also be accessed (but not subclassed) by code in a module that imports the module that contains that declaration.

(edited)

手元のプロジェクトでモジュール分割されてるのでopen絡めて試してみたけどやっぱり呼び出せますねえ

2:30 AM

openは別モジュールで継承可能な点以外publicと同じで、publicは別モジュールから使用可能の意味なので、見えなくなるのが謎・・・

呼び出せますね。なんだこれ…

再現できた。

open class NSValue2 {} protocol Factory {} extension Factory { init(factory: () -> Self) { self = factory() } } extension NSValue2: Factory {} open class NSNumber2: NSValue2 { private override init() {} private convenience init(private: Int) { self.init(factory: { NSNumber2() }) } public convenience init(init0: Int) { self.init(private: init0) } } open class NSDecimalNumber2: NSNumber2 {}

これでモジュール外の NSDecimalNumber2(init0:0) がビルドエラー error: 'NSDecimalNumber2' cannot be constructed because it has no accessible initializers になる。

3:15 AM

ああ、これ違う…

NSDEcimalNumber2に override init が必要なはず

今度こそ再現できたと思う。

import Foundation internal protocol _Factory { init(factory: () -> Self) } extension _Factory { init(factory: () -> Self) { self = factory() } } open class NSValue2: _Factory { internal init() {} } open class NSNumber2: NSValue2 { internal override init() { super.init() } public convenience init(value: Bool) { self.init(factory: { NSNumber2() }) } } open class NSDecimalNumber2: NSNumber2 { // override init() { super.init() } // この行を復元するとビルドが通る。 public init(decimal dcm: Decimal) { super.init() } }

これでモジュール外の NSDecimalNumber2(value: true) がビルドエラー error: incorrect argument label in call (have 'value:', expected 'decimal:') になる。 (edited)

おお　こちらでも再現しました

3:54 AM

どういうルールなのか弄って検証中

NSDecimalNumber2にoverride init() { super.init() }を足すと通る様になる。

Rule 1 If your subclass doesn’t define any designated initializers, it automatically inherits all of its superclass designated initializers. Rule 2 If your subclass provides an implementation of all of its superclass designated initializers—either by inheriting them as per rule 1, or by providing a custom implementation as part of its definition—then it automatically inherits all of the superclass convenience initializers.

open class NSNumber2 { public init() { } public convenience init(value: Bool) { self.init() } } open class NSDecimalNumber2: NSNumber2 { // A // public override init() {} // B public init(decimal dcm: Decimal) { super.init() } }

3:59 AM

これだけで現象のオンオフできた

Rule 2 の「superclassのすべてのdesignated initialzerを実装していれば、 superclass のすべてのconvenience initalizer が継承される」

2

あ、 @rintaro 先生・・・

これか https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Initialization.html#//apple_ref/doc/uid/TP40014097-CH18-ID222

4:01 AM

知らなんだ…

ややこしいンゴ

拝んでおこう

つまり、サブクラスで親のdesignated initializerを全部overrideしてない場合なので、 Rule1にもRule2にも合致しないため、 convenience initializerの継承がされない

4:03 AM

ということか。

swift-4.1-DEVELOPMENT-SNAPSHOT-2017-10-25-a を試したら、REPL起動時に-I/usr/lib/swift/clang/includeを渡さなくてもimport Foundationでエラーにならなくなってた

(edited)

REPLで面倒なコマンド打たなくても良いんですね

swift-corelibs-foundationのバグを追って原因がCoreFoundationにあると知り、元となってるCoreFoundationのソースがOS X 10.10.5で公開されたモノらしいと知り、さらにソース非公開の最新のCoreFoundationだと修正されているぽい事を知ると、PR投げる気が失せる…

Appleの内部で CoreFoundation 直すときに、同じ問題って OSS の方にも無いのかな？って見てほしいですね

こういう感じで、最新のCoreFoundationの反映自体はされてますね（少なくとも昨年のSierraでは） https://github.com/apple/swift-corelibs-foundation/pull/709

Import CoreFoundation changes from Sierra by phausler · Pull Request #709 · apple/swift-corelibs-foundation

なるほど、じゃあ、たまたまこういうプロセスから漏れちゃっただけですか

まだ時期的に公開されてなくて、反映も追いついてないだけな気がします。昨年のPRは12月だし。

あー　漏れてるんじゃなくてまだ来てないという意味か。

できたらCoreFoundation単体のリポジトリで公開して欲しいところ。

確かに単体で公開される方がいいですね

CoreFoundationの更新きた https://github.com/apple/swift-corelibs-foundation/pull/1305

Import CoreFoundation sources from High Sierra by phausler · Pull Request #1305 · apple/swift-corelibs-foundation

This is the latest changes from CoreFoundation, round tripped to include the latest additions in High Sierra. Careful review should be taken for non x86_64 linux platforms since we have not yet tes...

やっぱり実際の挙動と公開されてるコードは違うな。

AppleのICUとLinuxで使われているICUの挙動が違うのが原因だろう、と教えてもらった。 https://opensource.apple.com/source/ICU/ICU-59117.0.1/

12:54 AM

根本的な解決には、swift-corelibs-foundationでもAppleが公開しているICUを使う事が必要だけど、影響範囲が広くて簡単にはいかなそう。

 func testNSStringPath1() throws { let actual = NSString(string: "").appendingPathComponent("*.txt") let expected = "*.txt" XCTAssertEqual(actual, expected) }

5:40 AM

MacOSXなら↑が通るけど Linux だとコケる。 /*.txt になってしまう。

5:46 AM

どこかに報告するべきですかね？

たぶんこれかな https://github.com/apple/swift-corelibs-foundation/pull/1294

[SR-5582] Changed NSString.appendingPathComponent implementation on Lin… by ogres · Pull Request #1294 · apple/swift-corelibs-foundation

Resolves SR-5582 Changed NSString.appendingPathComponent implementation on Linux to match Darwin's Fixed following issues where path.appendingPathComponent(component) would produce incorrect result...

おお！！

6:03 AM

もうマージ済みだ　じゃあ使ってるやつが新しくなれば解決だ。ありがとうございます。

うおお・・・

6:44 AM

同じSwiftバージョンなのに

6:44 AM

手元のDockerとTravisCI の Ubuntu で挙動が違う・・・・・

6:46 AM

DockerはUbuntu16.04だからそこか

docker良い・・・

docker上でubuntu14.04環境で検証したけどテストが通った

7:47 AM

TravisCI上のubuntu14.04の固有の何かがある・・・

あれ〜なんだこれ・・・

8:01 AM

TestResources └── globstar ├── a │ ├── b │ │ ├── c │ │ │ ├── d0.txt │ │ │ └── d1.md │ │ ├── c0.txt │ │ └── c1.md │ ├── b0.txt │ └── b1.md ├── a0.txt └── a1.md

substSubpathStrs = try fm.subpathsOfDirectory(atPath: path) dump(substSubpathStrs)

8:02 AM

Test Case 'GlobTest.testExpandGlobStar1' started at 2017-11-11 07:57:51.502 ▿ 3 elements - "a" - "a0.txt" - "a1.md"

8:02 AM

subpathsOfDirectoryが仕事してない・・・

8:03 AM

$ swift --version が同じならこの手の挙動は同じですよね？

Foundationの中身のコードをコピペしてダンプして調べた

8:51 AM

[subpathsOfDirectoryCompat(/home/travis/build/omochi/gysb/TestResources/globstar)] enter [subpathsOfDirectoryCompat(/home/travis/build/omochi/gysb/TestResources/globstar)] entryName=. [subpathsOfDirectoryCompat(/home/travis/build/omochi/gysb/TestResources/globstar)] entryName=.. [subpathsOfDirectoryCompat(/home/travis/build/omochi/gysb/TestResources/globstar)] entryName=a [subpathsOfDirectoryCompat(/home/travis/build/omochi/gysb/TestResources/globstar)] entryType=0 (DT_DIR=4) [subpathsOfDirectoryCompat(/home/travis/build/omochi/gysb/TestResources/globstar)] entryName=a0.txt [subpathsOfDirectoryCompat(/home/travis/build/omochi/gysb/TestResources/globstar)] entryType=0 (DT_DIR=4) [subpathsOfDirectoryCompat(/home/travis/build/omochi/gysb/TestResources/globstar)] entryName=a1.md [subpathsOfDirectoryCompat(/home/travis/build/omochi/gysb/TestResources/globstar)] entryType=0 (DT_DIR=4) [subpathsOfDirectoryCompat(/home/travis/build/omochi/gysb/TestResources/globstar)] exit

8:52 AM

 if tempEntryType == Int32(DT_DIR) { let subPath: String = path + "/" + entryName let entries = try subpathsOfDirectory(atPath: subPath) contents.append(contentsOf: entries.map({file in "\(entryName)/\(file)"})) }

8:52 AM

↑ dirent 構造体の d_type フィールドを見て、それが DT_DIR だったらサブディレクトリとして再帰的に呼び出すようになっているけど

8:53 AM

TravisCI 上の Ubuntu上だと d_type がディレクトリでも 0になっている事がわかった。

8:53 AM

travisの実行が container mode だからなんかおかしそう。

d_typeがサポートされてないファイルシステムもあるみたいで https://linuxjm.osdn.jp/html/LDP_man-pages/man3/readdir.3.html

なんだと！！！！！

https://docs.travis-ci.com/user/reference/overview/

マジカ、travisの環境が壊れてると考えたけど、じゃあそれに頼ってしまったFoundationの実装が悪いと言えるのでは・・・

Ubuntu Trustyのcontainer basedのfile systemはAUFSでサポート外、という感じ？

ちなみにfileExeits(isDirectory)の方のディレクトリチェックを見てみたら、そっちはstatで実現されてた。

9:01 AM

あーなるほど。

sudo: requiredにしてみると違いが分かりそう

そうですね、いまからやってみます

9:02 AM

AUFSとやらがキモか・・・

9:03 AM

dirent 構造体のフィールドで POSIX.1 で要求されているのは、 d_name[] と (XSI 拡張での) d_ino だけである。

9:03 AM

なるほどなあ。

9:05 AM

期待通りに動いた > sudo: required

9:06 AM

ありがとうございました〜

9:06 AM

あきらめてsudo required環境でテストするか、

9:06 AM

自前実装で動くようにするか・・・

9:07 AM

あとFoundationプロジェクト側にこの件は伝えたほうが良いんだろうか？

なるほどなー、まあcorelibs-foundationの実装がよくなさそう

報告はFoundationのMLでいいんでしょうか

9:10 AM

How do I contribute? We welcome contributions to Foundation! Please see the known issues page if you are looking for an area where we need help. We are also standing by on the mailing lists to answer questions about what is most important to do and what we will accept into the project.

enumerator(atPath:)とかはどうだろう

9:11 AM

bugs.swift.orgに起票でもよさそう？

bugsってOSS のFoundationもいいんですっけ

はい、corelibsも対象です。

なるほど、じゃあそうします。

さっきのappendingPathComponentのもSRついてたし

たしかに、もうあるかもしれないですね

9:14 AM

ああ、そういう意味化

9:14 AM

起票があるからSR番号なのか。

9:17 AM

enumeratorの方は fts ってAPIで実装されているみたい

9:17 AM

fts_read

9:17 AM

https://linuxjm.osdn.jp/html/LDP_man-pages/man3/fts.3.html

9:17 AM

使ったことなかった。

9:17 AM

これは動きそうですね。差し替えてみます。

9:22 AM

NSEnumeratorを継承している関係で型が func nextObject() -> Any? なのが気持ち悪くて使ってなかったんですが

9:23 AM

こっちのほうが良さそうだ。

9:28 AM

enumeratorにしたら期待通りに動きました〜〜ありがとうございます

1

https://github.com/omochi/gysb バッジがついた〜

omochi/gysb

gysb - Generate your swifty boilerplate

CircleCIオススメ

TravisはSwiftで必要なパッケージで、入っていないものがあった気がする。

10:34 AM

libblocksruntime0 が入ってない。

ふむ

あいや、sourcekitが必要とするだけで普通は関係なかった。

linuxをサポートしてるネットワーク通信ライブラリって何かご存知ですか？

サーバーサイドSwiftフレームワークが使っているやつで良いかなと思って、僕はVaporの使ってます。

お、Vapor

9:03 AM

に入ってるんですね　気づかなかったです

vaporの中にめっちゃいろいろ入ってるよ

https://docs.vapor.codes/2.0/http/client/

オーーーーー

9:04 AM

ほしかったものだ。

multipartとかも対応

vaporは使ったこと無いけどvaporの中にいろいろはいってるのは前みたｗ

いまVaporでVapor Cloudで動かすサービス作っていて何も考えずにクライアントのコード引っ張ってきてAPIKit使ってたけどMacでビルド通ってたけどデプロイしたらコケて悲しんでいました

個人的にはHTTP/2非対応なのがマイナス点ですが、あと数ヶ月くらいでリリースされそうなVapor 3で対応しそうです。 https://github.com/vapor/vapor/pull/1188 (edited)

HTTP2 and gzip by Joannis · Pull Request #1188 · vapor/vapor

This PR will focus on HTTP2 and Gzip. The reason this is bundled is because HTTP2 relies on Huffman trees, which are are one of the primary components of Gzip. Gzip will not implement a good algori...

なんとかこれをSwift 3.0までサポートする手段ないかな…… https://github.com/Quick/Nimble/pull/483

Work around SR-6419 by ikesyo · Pull Request #483 · Quick/Nimble

https://bugs.swift.org/browse/SR-6419 Should fix #481.

1:15 PM

https://twitter.com/ikesyo/status/931510429100077056

いけしょー (@ikesyo)

https://t.co/SbLvT41AjN と https://t.co/02nBsD8sva とSwift 3.0サポートの3つが絡み合って詰んでる……というのもif swift(>=4.0.2)というパッチバージョン（3桁目）まで含んだチェックがSwift 3.1からしかサポートされていない。

なんだこりゃｗｗｗ

めっちゃ厳しい……Swift 3.0をドロップするしかない気はしている。

方法はあるのですが、今外なので戻って確認してから書きます。

https://bugs.swift.org/browse/SR-4032 により、 swift(>=) による検査は演算子が使えません。

2:03 PM

なので、 #if swift(>=4.0) #elseif swift(>=3.2) #else #endif みたいにするしかないと思います。

2:06 PM

そうすれば、 #else ブロック以外は Swift3.0 ではパースされないので、その中であれば swift(>=4.0.2) など使えると思います。

あーなるほど！そこで引っかかってパースされていたのか。ありがとうございます！試してみます。

SR-6419 の話で、どうしてもtrailing closure使いたければ、 self.token = self.notificationCenter.addObserver(forName:object:queue:using:)(nil, nil, nil) { ... } っていう手もあり。

なるほど。

2:21 PM

無事Swift 3.0で動きました

https://travis-ci.org/Quick/Nimble/jobs/303553458

1

2:21 PM

ありがとうございます!!

ひどいソースになっちゃってるｗ

#if swift(>=4.0) #if swift(>=4.0.2) #else extension NotificationCenter { func addObserver(forName name: NSNotification.Name?, object obj: Any?, queue: OperationQueue?, using block: @escaping (Notification) -> Void) -> NSObjectProtocol { ... } } #endif #endif

みたいにメソッド生やすともうちょっとマシにできそうな気がしてきましたw (edited)

マシになった https://github.com/Quick/Nimble/pull/483/commits/a62e07e94fc8fd1fabce89d71bc93d4b57edba4d

Work around SR-6419 by ikesyo · Pull Request #483 · Quick/Nimble

https://bugs.swift.org/browse/SR-6419 Should fix #481.

1

Xcode 8サポート継続か、頑張るなあ。

切るにはメジャーバージョン上げたいところで、とはいえこの修正は7.0.3として出したいと思ったのでした。

import Dispatch func fib(_ i: Int) -> Int { switch i { case 0, 1: return 1 default: return fib(i-1) + fib(i-2) } } DispatchQueue.concurrentPerform(iterations: 30) { i in fib(i) }

これ実行したら確率的に死んでしまう…… swift-DEVELOPMENT-SNAPSHOT-2018-01-29-a-ubuntu16.04にて

8:34 AM

bugs.swift.org見てるけど同じのは無さそう？

30 が 20 なら死なない？

2とかだと死なないですねぇ

print(i) だと？

コア数絡んでそう

単に Linux の Dispatch のバグかもしれないけど

_ = iでやってみましたけど死亡

8:42 AM

WSLなので一般的じゃないかもと思い社内Ubuntuにssh叩くも繋がらず

あー、いや、大丈夫か。 2^30 に分岐したら（実際には -2 もあるからもっと少ないけど）ヤバそうと思ったけど、そこは並行じゃないから大丈夫だった。

LinuxのDispatchのバグっぽいね

ああfib起因のバグの可能性ですか。それは考えてなかった

8:44 AM

とりあえずそれは無さそうですね

import Foundation import Dispatch for i in 0..<30 { DispatchQueue.global().async { print(i) sleep(1) _ = i } } sleep(10) (edited)

8:58 AM

これも同上

9:01 AM

printは一個も出ずに死にますね。さらにsleepを入れることで死亡率100%に

9:06 AM

DispatchQueueを個別に生成した場合死なないのでconcurrent queueの問題みたいです

手元ではどっちも再現しないな。

https://github.com/apple/swift-corelibs-libdispatch/blob/f3531a246c97df84c769df06c990b95368ee2e79/src/queue.c#L508

apple/swift-corelibs-libdispatch

swift-corelibs-libdispatch - The libdispatch Project, (a.k.a. Grand Central Dispatch), for concurrency on multicore hardware

再現しないとなるとWSLの可能性が

Windows Subsystem for Linux　固有の問題な気がするね

windows機二台で試して同じ結果なのでubuntuで再現しないならそうなりそうです

Dockerで。 docker run --privileged -it --rm norionomura/swift:swift-4.1-branch swift -I/usr/lib/swift/clang/include

9:11 AM

norionomura/swift:swift-4.1-branchが最新のスナップショット。

まずdockerをインストールせねば。

なんかウェブでインストーラ落とすだけだから簡単だよ

9:13 AM

その後何も考えずに ↑のコマンド叩けばシェルに入れる (edited)

9:14 AM

https://hub.docker.com/r/norionomura/swift/

9:14 AM

↑これ

ああ、たんにwindowsにはいってなくて時間かかるってだけです。

9:14 AM

インストール爆速でした

windows上のdocker上のubuntuと mac上のdocker上のubuntuはまた挙動が違う可能性があるのでは

9:14 AM

norioさんが言ってるのはmac上だと思う。

そっちも並行してやってます

なる

CircleCIがdockerを使うと楽なので、linuxのCIは全部docker

9:17 AM

macとWindowsのdockerでどんな違いがあるのかは知らないです。

9:19 AM

WSLはVMではないぽい？

VMでは無いという認識

9:20 AM

Dockerに似てて、システムコールのレイヤでWindowsカーネルが意味変換の面倒を見てる

9:21 AM

WSLはマイクロソフトが開発した（Linuxカーネルのコードが含まれていない）Linux互換のカーネルインタフェースとともに、その上で動くUbuntuに由来するユーザーモードバイナリを提供する。これはBashシェルやコマンド言語、ネイティブLinuxコマンドラインツール（sed、awkなど）やプログラミング言語インタプリタ（Ruby、Pythonなど）[5]を含む[6]。

https://ja.wikipedia.org/wiki/Windows_Subsystem_for_Linux

Windows Subsystem for Linux

Windows Subsystem for Linux (WSL) とは、Linuxの（ELFフォーマット形式の）バイナリ実行ファイルをWindows 10およびWindows Server上でネイティブ実行するための互換レイヤーである。

9:21 AM

Linux互換カーネルインターフェースであって、Linuxカーネルそれ自体はブートしてない

なるほど。dockerの方がまともそう。

win/macともにdocker上では問題ないですね

1

windowsで動かす話がでた当初にdockerとwsl比較してwslのほうが良さそうってなったんですけどね。とりあえず並列化がどうしても必要な段階ではないので保留にしておきます。ありがとうございました。

/usr/libに置かれたライブラリ、swiftcだとリンクされるけど、REPLだとerror: Couldn't lookup symbols:になってしまう。

4:11 AM

swift -I/usr/lib/swift/clang/include -L /usr/libで起動したREPLだとエラーにならないので、REPLはldとは違う仕組みでライブラリを検索するぽい？

REPLで:type lookupだと型の情報が出るのに、使おうとするとunresolved identifierになる

$ docker run --privileged -it --rm norionomura/swift:40 swift -I/usr/lib/swift/clang/include Welcome to Swift version 4.0 (swift-4.0-RELEASE). Type :help for assistance. 1> import Foundation 2> :type lookup DBL_DECIMAL_DIG var DBL_DECIMAL_DIG: Swift.Int32 { get {} } 2> print(DBL_DECIMAL_DIG) error: repl.swift:2:7: error: use of unresolved identifier 'DBL_DECIMAL_DIG' print(DBL_DECIMAL_DIG) ^~~~~~~~~~~~~~~

(edited)

ci.swift.org で使ってるclangとllvmは5.0なのか。llvm-symbolizerにもオプションが増えてるなあ。 (edited)

Illegal instructionで落ちた時に、backtraceが出ない条件って何が考えられるでしょうか？

Linux向けのバックトレース用パッケージを作りました。 https://github.com/norio-nomura/SwiftBacktrace

norio-nomura/SwiftBacktrace

SwiftBacktrace - Stack traces for Swift on Mac and Linux using libunwind.

7:54 AM

Darwinのバックトレースと同様にクロージャとかまで表示してくれます。

1

7:54 AM

リリースビルドでもOK。

7:56 AM

macOSではバックトレースの取得に https://github.com/llvm-mirror/libunwind が使われています。

llvm-mirror/libunwind

Mirror of official LLVM libunwind git repository located at http://llvm.org/git/libunwind. Updated every five minutes. http://llvm.org

7:57 AM

それの移植元になった https://github.com/libunwind/libunwind/ を利用するパッケージになっています。

libunwind/libunwind

libunwind official github repo

8:03 AM

いちおう、macOSでも動いて、標準のバックトレース(SwiftだとThread.callStackSymbols)とほぼ同じ出力が得られます。

これでSwiftCompilerDiscordappBotのクラッシュ原因を突き止めたい…

クラッシュするケースがあるんですか？

HerokuのログにState changed from up to crashedってのが時々出てくるのですが、何がトリガーなのかさっぱりわかっていないのです。

8:29 AM

ボットに対する指示ではクラッシュしないので、Discordから送られてくる何かのイベントがトリガーだと一応予想しています。

なるほど。受け取ったSwiftのコードが原因ではなさそう、ということですね。

ProcessのstandardInputにパイプのFileHandleを渡してパイプへデータを書き込んでも、Linuxだと起動したプロセスが標準入力を読んでくれない現象に悩んでたのだけど、launch()の前にパイプへデータを書き込んでおく事で読んでくれる様になった。

2:26 AM

macOSだとlaunch()後にパイプへ書き込んでも問題ない。 (edited)

Process.waitUntilExit()がスレッドセーフではないため、Process.terminationStatusがおかしくなる。 @swift-4.2.4

import Foundation let process = Process() process.launchPath = "/bin/false" let group = DispatchGroup(), queue = DispatchQueue.global() process.launch() queue.async(group: group) { process.waitUntilExit() } group.wait() print("terminationStatus should be 1, actual: \(process.terminationStatus)")

(edited)

terminationStatus should be 1, actual: 0 (edited)

terminationHandlerの方がいいのかな？リファレンス見る限りではwaitUntilExit()とは別々に動いてるみたい。 @swift-4.2.4

import Foundation let process = Process() process.launchPath = "/bin/false" let semaphore = DispatchSemaphore(value: 0) process.terminationHandler = { _ in semaphore.signal() } let queue = DispatchQueue.global() process.launch() queue.async { process.waitUntilExit() } print("terminationStatus should be 1, actual: \(process.terminationStatus)") semaphore.wait() print("terminationStatus should be 1, actual: \(process.terminationStatus)")

(edited)

terminationStatus should be 1, actual: 0 terminationStatus should be 1, actual: 1 (edited)

ああ、確かにterminationHandlerを使った方が良さそう。 https://github.com/apple/swift-corelibs-foundation/blob/swift-4.2-branch/Foundation/Process.swift#L341

apple/swift-corelibs-foundation

swift-corelibs-foundation - The Foundation Project, providing core utilities, internationalization, and OS independence

あいや、同じスレッドで使えばwaitUntilExit()でも問題ないしその場合のオーバーヘッドもwaitUntilExit()の方が少ないかな。

swift-4.2-DEVELOPMENT-SNAPSHOT-2018-08-06-aを使ったubuntu 16.04のdockerイメージ作成が失敗する様になった。

Step 7/7 : RUN swift --version ---> Running in bb3dce9f40cc swift: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by swift)

(edited)

3:54 AM

GLIBCXX_3.4.22を含むlibstdc++.so.6はubuntu 16.04のパッケージとしては未リリースぽい。

https://bugs.swift.org/browse/SR-8477

swift-4.2-DEVELOPMENT-SNAPSHOT-2018-08-07-aで直ってた。

https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/Thread.swift#L156-L157

apple/swift-corelibs-foundation

The Foundation Project, providing core utilities, internationalization, and OS independence - apple/swift-corelibs-foundation

2:09 AM

 /// - Note: this differs from the Darwin implementation in that the keys must be Strings open var threadDictionary = [String : Any]()

(edited)

2:09 AM

これ困るんですけど

2:10 AM

どこに連絡するのが良いでしょう？

2:10 AM

bugs.swift.org ?

2:10 AM

なぜ困るかと言うと、 Thread.current.threadDictionary を Thread Local Storage として使おうとしたときに

2:10 AM

String だと衝突回避が困難だからです

2:11 AM

MacOS版ならNSMutableDictionaryなのでObjectIdentifierとかUnsafeRawPointerをキーにすればまずぶつかる事は無い

@omochimetaru ObjectIdentifier の debugDescription をキーにするとか？

"ObjectIdentifier(3001238)" みたいな？

うん

まあ確かに悪意が無ければ衝突することは無いですね・・・

2:17 AM

それでも8バイト整数であるポインタと違って文字列の長さだけ比較しないといけないので

2:18 AM

無駄なパフォーマンスロスがありそうで微妙な気分です。

パフォーマンスは悪いだろうね。

NSMutableDictionary だと何がまずいんだろう？

たしかに、パッチとしては普通にここの型をNSMutableDictionaryにしてくれたら、それで僕は満足・・・

2:26 AM

コメントでわざわざnote 書くなら理由も書いといてほしいな。 (edited)

2:27 AM

とりあえずLinux向けの分岐では @koher 案で対応しときます

2:33 AM

bugsにFoundationに関する話も投稿されてるから、ここでいいか。

あ、corelibs 系のバグ報告は bugs でいいです。

2:34 AM

NSMutableDictionary に変更PRしちゃっても良いと思いますけどね。

ふむ。PRついでにお気持ちと質問を書けばいいですかね？ (edited)

良いと思います。Dictionary じゃなければいけない理由が本当にあるなら、 [AnyHashable: Any] ではだめなのかとか聞いてみると良いと思います。 (edited)

じゃあそうします、最近ビルドしてなかったから、後でやろう。ありがとうございます。

https://twitter.com/omochimetaru/status/1062380664903761921

おもちメタル (@omochimetaru)

OSS FoundationにPRだした https://t.co/0bTE9hI4XF

2

@omochimetaru 質問来てるよ。

気づいてます、対応中です

DockerでSwiftのコンパイルしようとしたらメモリ不足でリンカーが死んだｗ 2G じゃたりないらしい。

それが原因でswift-nightlyが更新できてません。

ほう。こちらはとりあえず8Gにしてリトライ中ですが、クラウドだから増やすのが面倒ってことですか？

CircleCIでビルドが通らないので。多分Herokuでのビルドも通らないんじゃないかな。

なるほど・・・

3:08 AM

https://circleci.com/pricing/

Pricing and Plan Information

Save time and cost by making your engineering team more efficient. Get started for free and see how many containers and parallelism you need to scale with your team.

3:08 AM

課金してもメモリサイズは上がらない・・・？

あ、SwiftのToolchainか。

3:17 AM

だとしたら違う原因なのかも。

3:18 AM

スタックトレースも吐かないでクラッシュするので、メモリ不足だろうと考えてました。

[954/1340] Linking CXX executable bin/clang-check ... clang: error: unable to execute command: Killed clang: error: linker command failed due to signal (use -v to see invocation)

3:19 AM

8Gでやってもだめだった

3:22 AM

てか、ボリュームマウントに問題があるのか、コンテナをstop/startするとビルドキャッシュが効かない・・・

こちらでうまくいかない時と同じ様なエラーメッセージですね。

同じか・・・なんだろう

ちなみにCircleCIへsshで入ってリビルドすると通ったりするので、リビルドされるソースが少ないと通る可能性がありそう。

今そのままリトライして、そしたらこのリンクフェーズだけ再開したけど、だめでした

3:27 AM

うーんこまったな・・・

ああ、foundationへのPRのCIか。

今はFoundationのテストをしたいだけだから、Swiftコンパイラ自体はダウンロードしてくる方向でやってみるか

3:29 AM

はい、Linuxで落ちてて

3:30 AM

https://github.com/apple/swift-corelibs-xctest/blob/master/Sources/XCTest/Private/WaiterManager.swift#L41

apple/swift-corelibs-xctest

The XCTest Project, A Swift core library for providing unit test support - apple/swift-corelibs-xctest

3:30 AM

CIのエラーログから見ると、多分ここで落ちてるんですけど、再現までが遠いｗ

これは辛いな。

cmake -G Ninja ../../../swift-corelibs-foundation \ -DCMAKE_C_COMPILER=../../llvm-linux-x86_64/bin/clang \ -DCMAKE_SWIFT_COMPILER=../../swift-linux-x86_64/bin/swiftc \ -DFOUNDATION_PATH_TO_LIBDISPATCH_SOURCE=../../../swift-corelibs-libdispatch \ -DFOUNDATION_PATH_TO_LIBDISPATCH_BUILD=../../libdispatch-linux-x86_64

5:21 AM

@norio_nomura 配布している nomuranorio/swift って、ビルドディレクトリは含まれてますか？

5:22 AM

libDispatchのビルドディレクトリが必要らしく。

含まれてないです。

なるほど

5:23 AM

とりあえず古いコミットでリビルドしてみるか・・・

1101でもビルドできんかった

10:07 AM

Dockerだから起きてる問題だったりするのかなあ・・・

SwiftBotで使ってるDigitalOceanのマシンでビルドできるかやってみましょうか？ Dockerじゃなくて普通のUbuntuなので。

10:10 AM

うちに帰ってからになりますけど。

おお、お願いしますビルドできる環境がわかれば手が進められるので、助かります

単純にSwiftのmasterをビルドしたらいいんですか？

masterが時間差で壊れるとアレなので、できれば公式CIが成功してるsnapshotだと嬉しいですコマンドラインを後で貼りますねいま移動中のため

私もやるのは早くて23時くらいからなのでゆっくりで。

1

↓これでお願いします https://gist.github.com/omochi/4ee26ed34d128073cabdac954df4ddff

foundation-linux-1114.bash

GitHub Gist: instantly share code, notes, and snippets.

https://github.com/apple/sourcekit-lsp/pull/1 何かは知らないのですが11-13は問題あるので試すなら11-01がいいと思います。

The latest toolchain has some issues on Linux (and on macOS we need an update to match it). Update the instructions in the meantime.

2018-10-03より後のスナップショットはいろいろ問題があって、swift-nightlyボットは更新されてない。

ふむ、ありがとうございます。手順書を11-01に変更しておきました (edited)

とりあえずビルド始めました。メモリ1GBディスク25GBの貧弱マシンでメモリは初めから60%消費してる状態だけど別にそこから増えることもなくビルド進んでますね。

1

2:00 PM

あ、メモリよりCPUが先に悲鳴をあげてるっぽい。

以前AWSのT2 microでやったときは、一瞬でCPUブーストチケット？がなくなりました (edited)

まあめっちゃ遅いけど進んではいますね。。。 [250/3012] Building CXX object

確かその分数はLLVM(Clang)のときとSwiftCompilerのときで別々に出てくるんですが、僕が止まったのがLLVMのほうの残り350タスクぐらいのところの終盤で生じるバイナリのリンクフェーズなので

2:27 PM

2700/3012ぐらいまではとりあえずいけると思います、気になるのはそこから先ですね

なるほど。じゃあこのまま放置で明朝ですね。

課金がヤバそうだったら止めていただいて大丈夫です

DigitalOceanはスペックが変わらなければ（めっちゃ転送量が多いとかでない限り）一定です。

おおなるほど。

一定というか、従量課金ではあるんですけど、それは最初に決まっていて、今使ってる最低スペックのマシンでは動かし続けたとして5$/mo

2:30 PM

どうせswiftbotとかのWebでずっと動いてるやつなんで

ありがたい

+ /usr/bin/cmake --build /home/katsumi/work/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64 -- -j1 all [59/1905] Building CXX object lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86ISelLowering.cpp.o FAILED: /usr/bin/clang++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Target/X86 -I/home/katsumi/work/swift-source/llvm/lib/Target/X86 -I/usr/include/libxml2 -Iinclude -I/home/katsumi/work/swift-source/llvm/include -Wno-unknown-warning-option -Werror=unguarded-availability-new -g -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wno-class-memaccess -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -g -fno-exceptions -fno-rtti -MMD -MT lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86ISelLowering.cpp.o -MF lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86ISelLowering.cpp.o.d -o lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86ISelLowering.cpp.o -c /home/katsumi/work/swift-source/llvm/lib/Target/X86/X86ISelLowering.cpp clang: error: unable to execute command: Killed clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ********************

！！！

3:28 PM

clang: error: unable to execute command: Killed

同じエラーっぽいです。

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/X86ISelLowering-5d18e1.cpp clang: note: diagnostic msg: /tmp/X86ISelLowering-5d18e1.sh clang: note: diagnostic msg: ******************** ninja: build stopped: subcommand failed. utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting

2つのマシンで試してたけど片方は全然手前で死んだ。

3:28 PM

この状態になるとリトライしても同じ。

3:29 PM

あ、これはディスクかもしれないな。

[59/1905] Building CXX object

リンクではないところですね

進み始めたけど、たぶん死にますね。ちょっとマシン選びが適当すぎました。別の方は進んでるんでそっちの様子を見ましょう。

3:31 PM

Swiftって一部ビルドするだけでこんなにディスク消費するんでしたっけ

数Gは使うと思いますけど気にしたことがなくて値はよくわからないです

3:32 PM

手元のbuild/Xcode-DebugAssertは31Gだ。

あー、swift build -c releaseだとswift-nightlyボットのCIも通るみたい。

ほう

久しぶりにswift-nightlyボットを更新できそう。

ダメだった。

[1071/2408] Linking CXX shared library lib/libLTO.so.7svn FAILED: : && /usr/bin/clang++ -fPIC -Wno-unknown-warning-option

^ 昨日ビルドしてた２つのマシンがリンクフェーズの同じところで死んでました。

あ、おはようございます、あら・・・マジか・・

リトライしても同じですね。別にメモリでもCPUでもなさそう。

僕も昨日libLTO.soのリンクで死んでました。

スペックを上げて成功するような様子がないです。

なるほど。でもこれでDockerは関係ないことがわかってよかったです。

2:18 AM

PRスレッドの方にも、Dockerのメモリ増やしてみたら？ってアドバイスが来てたんで、改めてやり直しているところですがダメそうだなあ

メモリ8G Swap 8G 4コアにして --jobs 1 で実行したら LLVMのリンクが突破できた。

スペックの問題なのか〜

最初デフォルトのjobs4の状態だとコケたので、

3:33 AM

並列実行にバグがあるのかも？

なるほど。再トライしてみよう。 (edited)

[31/78] Linking CXX shared library src/libdispatch.so ここでコケるようになったでも、例の謎の Killed じゃなくて /usr/bin/ld.gold: error: cannot find -lswiftSwiftOnoneSupport

^ これは根本の原因はビルドスクリプトが変更に追いついてないのかな。

そうですね、Swift関連の複数のリポジトリの足並みが揃ってないとこういうことがおきますでも、snapshotはCIで通ったコミットに対してついてるはずだから、 snapshotでチェックアウトしてる以上、正しい組み合わせのはずなんですよねえ

9:59 AM

あ、でもそうか、foundationだけは自分のコミットになってるから、それでおかしいのかな・・・

10:00 AM

それにしてもここまで来るのに朝から8時間かかってるのが厳しいｗ

Docker for Mac 2.0.0.0-mac77(edge)でdocker-machine upgradeしたらハマったので共有。 https://twitter.com/norio_nomura/status/1063237666903273474

Norio Nomura (@norio_nomura)

Docker for Mac 2.0.0.0-mac77へアップグレード後docker-machine upgradeしたらdocker-machineが壊れた。boot2dockerをv18.06.1-ceにして復旧。 -- 18.09.0 iso breaks swarm ingress · Issue #4608 · docker/machine https://t.co/EwqzwMziDi

1116snapshotがビルドできました releaseモードですが

foundationを切り替えてやり直したら missing required module 'SwiftShims' でコケた・・

8:04 AM

docker-machine + jobs = 1だと1日1手しか施行できなくて何も進まねえｗ

8:05 AM

再実行したらなぜかlibDispatchがリビルドされてるな。1回じゃうまくいかないcmakeソースのバグなどがあるのかな？

グオオオ

9:56 AM

masterにしたらfoundationのテストが通らなくて、犯人のコミット調べてたら

9:56 AM

https://github.com/apple/swift-corelibs-foundation/pull/1777

Adjust for 'try?' changes in Swift 5 by bjhomer · Pull Request #1...

When 'try?' has an optional sub-expression, it no longer produces a nested optional.

9:56 AM

コンパイラが最近Swift5モードがデフォルトになったからそれだといけるらしい

9:57 AM

手元のswiftcの方のコミットがずれてるから通らなかったのだ・・・

今日こそ・・・

2:07 AM

macでdockerが遅い問題、volume mountが遅いらしくて、 cached を設定すると良いらしいので、やってみる

ああ、その辺りは散々試しました。

お。

cachedはメモリ消費が多すぎて、使うのを止めました。

なるほどｗ

結局nfsでマウントする様にしてます。

ほほう

4:17 AM

ホストのmac上でnfsで？サーバを立てた上で、コンテナがそれに対してソケットで接続してマウントしてる状態を構築するって感じですか？

4:18 AM

それとも、普段からnfsストレージで作業してて、macもコンテナもそこにネットワーク接続している？

あ、VMware Fusionでdocker-machine使う構成です。

ほほう

Docker for Macのネイティブな奴は、nfsを使う構成が面倒だった。

4:21 AM

docker-machineを使った構成のメモ https://github.com/norio-nomura/swift-dev/blob/sourcekit-linux/docker-machine-on-mac.md

norio-nomura/swift-dev

Managing Swift Repositories. Contribute to norio-nomura/swift-dev development by creating an account on GitHub.

ありがとうございます

4:23 AM

IO自体が仮想化されなくなって、CPUバウンドになって、なんかいい感じになるんかな・・・

Docker for Macのボリュームマウントが遅い問題は、小規模なプロジェクトではcachedで問題なくなるけど、大規模だとまだダメという認識です。

物理メモリ16Gのうち8GをDocker-machineに割り当てた状態で、今Swift Compilerをビルドしてみています。

4:27 AM

昨日までの状態では、たとえ --jobs 1 であっても

4:27 AM

Dockerの中が忙しくなるとホストに影響が出てきて、特に文字入力とか日本語変換とかが秒単位でプチフリするようになるんで

4:28 AM

どうなるか試し中

4:28 AM

いまんとこ、com.docker.hyperkitがメモリ13.7G, メモリ圧縮4.7G, と表示されていますｗ

4:29 AM

引いても8Gを超えてるのが気になる。

cachedだとキャッシュメモリがバカみたいに消費されたと記憶。

4:33 AM

docker-machineを使わずにnfs使う方法。 https://qiita.com/kunit/items/36d9e5fa710ad26f8010 (edited)

Docker for Mac の NFS Volume sharing のベンチマーク結果(...

Docker for Mac の Volumeマウントの遅さについて

Docker for Mac は正式版になる以前からローカルファイルシステムをマウントした際の、read/writeの遅さが指摘されていた。特に write ...

お、簡単そう。

dockerにオプション指定ではなくdocker-composeを使う事が多いなら、こちらが良いのかも。

設定項目が多いから、dockerオプション指定だと結構めんどくさいですね。

そう。

以前はmacOSのバグでnfsクライアント側で謎のpermission errorとか出る事があったけど、今は直ったのだったかな。

Could not cast value of type 'XCTest.WaiterManager<XCTest.XCTWaiter>' (0x5573ab0fdab0) to 'Foundation.NSObject' (0x7fe388789920).

うおおおおお

6:33 AM

やっと手元で再現できた！！

6:34 AM

ここまで9日かかったｗ

おつ

7:15 AM

nfsのパフォーマンス調べてみた。

7:17 AM

Docker for Mac Native NFS

$ docker volume create --driver local --opt type=nfs --opt o=addr=host.docker.internal,rw,nolock,hard,nointr,nfsvers=3,acregmin=1,acdirmin=1 --opt device=:/Users Users $ docker run --privileged -it -v Users:/Users -w `pwd` --rm norionomura/swift:421 bash -c "time dd if=/dev/zero of=test bs=1k count=100000" 100000+0 records in 100000+0 records out 102400000 bytes (102 MB, 98 MiB) copied, 4.34849 s, 23.5 MB/s real 0m4.365s user 0m0.020s sys 0m0.220s

7:19 AM

docker-machine VMware Fusion + NFS

$ docker run --privileged -it -v `pwd`:`pwd` -w `pwd` --rm norionomura/swift:421 bash -c "time dd if=/dev/zero of=test bs=1k count=100000" 100000+0 records in 100000+0 records out 102400000 bytes (102 MB, 98 MiB) copied, 1.43024 s, 71.6 MB/s real 0m1.455s user 0m0.030s sys 0m0.180s

7:21 AM

Docker for Mac

$ docker run --privileged -it -v `pwd`:`pwd` -w `pwd` --rm norionomura/swift:421 bash -c "time dd if=/dev/zero of=test bs=1k count=100000" 100000+0 records in 100000+0 records out 102400000 bytes (102 MB, 98 MiB) copied, 45.2698 s, 2.3 MB/s real 0m45.259s user 0m0.370s sys 0m4.710s

7:23 AM

Docker for Mac Native NFSはdocker-machineと同等の場合もある。

Docker for Mac の45secは際立ってますね

cachedは使ってもあまり変わらなかった。

なるほど。こっちでは結構変わりました。全然重くなかった。

上記テストはddでの書き込みですからね。読み込みはcachedの効果が出そうです。

ですね〜

まあでも、nfs使うのがオススメです。

7:27 AM

調査にかかる時間とか、多分1, 2回のビルドで取り戻せる。

確かに・・・次やってみます。

@swift-4.2.4 import Foundation class Cat {} let a: Cat = Cat() let array = NSMutableArray() array.add(a as Any)

exit status: 134 with stderr:

Could not cast value of type 'main.Cat' (0x7f180f3b0040) to 'Foundation.NSObject' (0x7f1801800a20). #0 0x000000000410ac94 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x410ac94) #1 0x0000000004108b22 llvm::sys::RunSignalHandlers() (/usr/bin/swift+0x4108b22) #2 0x000000000410ae42 SignalHandler(int) (/usr/bin/swift+0x410ae42) #3 0x00007f180ef80390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x00007f180d6bf428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428) #5 0x00007f180d6c102a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a) #6 0x00007f18095ec742 (/usr/lib/swift/linux/libswiftCore.so+0x3c7742) #7 0x00007f18095e6b62 (/usr/lib/swift/linux/libswiftCore.so+0x3c1b62) #8 0x00007f18095e6bbb (/usr/lib/swift/linux/libswiftCore.so+0x3c1bbb) #9 0x00007f18095e7e43 swift_dynamicCastClassUnconditional (/usr/lib/swift/linux/libswiftCore.so+0x3c2e43) #10 0x00007f18016a4b52 $S10Foundation11_SwiftValueC5storeyAA8NSObjectCypFZTf4nd_n (/usr/lib/swift/linux/libFoundation.so+0x6ebb52) #11 0x00007f18016a42d9 $S10Foundation11_SwiftValueC5storeyAA8NSObjectCypFZ (/usr/lib/swift/linux/libFoundation.so+0x6eb2d9) #12 0x00007f1801342eb2 $S10Foundation14NSMutableArrayC6insert_2atyyp_SitF (/usr/lib/swift/linux/libFoundation.so+0x389eb2) #13 0x00007f1801342e3e $S10Foundation14NSMutableArrayC3addyyypF (/usr/lib/swift/linux/libFoundation.so+0x389e3e) #14 0x00007f180f3af102 #15 0x0000000001043efe llvm::MCJIT::runFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) (/usr/bin/swift+0x1043efe) #16 0x0000000001048022 llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, char const* const*) (/usr/bin/swift+0x1048022) #17 0x00000000004f8b42 swift::RunImmediately(swift::CompilerInstance&, std::vector<std::__cxx11::basic_string<char, std:

stderr.txt

https://ptpb.pw/rfkP.txt/text

↑本質的な問題はこれって事がわかった。

通るようになった・・・

https://github.com/apple/swift-corelibs-foundation/pull/1762#issuecomment-443022327

Change threadDictionary to NSMutableDictionary by omochi · Pull R...

This PR changes type of Thread.threadDictionary to NSMutableDictionary from Dictionary<String, Any>. The reasons are below. Because apple's implementation for macOS/iOS is so. A current...

12:51 AM

マージされた

7

12:52 AM

That's a regression; any object should be storable in an array. I'll need to look into it.

12:57 AM

気になるコメントと共に。

swift-corelibs-foundationで壊れていたDate, DateComponentsのnanosecond周りがSwift 5.0で直ったぽい。 @swift-4.2.4 @swift-5.0.3

import Foundation let now = Date() let comp = Calendar(identifier: .gregorian).dateComponents(in: .current, from: now) let recreatedDate = Calendar(identifier: .gregorian).date(from: comp) print(now.timeIntervalSinceReferenceDate == recreatedDate?.timeIntervalSinceReferenceDate)

false

true

Linux版はswift-4.2.x-RELEASEを毎月出すらしい。 https://forums.swift.org/t/announcing-swift-4-2-2-and-monthly-swift-4-2-x-dot-releases-for-linux/20148

Announcing Swift 4.2.2 and monthly Swift 4.2.x dot releases for Linux

Announcing Swift 4.2.2 and monthly Swift 4.2.x dot releases for Linux We are very happy to announce the release of Swift 4.2.2 containing bug fixes for Linux. Much more excitingly, from now on we will be releasing monthly Swift 4.2.x dot versions for Linux over the next few m...

なるほど、swift-corelibs-foundationとswift-corelibs-xctestの修正のバックポートに絞っていると。 (edited)

Docker Hubで公開している norionomura/swift 、5.0を機にubuntu16.04からubuntu18.04へ切り替えてたのだけど、Discordのボットをubuntu18.04にするとProcessで起動したswiftプロセスが終了せずにタイムアウトしてしまう不具合に遭遇。

ubuntu16.04へ戻すと今までどおりの挙動に戻る事を確認…

https://github.com/apple/swift-corelibs-foundation/pull/1762

Change threadDictionary to NSMutableDictionary by omochi · Pull R...

This PR changes type of Thread.threadDictionary to NSMutableDictionary from Dictionary<String, Any>. The reasons are below. Because apple's implementation for macOS/iOS is so. A current...

1:55 AM

↑11月にワイが出したやつで Nimble や RxSwift が壊れちゃったらしい。

1:55 AM

Ninbleは @ikesyo が直してた。

1:55 AM

RxSwiftは5ヶ月間壊れ続けてるんかな・・・。

もともとDarwinと非互換なところがあって、それを互換になるようになおしたら、RxSwiftはそのバグ（非互換）を回避するためのコードを書いてて、そっちが動かなくなったという話なんですね。難しい問題だ。

そう・・・

何をもってBreaking Changeというのか難しい

もともとがbrokenだっただけって思うんですけどねえ

1

これはRxSwiftが直しましょうねって感じですね

2

https://forums.swift.org/t/changes-to-foundation-must-go-through-swift-evolution/22312

Changes to Foundation must go through swift-evolution

I'd like to talk about something which has been bugging me for a while. Apologies for not doing it sooner, but recent events have brought this to my mind again and I think we should discuss it. For Swift 5.0, the Foundation team totally redesigned the Data type and did not...

2:33 AM

↑FoundationをSwift-Evol通そうってスレで、まあ、Darwin版がAppleのビジネス配下にあるからどうしようも、ってツッコミが入ってるけど

2:34 AM

Foundationは Darwinの互換性のものとして、 Swiftの標準ライブラリがあったほうが

2:34 AM

物事がスッキリする気がしてきた

2:35 AM

このNSThreadの件も結局、NSMutableArrayとかObjC由来の話があるせいでややこしくなってる感がある

2:36 AM

Linux版のFoundationだけ構造を綺麗にしていこうぜ、みたいな意見もあるけど。

Swift 5.0からswift-corelibs-foundationが使うICUがバンドルされる様になったから、令和サポートはツールチェインのアップデートが必要なのか。

https://github.com/apple/swift-corelibs-foundation/pull/2234 によって、一部のFoundationの型がComparableになったけど、Nimbleでソース互換の問題が発生した。

Parity: NSSortDescriptor & _CFSwiftArrayReplaceValues by millenomi...

Implement the parts that can be implemented and annotate the rest with diagnostics. Add a partially source-compatible version of init(keyPath:ascending:) that works with Comparable values. A li...

3:25 PM

https://github.com/apple/swift-corelibs-foundation/blob/42b387cf0b3e09ff3bbdcedb16236cd92bc0921f/Foundation/NSSortDescriptor.swift#L96-L124

apple/swift-corelibs-foundation

The Foundation Project, providing core utilities, internationalization, and OS independence - apple/swift-corelibs-foundation

3:25 PM

エラーの様子 https://travis-ci.org/Quick/Nimble/jobs/539263557

3:25 PM

これするなら、DarwinのOverlayの方でもComparable準拠追加した方がいいのではないか

ひとまず起票しました https://bugs.swift.org/browse/SR-10798

Linuxで--enable-test-discoveryを試せるtoolchainのDockerイメージを作りました。 https://forums.swift.org/t/test-discovery-on-linux/26203/5

Test discovery on Linux

I created a docker image on Docker Hub as norionomura/swift:pr-25685 that supports --enable-test-discovery.

これはLinuxMainなくてもxctestできるようになるモノですか？

そう。

7:26 AM

.build/x86_64-unknown-linux/debug/testlist.derived/ にLinuxMain.swiftとXCTestManifests.swift相当を生成してそれを実行してる。

$ rm Tests/LinuxMain.swift remove Tests/LinuxMain.swift? y $ _docker_swift_run norionomura/swift:pr-25685 swift test --enable-test-discovery --parallel [117/117] Testing YamsTests.YamlErrorTests/testYamlErrorScanner $ tree .build/x86_64-unknown-linux/debug/testlist.derived/ .build/x86_64-unknown-linux/debug/testlist.derived/ ├── YamsTests.swift └── main.swift 0 directories, 2 files

(edited)

7:28 AM

swift test --generate-linuxmainの生成物をリポジトリへ含めるのが不要になる。 (edited)

おお・・・ついに・・・

LinuxMain.swiftがなかったら勝手に--enable-test-discoveryする、とかそんな挙動になるのかな。

PR見ててもいまいち仕組みがわからない

お、SourceKitではなくIndexStoreなのか？ https://github.com/apple/swift-package-manager/pull/2174

[WIP] Implement test discovery on linux by aciidb0mb3r · Pull Req...

This is a WIP PR for implementing test discovery on linux using indexing data. The basic idea is to leverage the IndexStore library to get the test methods and then generate a LinuxMain.swift file ...

IndexStoreをしかも動的ロードしてる？

7:42 AM

IndexStoreが何かよくわかってない

ビルドしたときに解析した情報が入ってるのか。

そうみたい。

これてっきりSwiftSyntax使うのかと思ってた。

https://docs.google.com/document/d/1cH2sTpgSnJZCkZtJl1aY-rzy4uGPcrI-6RrUpdATO2Q/edit

Adding Index-While-Building support to Clang

Adding Index-While-Building support to Clang This document details the Clang enhancements behind the new index-while-building functionality introduced in Xcode 9. Motivation Indexing typically happens continuously in the background, and works as outlined in Figure 1. When a s...

SwiftPMは https://github.com/apple/indexstore-db から一部流用して作ってるぽい。 (edited)

apple/indexstore-db

Index database library for use with sourcekit-lsp. Contribute to apple/indexstore-db development by creating an account on GitHub.

indexstore面白いけど、エディタか、このSwiftPMの--enable-test-discoveryくらいしか利用法が思いつかないな。

FoundationNetworkingに続き、FoundationXMLも分離するらしい。 https://github.com/apple/swift-corelibs-foundation/pull/2432

Split: FoundationXML by millenomi · Pull Request #2432 · apple/s...

Split the portions of Foundation that depend on libxml2 into their own module, FoundationXML. This is the last module to be split off.

これって

2:26 AM

Foundation　は、全部入りを指すんですよね？

2:27 AM

いろいろ取り除いて残った部分のFoundation本体はなんてパッケージなんでしたっけ

FoundationはNetworkingとXMLが取り除かれたパッケージになる。全部入りパッケージは無い（と思う）。

あれ、そっちに倒れたのか

2:50 AM

それだと、iOSとLinuxで import Foundation したときに入るものが異なってしまいますよね。

そう。Linux対応しようとした場合、#if canImport(FoundationXML)とかが必須随時必要になる。 (edited)

そういう感じか・・・

メリットとしては、FounationNetworkingやFoundationXMLをインポートしなければ、libcurlやlibxml2をインストールしなくても実行時エラーにならなくなる。 (edited)

FoundationXMLに入るものは、そもそもiOSにもないような気が。

Foundation. XMLParserとか。

XMLParserはあった。ぼくもいま気づきました

https://twitter.com/SwiftLang/status/1161419342224904192

Swift Language (@SwiftLang)

The Thread Sanitizer for Swift is now available for Linux. Learn more about it here: https://t.co/Ih9A1q8dFw

このビルドエラー、docker-machineで動かしたコンテナでは発生せず、Docker for Mac標準のVMで動かしたコンテナだと発生する。なんだこれ… https://github.com/norio-nomura/SwiftBacktrace/runs/247453814#step:5:18 (edited)

norio-nomura/SwiftBacktrace

Stack traces for Swift on Mac and Linux using libunwind. - norio-nomura/SwiftBacktrace

docker-machineのVMがCPUを1個にしてたから発生しなかったらしい。CPUを2個にしたらdocker-machineでも再現した。

ははーん

swift-DEVELOPMENT-SNAPSHOT-2019-09-24-a以降で発生してる事を確認した。 https://bugs.swift.org/browse/SR-11570

久しぶりにLinuxのToolchainをビルドしてたらSwift.swiftmoduleを生成するところから進まなくて、VMのメモリを3GBまで増やしたらようやく進む様になった。以前は1GBで問題なかったのに…

ついに公式のNightly dockerイメージが来た。 https://forums.swift.org/t/nightly-swift-docker-images/33029

6

@swift-5.3.3 @swift-main

import Foundation private final class _Thread: Thread { private let block: () -> Void init(block: @escaping () -> Void) { self.block = block } override func main() { block() } }

no output

exit status: 1 with stderr:<stdin>:8:5: error: 'super.init' isn't called on all paths before returning from initializer } ^

これmacOS版だと通る。

Foundation...

Foundation.Thread の定義がずれてるってことですか？

Linuxのswift-DEVELOPMENT-SNAPSHOT-2020-08-18-aからNG (edited)

corelibsのコードは自分が見た限りわりと牧歌的なのでなんでもあるなーという印象

swift-DEVELOPMENT-SNAPSHOT-2020-08-18-a版のswift-corelibs-foundationに入った変更で関係しそうなものは無さそうなので、コンパイラの挙動が変わったのだと思う。 https://github.com/apple/swift-corelibs-foundation/compare/swift-DEVELOPMENT-SNAPSHOT-2020-08-11-a...swift-DEVELOPMENT-SNAPSHOT-2020-08-18-a (edited)

apple/swift-corelibs-foundation

The Foundation Project, providing core utilities, internationalization, and OS independence - apple/swift-corelibs-foundation

それは怖い

https://bugs.swift.org/browse/SR-13427

swift-5.3.1-RELEASEからLinux版のSwiftPMに渡された--static-swift-stdlibもswiftcへ-static-stdlibを渡す様になったけど、FoundationNetworking, FoundationXMLを使ってると~~ビルド~~リンクエラーになってしまう。 (edited)

そもそもこれまで-static-stdlib 渡ってなかったのか。

4:35 AM

そういえば、その辺り直したことがある気がする… たしかexecutableをリンクするときにしか渡らなかった気がする

swift-5.3-RELEASEでも同一条件で-Xswiftc -static-stdlibを使うと~~ビルド~~リンクエラーになる。 (edited)

おそらく lib/swift_static のswiftmoduleの配置が変わった影響ですね

4:37 AM

あとコンパイラの方の読み込み方も変わっていたはず

https://bugs.swift.org/browse/SR-648 で-static-stdlibがLinuxでも動く様になったと報告されてる詳細に、FoundationNetworking, FoundationXML利用有無とか書かれてない。

4:45 AM

SR-648で挙げられたPRマージ直後のスナップショットでも同様の~~ビルド~~リンクエラーになるので、配置変更とか関係ないと思う。 (edited)

これですか？ https://github.com/apple/swift/pull/33678

[5.3] Properly compute resource folder when linking statically by d...

Cherry-pick of #33168 into release/5.3 This PR depends on the following PRs: apple/swift-corelibs-foundation#2863 apple/swift-corelibs-foundation#2862 apple/swift-corelibs-libdispatch#546 Explanat...

あ、-static-stdlibを使うと外部依存するライブラリが変わるのか。

おお、再現しました。確かにリンクエラーになりますね

解決方法がわかったぽい。

あ！思い出した。implementationOnlyだ

CoreFoundationを明示的にインポートしても駄目だな

--static-swift-stdlib付け外し後はswift package cleanではダメで、swift package resetが必要ぽいのも、混乱の要因かも…

ええ。。そんなところに罠が

5:09 AM

リンクエラーなのでこれが原因だと思ったんですが https://forums.swift.org/t/implementationonly-behavior-in-autolinking/41621

@_implementationOnly behavior in autolinking

Hello, everyone. I have a question about @_implementationOnly. Currently, Foundation in apple/swift-corelibs-foundation uses @_implementationOnly to import CoreFoundation. At the same time, RunLoop.swift is still importing CoreFoundation without the attribute. The import in ...

5:13 AM

そもそもimplementationOnlyは5.3に含まれてなかった

とりあえずubuntu16.04を使ったnorionomura/swift:5.3.1で apt-get update && apt-get install -y libxml2-dev した後 swift package reset; swift build -Xswiftc -static-stdlib はリンク出来るが swift package reset; swift build --static-swift-stdlib はダメという事までわかった… (edited)

なんだそりゃ…

5:15 AM

ちなみにリンクエラーは何のシンボルが足りてないと出ますか？ import FoundationNetworking import Foundation print(try! String(contentsOf: URL(string: "https://example.com")!)) 僕の環境だとこれを swiftc main.swift -static-stdlib でコンパイルするとCoreFoundationのシンボルが足りないと怒られます。

事の始まりjazzy(sourcekitten)のビルドです。 https://github.com/norio-nomura/docker-jazzy/pull/20/checks?check_run_id=1393708523

5:21 AM

/usr/lib/swift_static/linux/libFoundation.a(Bridging.swift.o):Bridging.swift.o:function $s10Foundation12__SwiftValueC5fetch11nonOptionalypyXl_tFZ: error: undefined reference to 'kCFBooleanTrue'

CFですねぇ

オフィシャルdockerイメージではなく、norionomura/swift:5.3.1を使ってます。

5:24 AM

オフィシャル版Dockerfileからswift-5.3.1-RELEASE相当をビルドしようとしてるけど、途中でdocker buildが止まる…

まだ5.3.1のオフィシャルイメージないのか。

5:27 AM

とりあえず norionomura/swift:531 で試してみます

あ！わかった

6:00 AM

--static-swift-stdlib の場合、オブジェクトファイルを作るときにはSwiftPMは-static-stdlibを渡さないので /usr/lib/swift/CoreFoundation/module.map を見て、autolinkのエントリを追加しないからリンク時に-lCoreFoundation が付かないんだ！ (edited)

なるほど。

6:03 AM

とりあえずオフィシャルイメージ相当でも apt-get update && apt-get install -y libxml2-dev swift build -Xswiftc -static-stdlib でリンク出来ることを確認しました。

とりあえず -Xswiftcで渡すしか無いですね…

6:04 AM

パッチ作っておきます

1

# ldd `swift build --show-bin-path`/sourcekitten linux-vdso.so.1 => (0x00007fffa45cd000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f50112a8000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f50110a5000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5010ea1000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5010b98000) libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f50107dd000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f501045b000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5010245000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f500fe7b000) /lib64/ld-linux-x86-64.so.2 (0x00007f50140a1000) libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 (0x00007f500fae7000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f500f8cd000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f500f6ab000) libicudata.so.55 => /usr/lib/x86_64-linux-gnu/libicudata.so.55 (0x00007f500dbf4000)

6:07 AM

これ、不要な.soがリンクされてる気がするんだけど、実際にシンボルを参照していなければ、.soが無くても動いたりするのだろうか？

~~libicudata と libicuuc が.soでリンクされてるのがおかしい気がしますね~~ 元のlibicuがリンクされてるのはいいのか、swiftサフィックスが付いてるicuが動的リンクされていなければ正常だ。 (edited)

6:09 AM

使ってなければ動くような気もしますが、どうだろう…

libxml2.soがlibicu*を使ってますね。

6:14 AM

素のubuntuにapt-get update && apt-get install -y libxml2するだけで実行可能になりました。 (edited)

libxmlもicuに依存してるんですね。しらなかった。

実際にはsourcekitdが無いと動かないのですが。

お、libxml2が必要な依存物を引き連れてインストールしてくれてるんですかね

そうです。

echo 'import Foundation'|swiftc -static-executable -はまた違ったリンクエラーになるのね。

えぇ…

6:38 AM

/usr/lib/swift_static/linux/libswiftImageInspectionShared.a(ImageInspectionELF.cpp.o):ImageInspectionELF.cpp:function swift::initializeProtocolLookup(): error: undefined reference to 'swift::addImageProtocolsBlockCallbackUnsafe(void const*, unsigned long)' ...

6:38 AM

この辺のシンボルはswiftCoreに入ってるはずなんだけどなぁ

--static-swift-stdlib 全然テストされてない…

1

とりあえず、issue書いておこうかな…

お願いします

SR-648がまだopenだから、そちらへコメントの方が良いのかな？

確かに、まだopenならそっちのほうが良いかも知れないですね

https://github.com/apple/swift-package-manager/pull/3048

Pass -static-stdlib for all compiler jobs by kateinoigakukun · Pull...

Motivation: --static-swift-stdlib support on Linux is introduced by #2921 but it doesn't work when linking CoreFoundation. When CoreFoundation is used on a project and a user uses --static-...

7:13 AM

おそらくこれで治るはず

現象と回避方法だけコメントしました。

ありがとうございますリファレンスしました〜

1

dockerイメージの方にもPR出した方が良いかも。

あれ、dockerイメージの方にも必要な変更ありましたっけ

今はlibxml2しかインストールされていないので、libxml2-devへ変更した方が良いかなと。

ああそうかslimじゃない方には-devを入れたほうが良さそうですね

お、wasm32も対象なのか。 https://github.com/apple/swift-package-manager/pull/3048/files#diff-13eb4b18e8a4f2de8467dae905be6bdc133208159aded4aa6dbb6a03be21c6bdR1926

実はそうなんです。

7:31 AM

mainブランチからブランチ切ったせいでSourceKittenのマニフェストをビルドできなくなった

ありゃ？

release/5.3 ベースにしてやり直してます

sourcekittenはnightlyテストしてないな。

正確には依存の SWXMLHash がビルドできなかったです

あれ？こちらではswift-DEVELOPMENT-SNAPSHOT-2020-11-09-aでビルドできました。 (edited)

お？どうしてだろう… この数日の間に壊れるような変更が入ったのか？

自分でSwiftPMをビルドすると-package-description-version 4.0.0に固定されてしまうな‥

.so, .a 両方が入ってる場合に .aを優先する方法ってないのだろうか。

-static を付けたら.aを優先してくれないですか？ lldはそういう挙動だったと思います

11:03 AM

GNU ldがどうかはわからないです

-staticは他のオプションの関係で使えないみたい。

# swift build -Xswiftc -static-stdlib -Xlinker -static /usr/bin/ld.gold: fatal error: -pie and -static are incompatible clang-10: error: linker command failed with exit code 1 (use -v to see invocation) <unknown>:0: error: link command failed with exit code 1 (use -v to see invocation) [0/1] Linking sourcekitten

2:41 PM

.soを探さないという極端な挙動のオプションはあるけど、両方存在する場合に.aを優先する的なのは見当たらない… # ld.gold --help Usage: ld.gold [options] file... Options: … -Bstatic -l does not search for shared libraries (edited)

https://forums.swift.org/t/static-linking-on-linux-in-swift-5-3-1/41989

Static linking on Linux in Swift 5.3.1

Static linking on Linux I am happy to announce that with the release of Swift 5.3.1 statically linking the Swift stdlib components is now fully supported on Linux. This includes linking against Dispatch and the different Foundation components. Additionally building self-contai...

なるほどPIEと衝突するのか… 難しいですね。

2:17 AM

そういえばSwiftPMのPRは無事マージされました

1

swift-DEVELOPMENT-SNAPSHOT-2020-11-13-aで試そうと思ったら、まだPRの変更が含まれてなかった。

1

swift-DEVELOPMENT-SNAPSHOT-2020-11-16-aで確認しました。

docker run -v$PWD:$PWD -w$PWD norionomura/swift:nightly sh -c 'apt-get update && apt-get install -y libxml2-dev && swift build -c release --static-swift-stdlib'

で無事にsourcekittenをビルドできました。

おー、よかったです

swiftlang/swift:nightlyはまだ更新されてないのでnorionomura/swift:nightlyで。

10:08 AM

XCTestはスタティック版がまだ無いぽい。

あれ、無いんでしたっけ？

10:12 AM

CMakeLists自体はスタティックライブラリのビルドをサポートしてるんですけどね

$ docker-swift-run find /usr -name "*XCTest*" /usr/lib/swift_static/shims/XCTestOverlayShims.h /usr/lib/swift/shims/XCTestOverlayShims.h /usr/lib/swift/linux/libXCTest.so /usr/lib/swift/linux/x86_64/XCTest.swiftdoc /usr/lib/swift/linux/x86_64/XCTest.swiftmodule

swift/utils/build-script-implにlibXCTest.aをビルドする仕組みが入ってないぽい。

なるほど

foundation_staticを見ると、productとしてxctest_staticを用意していく作法ぽい。 https://github.com/apple/swift/blob/main/utils/build-script-impl#L2301

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

swift-5.4-RELEASEでSwiftLintにswift build --configuration release -Xswiftc -static-stdlibするとundefined referenceでリンクエラーになる。 https://github.com/norio-nomura/docker-swiftlint/pull/18/checks?check_run_id=2445741371

あー、これ直さないまま出荷されてしまった… (edited)

9:27 AM

FoundationがCoreFoundationを@_implementationOnlyでimportするようになった影響でFoundation.swiftmoduleにCoreFoundationへの依存の記述が無くなったんですよね

9:29 AM

動的ライブラリの場合はlibFoundation.soがlibCoreFoundation.soにリンクされているので問題なくリンクできるんですが、静的ライブラリlibFoundation.aはlibCoreFoundation.aを包含してないので壊れました

9:29 AM

とりあえずのworkaroundとしては -Xlinker -lCoreFoundation で治ると思います。

9:30 AM

詳しくはここにレポートしてました https://forums.swift.org/t/autolinking-behavior-of-implementationonly-with-static-linking/44393

Autolinking behavior of @_implementationOnly with static linking

I want to confirm that I'm using @_implementationOnly correctly with static library in autolinking aspect. Currently, Foundation imports CoreFoundation with @_implementationOnly attribute other than Linux and Darwin platforms. Modules imported with @_implementationOnly are not added to swift1_autolink_entries to hide the dependencies, and the...

ありがとうございます。試してみましたが、-Xlinker -lCoreFoundationでは治らないようです。 https://github.com/norio-nomura/docker-swiftlint/pull/18/checks?check_run_id=2446742238

おっと、なんでだろう

9:54 AM

手元で試してみます

手元では-Xlinker -lCFURLSessionInterface -Xlinker -lcurlで治りました。CIでも試し中。

あー、そうかLinuxだとFoundationNetworkingがあるからその辺りも明示的にリンクしないとダメですね

-Xlinker -lCoreFoundationは不要でした。 https://github.com/norio-nomura/docker-swiftlint/pull/18/commits/8117b0751d17ff567ea58656f4b3f718e39bd665

むむ、そうすると@_implementationOnlyをつけ忘れてるimport CoreFoundationがLinux向けのFoundationのコードに残ってるかもしれないですね。 (edited)

10:31 AM

@swift-5.4.3 -c -Xfrontend -use-static-resource-dir import FoundationNetworking _ = URLSession.shared (edited)

no output

https://github.com/apple/swift-corelibs-foundation/blob/swift-5.4-RELEASE/Sources/Foundation/RunLoop.swift#L10-L14 (edited)

apple/swift-corelibs-foundation

The Foundation Project, providing core utilities, internationalization, and OS independence - apple/swift-corelibs-foundation

あー、確かにその行見たことありますね。

10:38 AM

Wasm向けだとRunLoop動かないので除外してる関係で@_implementationOnly無しのimportが無くなってて、import FoundationがWasmだけで壊れてたんだ。思い出してきた。

そこ以外はDarwin向けとテストですね。

とりあえず改めてレポートしておきますね

bugsに上げました https://bugs.swift.org/browse/SR-14536 (edited)

1

直してくれてありがとう

https://kateinoigakukun.hatenablog.com/entry/2021/09/02/110000

kateinoigaku

SwiftコンパイラのAuto-linkingとそれを直した話 - kateinoigakukunのブログ

前回のエントリでAuto-linkingについて解説しました。今回はSwiftコンパイラにおけるAuto-linkingの使われ方と、最近それを直した話をします。 kateinoigakukun.hatenablog.com 用語定義モジュール: Swiftのimportできる単位。 .swiftmodule、.swiftinterfaceまたは module.modulemap が実態。Cで言うヘッダライブラリ: libfoo.a とか libfoo.dylib。大抵モジュールと1対1になってる。 SwiftのAuto-linking C言語では以下のようなpragmaを書くことでリンク…

1

https://github.com/apple/swift-nio/blob/main/Sources/NIOFoundationCompat/ByteBuffer-foundation.swift#L299

swift-nio/ByteBuffer-foundation.swift at main · apple/swift-nio

Event-driven network application framework for high performance protocol servers & clients, non-blocking. - swift-nio/ByteBuffer-foundation.swift at main · apple/swift-nio

1:06 PM

swift-nio の Data(buffer: ByteBuffer) が NIOFoundationCompat モジュールに定義されていて、Linuxだとこれをimportしないと使えないんだけど

1:06 PM

mac環境だとなぜかこれをimportしなくても使えるのが、なぜかわからなくて困っている

綺麗なターゲット作ったらちゃんとエラーになった

1:15 PM

何かビルドが壊れてるか他のライブラリの影響か

あれ？auto-linkingって5.5でも壊れたまま？

お、どのケースですか？

2:13 PM

あ、5.5か。マージがブランチカットに間に合わなかったので5.5には入ってないです

なるほど。

久しぶりにローカルのdockerでSwiftLintをビルドしようとしたら、メモリ不足でビルドできなかった…

SwiftLintが大きくなったのか、ツールチェインのメモリ利用効率が悪化したのか…

5.3だとビルドできた。

5.4は5.3での所要時間の7倍を超えてまだビルド中、5.5での挙動に似てるからダメそう。

5.4もダメだった。 (edited)

Docker for MacのVMメモリを2GBから3GBへ増やしたら5.4と5.5でもビルドできた。 (edited)

Oracle Cloud Infrastructureの無料で使える範囲がすごくて ARM CPUが4コアと24 GBメモリまで、AMDのCPUで1 GBメモリが２台まで、さらにブロックボリュームが200 GBも使えるのでSwift自体をビルドすることも可能だった。 https://www.oracle.com/jp/cloud/free/#always-free (edited)

Oracle Cloud Free Tierを試す

Oracle Cloud Always Free Tierにサインアップすると、さらに多くのサービスに使用できる、30日間トライアルを対象とした300ドルの無料クレジットが提供されます。

後発ゆえ囲い込みが大変？

そうなのか。大変だ。

5:49 AM

Ingress/Egressの扱いが他とちょっと違うとか全体のダッシュボードみたいなのがなくて最初ちょっと迷うみたいな慣れは必要だけどおおむね使いやすいです。UI的な使い勝手はAzureより上。

5:51 AM

READMEに従ってSwiftを utils/build-script --release-debuginfo --test --skip-early-swift-driver でビルドしてテスト実行まで含めてピッタリ２時間半ってところ。ARM CPUの4コアと24 GBメモリのマシン。

debuginfo付けてビルドできるのはすごい！

そうだよね。

5:53 AM

70GBくらいの成果物になるからブロックボリュームのアタッチは必須だけどWeb UIですぐだった。なんせ200GB使えるし。

5:54 AM

確かにざっと調べた感じ後発だから価格はがんばってる、みたいなことが書かれてた。

6:01 AM

このUTC 3:00-5:30がSwiftのビルド。CPUは使い切ってるけどメモリはだいぶ余裕があるかな。一番高いところで15%だから4GB弱か。そこらへんのVPCじゃ難しいな。

30日間無料と、ずっと無料の範囲がよくわからなかった

30日間無料はおそらくサインアップしたら付与される¥33,000ぶんのクレジットのことだと思います。

6:40 AM

https://docs.oracle.com/en-us/iaas/Content/FreeTier/freetier_topic-Always_Free_Resources.htm もうちょっと詳しいドキュメントはこれかな。30日間無料についてはよくわかってないです。

ありがとうございます。おお、なかなかに太っ腹な感じ。

6:48 AM

というか、信じられないほど豪華？

OCIの無料枠がすごいっていうのはOCIについて調べてたらちょいちょい目にしたのですごいんだと思います。

6:50 AM

ARMアーキテクチャのSwiftイメージでVaporのWebサービスも動きました。たぶんVPC4つぶんとして使ってもいいんだと思うんですよね。

swift:5.5.2-focal で、最適化バグで、実行ファイルが該当箇所でコアダンプ吐いてクラッシュする症状に出会いました。しかも、その箇所 + 5.5.2 の組み合わせは過去に動いていて、新規に追加した別のコードが、間接的に？なんらかの影響をその箇所に与えていたようです。 printを追加すると症状が消えたりしたので、 @_optmize(none) を付けて解決しました。みなさんも気をつけて・・・

macのdockerの5.5.2-focalでは解決したけどamazonlinuxのdockerの5.5.2-focalでは Vapor.StackTrace.capture がクラッシュしててだめだこりゃ

5.5.2-focal, 5.5.1-focal, 5.5.0-focal, 5.5.2-bionic で再現したのでおしまいです nightly-5.6-bionic に行くことにします

レスポンスヘッダにnio-http2がサポートしてない奴があるとfatalErrorだったのがセキュリティイシューとして対応されたらしい https://twitter.com/lukasaoz/status/1492067005486309394?s=21

Cory Benfield (@Lukasaoz)

swift-nio-http2 1.19.2 has been released with three fixes for high severity denial of service issues. We recommend updating as soon as practical to remediate these issues. More details available from the release notes: https://t.co/au2XqazShv

10:34 AM

fuzzingで見つかったとのこと

https://github.com/apple/swift-nio-http2/commit/000ca94f9de92c95b9ac85d44600b7b0fe25a3e5#diff-cf9025d8ea6d311afe1a3ad83fd8c3456c162d86fde91c690e081490f0ec99f3L238

Merge pull request from GHSA-pgfx-g6rc-8cjv · apple/swift-nio-http2...

Motivation: We don't currently support ALTSVC and ORIGIN frames. At the moment when receiving or attempting to write these frames we trap. Trapping when receiving an unsupported frame can ...

12:23 PM

TODOでfatalErrorｗ

macOS版のDEVELOPMENT-SNAPSHOTはインストール先のディレクトリ名を見ればいつのものかわかるけど、Docker版はswift -versionに含まれるハッシュを元にリポジトリを検索しないとわからない。そのためにSwiftボットはGitHubのGraphQL APIを使ってタグを取得してたのだけど、その仕組みをGitHub CLI extensionとして独立させた。 https://github.com/norio-nomura/gh-query-tags (edited)

GitHub - norio-nomura/gh-query-tags: GitHub CLI extension to query ...

GitHub CLI extension to query the GitHub repository and print out the tags. - GitHub - norio-nomura/gh-query-tags: GitHub CLI extension to query the GitHub repository and print out the tags.

1

一応、apple/swift以外でも使えるように汎用性を持たせたけど、apple/swift関連以外でスナップショットにタグを付けて運用しているリポジトリを見つけられなかったので、事実上apple/swift関連専用。

久しぶりにSwiftLintをLinux on Dockerでビルドしてたのだけど、swift:focalだと動くのにswift:bionicだとswiftlint versionすら動かない。 $ docker run -it --rm -v $(pwd):$(pwd) -w$(pwd) swiftlint:bionic swiftlint version free(): invalid pointer

1:03 AM

swift:latestはbionicなんだけど、focalを使った方が良いのかな。

FileManager.DirectoryEnumerationOptions.producesRelativePathURLs という欲しかったものがあることに気がついて使ったが、Linuxに実装されてなかった。。

1

Linux 向けのマクロサポートはここで進んでそうですね． https://github.com/apple/swift/pull/68082

[WIP][CMake] Support Macros in Linux by rintaro · Pull Request #680...

For compiling codes required for macro support, we now need swiftc compiler in the build machine. Unlike Darwin OSes, where swiftCore runtime is guaranteed to be present in /usr/lib, Linux doesn&#3...

りんたろーさんがやってるんや

そういえばここで rintaro さんが書いてるみたいに 9 月以降の nightly ツールチェーンだと Linux でもマクロのビルドが普通に成功するようになっていました． https://forums.swift.org/t/are-macros-supported-on-linux-yet/65427/22

Are macros supported on Linux yet?

From Swift.org - Download Swift, I downloaded swift-DEVELOPMENT-SNAPSHOT-2023-09-01-a-ubuntu20.04-aarch64.tar.gz , cloned swift-syntax repo, applied this patch diff --git a/Examples/Package.swift b/Examples/Package.swift index f10a7c4a..821d3939 100644 --- a/Examples/Package.swift +++ b/Examples/Package.swift @@ -62,7 +62,7 @@ let package = Pac...

Docker Desktopで--platform=linux/amd64を付けて実行した時に/proc/self/cmdlineの内容がバグってて、

$ docker run --platform=linux/arm64 alpine cat /proc/self/cmdline|xargs -0 echo cat /proc/self/cmdline $ docker run --platform=linux/amd64 alpine cat /proc/self/cmdline|xargs -0 echo /bin/cat cat /proc/self/cmdline

CommandLine.argumentsの取得にそれを利用してるSwift製のバイナリはその影響を受けるので、swift buildとか動かない。

$ docker run -it -v $PWD:$PWD:rw -w $PWD --platform=linux/amd64 swift swift build error: Unexpected argument '/usr/bin/swift-build' Usage: swift build <options> See 'build -help' for more information.

正規の手順(argc,argv)?を使ってる場合、影響を受けない。 https://lima-vm.io で立ち上げたdockerだと/proc/self/cmdlineの内容は少しおかしいけど、SwiftのCommandLine.argumentsは影響を受けない。

$ docker.lima run --platform=linux/arm64 alpine cat /proc/self/cmdline|xargs -0 echo cat /proc/self/cmdline $ docker.lima run --platform=linux/amd64 alpine cat /proc/self/cmdline|xargs -0 echo /bin/cat /proc/self/cmdline

Lima

5:38 AM

issueは上がってるけど未解決のままcloseされてる。 https://github.com/docker/for-mac/issues/7058 (edited)

Rosetta emulation mishandles /proc//cmdline in 4.25.0 · Issue #7058...

Description After updating to Docker Desktop for Mac 4.25.0, Ubuntu 22.04 images running under Rosetta 2 emulation began to show corrupted /proc/<pid>/cmdline contents. Specifically, the actu...

gwynneさんだ

/proc/self/cmdline じゃなくてcrt0がくれるargvをコンパイラが吐くエントリポイントで保存しておくのが良いのかなぁ。

Rosetta in Linux guestについて調べてたら修正方法がわかったのでコメントした。 https://github.com/docker/for-mac/issues/7058#issuecomment-1926820688

1

11:58 AM

Docker DesktopのVMへのRosetta登録方法が間違ってるのだと思う。

docker buildx build --platform linux/amd64,linux/arm64は、Rosetta入りのlimaでもamd64がqemuになってめっちゃ遅かったけど、Docker DesktopだとちゃんとRosettaで動いて速い。

Docker Desktop for MacのRosetta登録を修正するためのイメージを作った。

$ docker run --privileged ghcr.io/norio-nomura/re-register-rosetta Rosetta is not correctly registered. Re-registering rosetta... Successfully re-registered Rosetta. $ docker run --privileged ghcr.io/norio-nomura/re-register-rosetta It looks like Rosetta is correctly registered.

(edited)

これが解決するのはすばらしいな。Swiftを含むイメージをローカル環境で動作確認するのがすごい難しかった。

3:52 AM

しょうがないからLinuxマシンでやってた。

Docker Desktop for MacがResource Saver modeに入るだけでre-register-rosettaでの修正が元に戻ってしまうので、やっぱり元から直して欲しいです。

1

lima+vz.framework+rosettaのcolimaでもrosettaちゃんとうごかないんですかね

5:09 PM

docker for desktop にこだわる理由はなさそう?

lima+vz +rosettaはSwiftちゃんと動きます。multi archイメージを作らないなら、それで十分。

limaへ移る理由になった不具合を直せる方法が分かったから、伝えたくなっただけ。issueでは反応無いけど。

1

なるほ

I don't think this is really a Docker bug.

とか返事が来てがっかり。 https://github.com/docker/for-mac/issues/7058#issuecomment-1942042116

Rosetta emulation mishandles /proc//cmdline in 4.25.0 · Issue #7058...

Description After updating to Docker Desktop for Mac 4.25.0, Ubuntu 22.04 images running under Rosetta 2 emulation began to show corrupted /proc/<pid>/cmdline contents. Specifically, the actu...

2

返事してくれたのはAppleの人だった。そして調べてくれてるぽい。

お、Alastairさんだ

https://github.com/apple/swift/pull/71611

[CommandLine][Linux] Don't read argv from /proc/self/cmdline. by al...

Instead of reading from /proc/self/cmdline, take advantage of the fact that the initial stack layout is ABI specified, and that we already have a pointer into it (environ). This lets us walk up th...

1:57 PM

swift側で対応作業が生えてる

2:00 PM

何これ・・・

2:00 PM

スタックポインタを登っていってmainのargc, argvを触る・・・？

わははLinux ABIベタベタだ

登っていくわけじゃないな、環境変数定義が入ってるポインタを起点にメモリレイアウトを読むのか (edited)

2:03 PM

キモすぎるなんだこれ

2:05 PM

c++ ArgvGrabber::ArgvGrabber() : argv(nullptr), argc(0) { findArgv(findStack()); }

2:08 PM

/proc/self/maps から sscanf(line, "%p-%p", &base, &top) でスタックトップを取ってるけど、これは保険のチェック用っぽいな

2:11 PM

argc側じゃなくてargv側から攻めてるのかこれw

2:12 PM

ポインタの差し先で、文字列かargcか判別しとる

2:14 PM

コマンドライン引数が1000万個ぐらいあったらargcがデカくなってargvに見間違えたりしないのかな

動きが早くてすごいけどこれが正しい解決法なのか・・・？

2:37 PM

家庭くんのコメントと返信読んだけどプロセスの起動まわりについて各プラットフォームの違いを熟知してないといけなくてむずそうだ

Swift製のライブラリを非Swiftプログラムに対して提供することを考えると任意のタイミングでargvを提供してくれるシステムコールが無いLinuxがびみょうという気持ちになってきた

（mainからargc/vを拾うことが）RustとかができててSwiftでできないのは、

Swift製のライブラリを非Swiftプログラムに対して提供することを考える

このユースケースが想定されているからですか？

ですね。RustでもLinux + glibcのケースではそのユースケースもglibc拡張を利用してサポートしてるんですが、任意のLinux環境（Linux + muslとか）ではサポートしきれてないです

なるほど。

これは珍しくLinuxだけが機能足りてないケースだなぁ

2:42 PM

大抵WindowsかWASIが足りてないのに

2

このへんの説明を聞くと初見でびっくりしたこの方針に妥当感が得られて高速に学びを得られました

あ〜〜そうか、main関数に手を入れられるのはmainバイナリを作るコンパイラ一個だけなのか

そもそもプロセスパラメータじゃなくてエントリポイントの引数なんだから、main関数を掌握した人が任意に分配したパラメータを持たない限り、ライブラリからは見えない、みたいな世界観の方が統治されてて良さそうだけど

3:24 PM

ProcessInfo.arguments とか存在してるし、もうこれはプロセスでグローバルなものとして世の中回ってるって事やな (edited)

ProcessInfo.arguments というか CommandLine.arguments ですねSwift自体が提供してるのは

あ、そっちだった。

3:25 PM

ProcessInfoはFoundationか。

Yuta Saito

これは珍しくLinuxだけが機能足りてないケースだなぁ

/proc/<pid>/cmdline が、その機能じゃないの？

3:26 PM

API関数じゃなくてFile風ってだけで。

まあそう見ることも出来るか

norio_nomura

返事してくれたのはAppleの人だった。そして調べてくれてるぽい。

the Rosetta folksに聞いてくれてるみたい。

norio_nomura

docker buildx build --platform linux/amd64,linux/arm64は、Rosetta入りのlimaでもamd64がqemuになってめっちゃ遅かったけど、Docker DesktopだとちゃんとRosettaで動いて速い。

Docker Desktop for Macの"Use containerd for pulling and store images"オプションに相当する設定をすれば、lima+vz+Rosettaなdockerでも --platform linux/amd64,linux/arm64 でRosettaが使われることが分かったので、Docker Desktopを使う理由はさらに減った。

Linuxのswift5.10はzipをuntarしようとして失敗するらしい 4/2 snapshotならちゃんと動いた

5.10.1まち https://github.com/apple/swift-package-manager/pull/7321

[5.10] Fix non-tarballed SDK installation with remote URL (#7312) b...

#7312 Explanation: 4714ea9 introduced a regression where non-tarball SDKs could not be installed from a remote URL due to the wrong assumption that the downloaded file would always be a tarball...

それまでは先に curl とかでダウンロードしてローカルの .artifactbundle.zip を指定すると展開成功しますよ． (edited)

1

家庭先生が直してたｗ

2:29 PM

これどっちのチャンネルがいいかわからんのだけど

2:30 PM

ubuntu22.04でswift 4/2 snapshotを使ってwasm 4/3 snapshotのsdk入れてビルドしようとしたら

2:30 PM

PackageDescription が見えないとか言い出した

2:31 PM

これは何か既知の情報ありますか

なんだこれ。swiftlyで入れるの辞めたらどうなります？

2:31 PM

swiftlyのシンボリックリンクが悪さをしてると予想

そうだと思います．(同じエラー経験済み)

1

swiftlyで入れるのをやめたらubuntuホストのデフォルトのSwiftになっちゃうからexperimental sdkが取り込めないと思う

kebo

そうだと思います．(同じエラー経験済み)

お。どうやって回避しました？

ん、普通にtar.gzツールチェインをswift.org/downloadsからダウンロードして展開したらいいですよ

PATH で export PATH=$HOME/.local/share/swiftly/toolchains/バージョン/usr/bin:$PATH を指定して何とか凌いでますw

Yuta Saito

ん、普通にtar.gzツールチェインをswift.org/downloadsからダウンロードして展開したらいいですよ

あ、なるほど

kebo

PATH で export PATH=$HOME/.local/share/swiftly/toolchains/バージョン/usr/bin:$PATH を指定して何とか凌いでますw

あ〜 shim経由じゃなくてインストールされた実体を先に発見させるんですね。

2:34 PM

なるほどなるほど・・・

僕は単に諦めて5.9使ってます

update させるたびに書き換えないといけないから早く何とかしたいんですよね... 一応 Swift 6 リリースまで待っても apple/swift 側でどうにかならない場合は swiftly 側で対処するかどうするかみたいな話はありましたが... https://github.com/swift-server/swiftly/issues/52#issuecomment-1943012509

Provide wrappers for tool binaries instead of symlink · Issue #52 ·...

The design document says: The ~/.local/bin directory would include symlinks pointing to the bin directory of the "active" toolchain, if any. This is all very similar to how rustup does th...

Iceman

僕は単に諦めて5.9使ってます

4/2からWASM対応がネイティブ化してて、その対応でコマンドとかが変わってくるから、新しい方に寄せたい

kebo

update させるたびに書き換えないといけないから早く何とかしたいんですよね... 一応 Swift 6 リリースまで待っても apple/swift 側でどうにかならない場合は swiftly 側で対処するかどうするかみたいな話はありましたが... https://github.com/swift-server/swiftly/issues/52#issuecomment-1943012509

全て踏破済みですごいな

これはswiftlyで直すべきだと思うんだよな

サーバーサイドLinuxのCIでやってる時はswiftlyからswift buildしても問題ないんだけどな (edited)

いや，Swift 6.0 以降は問題あるはずですよ．swift-driver が新しくなってそれがシンボリックリンク経由だと問題を起こすので．

swiftlyが他と違うインストールレイアウトをするメリットは多分無くて、単純にバリエーションを増やして問題をややこしくしてるだけだと思う。気持ちの余裕があればswiftly側直すんだけど… (edited)

swiftlyそんな問題あったんですね

kebo

いや，Swift 6.0 以降は問題あるはずですよ．swift-driver が新しくなってそれがシンボリックリンク経由だと問題を起こすので．

あっ、そういう話か。新しいswift ＋ swiftlyの組み合わせの問題なんですね。

1

2:43 PM

そんな〜〜

2:43 PM

setup-swiftに疲れて乗り換えたのにな〜

なので -Xswiftc -disallow-use-new-driver を渡すとある程度の部分までは動きました (1 月くらいに確認した時点では) (edited)

1

ちなみに SSWG の Adam さんは新しい swift-driver は古いやつの完全互換品だから今までできたことができなくなったらそれは Swift 本体のバグだからそっちで直すべきって言ってました． https://github.com/swift-server/swiftly/issues/92#issuecomment-1892735163

The new swift-driver doesn't work properly · Issue #92 · swift-serv...

The current main-snapshot toolchain uses the new swift-driver and it doesn't seem to work with symlinks. $ swiftly install main-snapshot ... $ swiftly list Installed release toolchains --------...

はい。。まあそういうスタンスなので難しい。気持ちの余裕というのは彼とPatrickを説得する余裕というかなんというか。 (edited)

やっぱりやるとしたらそこからですよね... (私も PR 出そうか迷ってこんな変更をいきなり上げたところでコンセンサスとってないと厄介に思われるだけだなと思って辞めちゃいました)

1

なるほど。(new)swift-driverの問題という理屈はそうだなあ。 (edited)

元の話に戻ると，CI で常に最新の nightly のツールチェーンが使われるようにしたいというのであれば，swiftlang/swift イメージを使うのが現状は楽な気がしますね．ただ Swift SDK を使う場合は Swift SDK とツールチェーンのコミットハッシュを一致させるために Docker イメージの SHA256 ハッシュを明示する必要が出てきてしまって，その履歴がどこにもないから 1 日前のツールチェーンじゃないと最新の Swift SDK と一致しないみたいな場合の追従が大変なんですよね... 今は暇さえあれば docker image pull してコンテナ内のツールチェーンのバージョンとイメージのハッシュをメモして力技で何とかしてました．(自動化できそう)

1

Yuta Saito

ん、普通にtar.gzツールチェインをswift.org/downloadsからダウンロードして展開したらいいですよ

めちゃくちゃ沼ったけどやっとこれできた

楽しいCI沼

確かにカスタムイメージ作りたいとかがなければ結局ハッシュを固定するならそれが素直かもですね

tarを解凍したら usr/ が出てくるのだと思ったら swift-DEVELOPMENT-SNAPSHOT-2024-04-02-a-ubuntu22.04/ が出てきた。

そこで--strip-components=1

こんなのがあるのか〜

kebo

なので -Xswiftc -disallow-use-new-driver を渡すとある程度の部分までは動きました (1 月くらいに確認した時点では) (edited)

そういえば swift コマンドの代わりに古い swift-driver で動いてくれる swift-legacy-driver コマンドがあったのを忘れてました．これが廃止されるまでは swiftly でインストールした場合はこっちでも何とかなりますね．(e.g. swift-legacy-driver build, swift-legacy-driver experimental-sdk install) (edited)

kebo

ちなみに SSWG の Adam さんは新しい swift-driver は古いやつの完全互換品だから今までできたことができなくなったらそれは Swift 本体のバグだからそっちで直すべきって言ってました． https://github.com/swift-server/swiftly/issues/92#issuecomment-1892735163

swiftly でインストールした swift が使えない問題，6.0 に cherry-pick されるかはまだわからないですが，main では修正されたかもしれないです． https://github.com/apple/swift-driver/pull/1583

おお、やったあ。

↑6.0 にも cherry-pick きました https://github.com/apple/swift-driver/pull/1606 (edited)

Swiftコンパイラと成果物がlinuxのQEMUでクラッシュする件 https://discord.com/channels/291054398077927425/291054454793306112/1248559139173433414 M2 MacBook Proのlimaで動かしたQEMUのarm64エミュレーションdocker環境でクラッシュしなかった。x86_64マシンでないと再現しないのかな。 (edited)

Linux x86_64 と Linux aarch64 でビルドした成果物を QEMU 8.X や 9.0 aarch64 で動かすのなら普段やってますが，クラッシュしたことはないですね．Embedded Swift なので特殊かもしれないですが．

もしかして、GitHub Actions Runner特有なのかな?

GitHub Actions Runnerで使ってるsetup-qemu-actionとsetup-buildx-actionの動作をなぞって、M2 MacBook Proのlimaで動かしたQEMUのarm64 dockerでのx86_64エミュレーションでクラッシュが再現した。

1

1:34 PM

limaでQEMUのx86_64エミュレーションdockerを作ってx86_64バイナリを動かす場合はクラッシュしない。 (edited)

1:35 PM

CPUアーキテクチャに関係なく、binfmtに登録されたQEMUエミュレータ下で動く場合にクラッシュしてる感じ。 (edited)

例の /proc/self/cmdline 依存だったコマンド引数取得をスタックスキャンするようにしたところですかねぇ

1:56 PM

さすがにスタックレイアウトのエミュレーションが間違ってたらSwift以外にも広範囲に壊れそうですが

やっぱりそこが怪しいよね。

2:01 PM

再現手順をまとめるかな。

使ってらっしゃるイメージってこちらですよね？latest は QEMU v7.0 みたいなので，仮に QEMU の問題だとしたらもう修正済みでバージョンを上げるだけで治ったりするかもしれないですね．最近 9.0 がリリースしました．

qemuのリリースまで追ってるんですか。すごい

swift_os (Embedded Swift で書いてる OS の卵みたいな repo) で (実機があるので) Raspberry Pi 4 向けに開発したいなと思った時に QEMU だと 9.0 からしか -M raspi4b が使えないのでたまたまリリースを待ち侘びてました． (edited)

1

2:09 PM

とりあえず tonistiigi/binfmt には QEMU v8.1 くらいまでのタグは push されているようなので，そこまでのバージョンなら試そうと思えばそんなに手間はかからないと思います． (edited)

GitHub Actionでtonistiigi/binfmt:qemu-v8.1.5を試してみてます。

2:20 PM

あ、ローカルで再現した際のQEMUが9.0.0だ。

1

norio_nomura

GitHub Actionでtonistiigi/binfmt:qemu-v8.1.5を試してみてます。

これは、apt-getで失敗して件のクラッシュまで辿りつけない、という結果になりました。

norio_nomura

再現手順をまとめるかな。

成果物のクラッシュがローカルで再現しなくなってしまった。そしてQEMU絡みのswiftのクラッシュを見つけてしまった。

norio_nomura

成果物のクラッシュがローカルで再現しなくなってしまった。そしてQEMU絡みのswiftのクラッシュを見つけてしまった。

6.0とmainで直ってた。

macOS -> ubuntuのクロスコンパイルで--static-swift-stdlibをつけるとリンクエラーになる件、/usr/lib/swift_static/CoreFoundation/module.modulemapと/usr/lib/swift_static/dispatch/module.modulemapで指定されているライブラリがリンカへ渡されていないからみたい。

6:37 AM

swift-autolink-extractの担当かな？

Swiftのバージョンいくつですか？

SDKに入ってるのはswift-5.10.1-RELEASEで、--swift-sdkを受け取ってるのはmainの20240604です。

6:52 AM

うまくいくubuntu上でのクロスコンパイルログと見比べると、最後のld.lldへのオプションに-lDispatchStubsとかが現れるので、それのレスポンスファイルを作成に関わってそうな5.10.1のclangかswift-autolink-extractが怪しいのかなと。

6:53 AM

レスポンスファイルの中身を見たいけど、終了時に削除させない方法がわからず。

-save-tempsでその辺のファイル残しておけないですかね

そんなオプションが。

あーーーあったなあそれ、完全に忘れて、最近temp file消えて困ってた

-Xswiftc -save-tempsで残せました。ありがとうございます。 (edited)

やっぱりswift-autolink-extractの出力が違ってた。

あ、FoundationをimportせずにCoreFoundationを直接importしてたりしますか？

7:38 AM

CoreFoundationのmodulemapで指定されてるライブラリはautolinkエントリには追加していなくて、

7:38 AM

Foundation.swiftmoduleを作るときにそれらのライブラリを-public-autolink-library でFoundation.swiftmoduleのLINK_LIBRARYエントリとして登録しているので、

7:39 AM

それらのCoreFoundationの依存ライブラリのautolinkエントリがimport-siteに現れるのはFoundationをimportしたときだけなんですよね。

7:39 AM

CoreFoundationはAppleプラットフォーム外ではpublicなAPIではないということになっているので… (edited)

1

$ diff -u cross-on-docker.autolink cross-on-mac.autolink --- cross-on-docker.autolink 2024-06-11 16:39:17 +++ cross-on-mac.autolink 2024-06-11 16:39:37 @@ -5,15 +5,12 @@ -lswiftGlibc -lBlocksRuntime -ldispatch --lDispatchStubs -lswiftDispatch --lCoreFoundation -lFoundation -lFoundationNetworking -lFoundationXML -lcurl -lxml2 --luuid -licui18nswift -licuucswift -licudataswift

7:42 AM

moudle.modulemapの定義として該当するのは、DispatchとCoreFoundationですね。 (edited)

Yuta Saito

CoreFoundationはAppleプラットフォーム外ではpublicなAPIではないということになっているので… (edited)

ということは明示的にリンカへオプションを渡すべきってこと？

import Foundation であればリンカオプションなしでリンクできる…はず…

まあビルドしているのはSwiftLintなので、import Foundationはあると思う。

であれば何かがおかしいなぁ

7:46 AM

もしかすると今朝直した問題が原因かもしれない。

swift-autolink-extractはswift-driverのお仕事なのかな。

private deps

swift-autolink-extract はフロントエンドのお仕事ですね

7:49 AM

でもFoundationはswiftinterface無いから今朝のやつとは関係ないか

今のビルド条件だとswift-autolink-extractは5.10.1のやつが使われてるぽいから、mainで直っても恩恵を受けるのは当分先ですよね。

そうですねぇ

これ、swift-sdkのswift.xctoolchain/usr/lib/swift_static/linux/static-stdlib-args.lnkに-lDispatchStubs -lCoreFoundation -luuidを追加することで--static-swift-stdlibでのビルドが通るようになりました。 (edited)

1

8:03 AM

swift-sdk-generatorの成果物に対して、さらに$ cd ubuntu-jammy.sdk/usr/lib; ln -sf aarch64-linux-gnu/ld-linux-aarch64.so.1と合わせて2箇所の修正が必要でした。 (edited)

8:04 AM

GitHub Actionsで再現してみます。

8:06 AM

あいや、手元で作成したswift-sdkがdockerイメージを元にしてるから、M1 runnerで作れないぞ。

1

8:08 AM

swift-sdk-generatorのubuntuパッケージダウンロードが不安定すぎて使いたくない。

8:12 AM

ubuntu runnerでswift-sdkを作って、M1 runnerへswift-sdkをインストールしてubuntu向けバイナリをビルドして、それをubuntuへインストールしてdockerイメージを作るのか？やっぱり、ubuntuでx86_64->aarch64クロスビルドして作ったバイナリでいいのでは。

sdkを作る工程も自分でやろうとするとmacを経由する意味が薄そうですね

あ、公式からダウンロードできるんだっけ？

コンパイラダウンロードの下にsdkのダウンロードリンクもありました (edited)

mainと6.0のSDKが提供されてるのね。 https://www.swift.org/install/linux/ubuntu/22_04/#latest

Swift.org

Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.

まあ、どちらで作っても、aarch64ビルド成果物のGitHub Actionsでの動作確認はarm64 linux runnerが来るまでは出来ない。

8:27 AM

問題が出るとわかってるQEMUでの動作を検知したら警告するか。 (edited)

qemu-user-static検出に使おうと思ってたpmapがswiftlint同様にqemu-user-static環境でクラッシュする。

クラッシュするのはQEMU 9.0.0で直ったバグらしい。 https://gitlab.com/qemu-project/qemu/-/issues/2168

qemu-x86_64: segfault when running grep on arm64 host (#2168) · Iss...

Host environment Operating system: Gentoo OS/kernel version: 6.6.13-gentoo-dist Architecture: ARM64 QEMU flavor: qemu-x86_64 QEMU version:...

ローカルのdockerに入ってるQEMUを、ソースからビルドして9.0.1にしたらクラッシュしなくなった。

いろいろ試して、結局ubuntu-latestのjammyでapt-get install qemu-user-staticして入る6.2を使ったら、11回中3回クラッシュする感じになり、失敗したjobも再実行で通ったりして、とりあえずPRのビルドが全部通った。スッキリしない。 https://github.com/norio-nomura/docker-swiftlint/pull/37 (edited)

Musl使うにはソース変更が必要なのか。 https://www.swift.org/documentation/articles/static-linux-getting-started.html

Swift.org

Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.

docker使ったクロスビルドで、キャッシュが残ったままだと2回目のビルドでautolink-extractが効かない現象に遭遇している気がする。

9:51 AM

似た話をこのサーバーで読んだ気がするけど、見つけられず。

6.0系なら多分昨日のスナップショットで治ってると思います

2:17 PM

これだ https://github.com/apple/swift/issues/74323

[6.0][ModuleInterface] Save -public-autolink-library module optio...

Explanation: Fixes inconsistent swiftmodule compilation issue revealed by recent explicit module improvements Scope: Only affects static-linking scenario Risk: Low; just save/restore an option that...

2:18 PM

https://discord.com/channels/291054398077927425/383442648012423179/1249913718062714930

ありがとうございます。うーん、5.10.1なんですよね。nightly同梱のモノをシンボリックリンクして使えるか試してみようかな。

うーん、もしかするとツールチェインに入ってる.swiftinterfaceにパッチを当てて欠けてるフラグを足せばなんとかなるかも…

ああ、swift-autolink-extractの問題ではなく、取り出す元が原因なのですね。

1

3:30 PM

だとすると、これ https://discord.com/channels/291054398077927425/306246042817396737/1249996996706566185 をするのが良さそう。

3:31 PM

足りないのを/usr/lib/swift_static/linux/static-stdlib-args.lnkに記述する方法

問題が顕在化するのはstatic-stdlibの時だけなのでそれでも十分なはず…！

少し調べてみましたが、.swiftinterfaceにパッチを当てる方法って、FoundationとCoreFoundationの問題には使えない気がする。

11:45 PM

あと、リンクエラーが出るようになったのは、昨日swiftlang/swift:nightlyのdockerイメージ更新されてからで、2回目のビルドとか関係なかったみたい。 (edited)

ホストSwift 6.0でswift build --swift-sdkしてターゲットSwift 5.10のツールチェインを起動して、ホストとターゲットのtripleが同じ時、ホスト用にビルドされる.oとターゲット用にビルドされる.oって、混ざったりしないのかな。 (edited)

ホスト向けビルド: .build/aarch64-unknown-linux-gnu/release/SwiftLintExtraRules-tool.build ターゲット向けビルド: .build/aarch64-unknown-linux-gnu/release/SwiftLintExtraRules.build みたいな感じで混ざらないらしい。

1:56 AM

そしてリンクに失敗するとき、ターゲットの最終成果物をリンクする際にホスト向けビルドの.oを渡していることが判明。失敗して当然だ。 (edited)

リンク成功と失敗で.build/aarch64-unknown-linux-gnu/release/description.jsonを比較してみたところ、swiftlintっていうモジュールが最終ターゲット用とプラグイン用で２つ作られていて失敗する方は中身が入れ替わってた。それに合わせて、.build/release.yamlに記述されるswiftlint.product/Objects.LinkFileListの中身もプラグイン用にビルドされたものが渡されて、結果リンクが失敗するぽい。

7:28 AM

リンク成功と失敗は完全にランダム。

1

ありそうなバグだあ

これは多分、先日のmacOS -> ubuntuのクロスコンパイルでのリンクエラーでも起きていたのではないかと思う。

https://github.com/apple/swift-package-manager/issues/7471 これで治ってるかもしれないがメインブランチにしかまだ入ってない…

おー、今はnightly-6.0-jammyでやってました。 (edited)

7:56 AM

nightlyでも確認してみます。

7:57 AM

とりあえず、Package.swiftからプラグインのモジュール定義を外したらリンク通ることは確認した。

Yuta Saito

https://github.com/apple/swift-package-manager/issues/7471 これで治ってるかもしれないがメインブランチにしかまだ入ってない…

あー、今試してるのホストとターゲットでtriple同じだ。

ありゃ。ホストとターゲット同じでもリンク失敗するのか

nightlyで直ってないです。

なるほど… SwiftPMのリポジトリの方にレポートいただけると

再現は一応こちらのPRで。 https://github.com/norio-nomura/docker-swiftlint/pull/37

1

あー、そのままだと/SwiftLint/.buildが残らないので、残せるように修正します。

更新した。 How to reproduce random link error:

# repeat following until link error occurs docker buildx build --load builder/ --build-arg BUILDER_IMAGE=swiftlang/swift:nightly -t swiftlint:try --target native-builder --no-cache-filter native-builder --progress plain # if link error occurs, keep image with tag docker tag swiftlint:try swiftlint:link-error

How to extract /SwiftLint/.build to link-error directory: mkdir -p link-error; docker run --rm swiftlint:link-error tar czO -C /SwiftLint .build | tar xzvf - -C link-error (edited)

8:37 AM

リンクエラーはaarch64-on-aarch64, x86_64-on-x86_64でランダムで起き、aarch64-on-x86_64, x86_64-on-aarch64では起きません。 (edited)

とりあえず報告とかするには、もっと最低限な再現環境を作るべきかな。

とりあえず手元で試してみてるけど全然ビルドが終わらない

CIで再現までに14m58sとかかかってます。

1

8:52 AM

キャッシュが効いてそれだから、swiftlang/swift:nightlyとswift:5.10ダウンロードとapt-getが入る初回はもっとかかる。

再現手順のdockerコマンドラインオプションに--target native-builderを追加。

9:38 AM

シンプルな再現手順が手元で作れたので、今からアップします。

https://github.com/norio-nomura/poc-module-name-conflict

再現手順の説明を更新しました。

poc-module-name-conflict

How to reproduce random link error:

# repeat following until link error occurs docker buildx build --load . -t poc-module-name-conflict:try --progress plain \ --target builder --no-cache-filter native-builder # after link error occurs, keep image with tag using --target native-builder docker buildx build --load . -t poc-module-name-conflict:try --progress plain \ --target native-builder # if link error occurs, keep image with tag docker tag poc-module-name-conflict:try poc-module-name-conflict:link-error

How to extract /poc-module-name-conflict/.build to link-error directory:

mkdir -p link-error; \ docker run --rm poc-module-name-conflict:link-error \ tar czO -C /poc-module-name-conflict .build | tar xzvf - -C link-error

(edited)

久しぶりにmacOSでdocker起動したら --no-cache-filter が無いと怒られてしまった

む

11:50 AM

lima使ってる。

おーlima

11:52 AM

うーんDocker Desktopをアップデートしても出てこないや

11:52 AM

limaというのでやるか

11:55 AM

違いそうだdockerクライアントというやつをアップデートしないといけないのか

僕のlima on dockerセットアップ 1. install lima brew install lima 2. if docker for mac is not installed, install docker cli brew install docker docker-buildx docker-completion 3. create docker instance

limactl create https://gist.githubusercontent.com/norio-nomura/9f8d469252a13adf2efdc49af0a47a30/raw/a700cc7261f8e782fd0b7c5373ef1201b5158a0d/lima.yaml --tty=false --name docker

4. enable boot dokcer instance at login limactl start-at-login --enabled docker 5. create "lima-docker" context to use docker context create lima-docker --docker host=$(limactl list docker --format 'unix://{{.Dir}}/sock/docker.sock') 6. use "lima-docker" as default context docker context use lima-docker https://gist.github.com/norio-nomura/9f8d469252a13adf2efdc49af0a47a30 (edited)

lima付属のtemplate://dockerに対し

containerd-snapshotterを有効にしてmulti arch build出来るように
buildkitを有効にして、docker buildをdocker buildx buildに

した環境となります。 (edited)

12:14 PM

Docker for MacはRosettaの設定がおかしいので、Swiftを動かすのに使うのはお勧めしません。

ありがとうございますーとりあえず一個目のリンクエラーまでは再現できました

12:21 PM

おー取り出せた取り出せた

1

再現リポジトリで、リンクエラーが再現した.buildと正常にリンクできた.buildをCIのアーティファクトからダウンロード出来るように、明日以降するかもしれません。 (edited)

dockerデバッグ難しいですねぇ

12:45 PM

--mount=type=bind,target=${BUNDLE_PATH}/${TARGET_TRIPLE_ARCH},from=runtime これを維持したままシェルを繋ぎたい

12:51 PM

5.10のコンパイラとmainのSwiftPMでやってるの怪しいなと思ったけどmain mainでも再現しますね

これSwift SDKに関係なく再現するな

お、もっと簡単に再現できそう？

Swift SDKを使わない環境で起きても、入れ替わったモジュールの設定でも問題なく動いてしまうはずだから、気付けなさそう。

とりあえずここまで小さくできました https://github.com/kateinoigakukun/swift-autolink-issue-repro

4:22 PM

10回くらいループ回すと再現する

まずそうなところはわかったぞ

これで治る https://github.com/apple/swift-package-manager/pull/7695

Fix build of host&target destination products with `--static-swift-...

Motivation: Given the following conditions: --static-swift-stdlib is enabled (it only affects "target" destination products, "host" destination products are always dynamic) the...

1

なるほど、クロスじゃなくてもautolink-extractが効かなくてリンクエラーを起こすのか。そしてクロスじゃなければリンカオプションで回避可能なエラーだけだったと。

10:10 PM

そして今回、mainと5.10でマングルが違ったから、リンカオプションでは回避不能なエラーになってたと。

10:13 PM

過去にswiftlintでリンクエラーでオプション追加して回避してたのって、全部これが原因だったのでは。

まだクロス特有の問題があるような気がするんですが一旦これ入れてみて様子見ですね

ほえー

4:03 AM

プラグインのビルドとターゲットのビルドでリンクリストファイルがぶつかってたのか

4:05 AM

分かれてるべきものが混ざる系のバグ、踏み抜くのがややこしくて難しいな

本当はllbuildのマニフェスト作るときに重複したターゲット作ってたらアサーション失敗するべきで、大体のケースはアサーション入ってたんですけど今回のObjects.LinkFileListは漏れてて発見が遅れた。。。 (edited)

そのファイルなんか名前もキモいし悪い子の気配する

4:09 AM

ビルドフォルダ眺めてると浮いてる

えーそうですか？まあレスポンスファイルだし存在が浮いてるのはそう

のりおさんの元の報告のパターンだと深淵すぎそうな雰囲気あったけどこれでも直せるなら、やっぱリビルドされない問題も再現つくろう・・・ (edited)

SwiftPM結構なおせるようになってきた

たのもしい

全然関係ないけどそういえばレスポンスファイルって何でレスポンスファイルって言うんだろう…

Yuta Saito

えーそうですか？まあレスポンスファイルだし存在が浮いてるのはそう

理解してないけど、他のものはいろいろプレフィックスがついてるのに、こいつは固定の名前なの変な感じがする

Windows compiler由来なんだな https://gcc.gnu.org/wiki/Response_Files

4:15 AM

これはリンク単位で一つあればいいのでProductごとにディレクトリ切った下でファイル名は固定でOK (edited)

ふむふむ

そういえば、SwiftPMのlinuxでの動作の疑問なのですが、SwiftLintに#if os(macOS)でbinaryTargetが定義されてるのだけど、linuxでもダウンロードされるのが気になってて。これって意図された動作なのかな。 https://github.com/realm/SwiftLint/blob/3e8a0516b248cfa4f51d7caa321c842013c42572/Package.swift#L166-L174

5:16 AM

ubuntu runnerでダウンロードしてるログ https://github.com/norio-nomura/docker-swiftlint/actions/runs/9610719998/job/26507777159#step:10:442

そのガードは0.55.0には入って無さそうですね https://github.com/realm/SwiftLint/commit/de66fea453ba730a3636328dc5185226c026418d

Completely exclude the binary target from the Linux build (#5585) ·...

なるほど！気づきませんでした。

5:19 AM

ありがとうございます。

Yuta Saito

--mount=type=bind,target=${BUNDLE_PATH}/${TARGET_TRIPLE_ARCH},from=runtime これを維持したままシェルを繋ぎたい

これ僕もやりたくて改めて調べてみましたが、出来なさそう。

5:30 AM

ホスト／コンテナどちらでもいいから、dockerイメージをマウントできる仕組みがあると色々便利そうなんだけどな。

残念

dockerデバッグの道は険しい

なんかこんな感じでどうですかね

w

なるほどw

ttyないからエディタとか使えなかった…… (頑張ればなんとかなりそうではある

sshdを起動しよう

ああ、できた。

ビルドセッションをsleepで止めて、そこへ別のコマンドで入る手順を追加した。 https://github.com/norio-nomura/poc-module-name-conflict

10:40 AM

How to enter docker building session:

Build with SLEEP=1 buildx build --load . --progress plain --build-arg SLEEP=1 Build session will hangs at sleep like following:

#31 0.090 Enter the following command to enter build session: #31 0.090 lima user: #31 0.090 limactl shell docker bash -c 'sudo nsenter --all --target=$(lsns|awk "/^4026532477/{print \$4}") bash' #31 0.090 #31 0.090 Docker for Mac user: #31 0.090 docker run -it --privileged --pid=host --rm ubuntu bash -c 'nsenter --all --target=$(lsns|awk "/^4026532477/{print \$4}") bash'

Copy and paste the command to enter build session.

$ docker run -it --privileged --pid=host --rm ubuntu bash -c 'nsenter --all --target=$(lsns|awk "/^4026532477/{print \$4}") bash' ################################################################ # # # Swift Nightly Docker Image # # Tag: swift-DEVELOPMENT-SNAPSHOT-2024-06-13-a # # # ################################################################ root@buildkitsandbox:/#

(edited)

10:45 AM

簡単に言えばnsenter(1)を使う手法。

10:50 AM

limaのdockerはrootlessだからDocker for Macとは手順が違う。

$ limactl shell docker bash -c 'sudo nsenter --all --target=$(lsns|awk "/^4026532602/{print \$4}") bash' ################################################################ # # # Swift Nightly Docker Image # # Tag: swift-DEVELOPMENT-SNAPSHOT-2024-06-13-a # # # ################################################################ root@buildkitsandbox:/#

norio_nomura

ビルドセッションをsleepで止めて、そこへ別のコマンドで入る手順を追加した。 https://github.com/norio-nomura/poc-module-name-conflict

該当箇所だけgistへ抜き出した。 https://gist.github.com/norio-nomura/edf224977880e6e7598e76b1330f2990 dockerが入っていれば直接ビルドして試せる。 docker buildx build https://gist.github.com/edf224977880e6e7598e76b1330f2990.git --build-arg SLEEP=1

How to attach a shell to a stage during docker buildx build

How to attach a shell to a stage during docker buildx build - Dockerfile

べんりー (edited)

dockerイメージやキャッシュをマウントして使える環境というのが便利かも？

3:46 AM

このアタッチしたシェルでの変更は、RUN --mount=type=cacheのターゲットディレクトリ内ならば、ビルドセッションを跨いでも維持されるのかな？ (edited)

3:51 AM

維持された。 (edited)

次のスナップショットが出るのはいつだろう

基本的に https://ci.swift.org/ のPackageジョブが緑になると出るので

https://ci.swift.org/job/oss-swift-package-trigger/ が全部成功したのって2ヶ月14日前らしいけど、もっと最近出てるから全部成功じゃなくても出る？

最近追加されたやつは成功してなくても出る気がします

1:50 AM

Fedoraとか

なるほど。ありがとうございます。

swift-DEVELOPMENT-SNAPSHOT-2024-07-01-aキタ

やったー

SwiftLintのクロスビルドで起きてたリンクエラーも、対策なしでリンクエラー起きなくなった。>2024-07-01a

おお

ヨシ!

いや、リンクエラー起きた。

む、dockerイメージが更新されてなかった。

swiftlang/swift のイメージであればツールチェーンのリリースとは独立して毎日決まった時間に更新されてる印象がありますね

ボットが更新されてたから勘違いしたけど、ボットは公式dockerイメージ使ってなかった。

スナップショットタグ作成から公式dockerイメージ更新までのタイムラグが気に入らなくて、RELEASE以外は.tar.gzをダウンロードして使うようにしてたの忘れてました。

Nightly Dockerイメージの更新状況 https://ci.swift.org/view/all/job/publish-nightly-main-docker-images-aarch64/

1:47 PM

タグのタイミング関係なく18:00更新ぽい

18時だとその日のスナップショットが作られる前？ (edited)

1:57 PM

外から見てる範囲ではPDT 3:00pmくらいにその日のタグ打つコミットが決まって、PDT 0:00amにビルドが始まって2~3時間でビルドが終わってアップロード、というスケジュールに見える (edited)

ciのID的なのはaarch64だけど、ビルドしてるのはx86_64だった。

2:12 PM

あ、jammyとかはaarch64もビルドしてるか。

ジョブのIDはaarch64だけど全部のプラットフォーム向けのイメージビルドしてるっぽいですね

2:14 PM

ホストマシンのアーキテクチャがaarch64なのかなと思ったけどamd64のbuildxインストールしてた

qemu-user-staticでaarch64のSwift製バイナリを動かすとクラッシュするのだけど、swift -versionしか実行してないから、引っかからないぽい。

例のqemuのバグですか？

うん

自前でビルドしたswift-DEVELOPMENT-SNAPSHOT-2024-07-01-adockerイメージを使って、クロスビルド使った問題再現用プロジェクトのビルドでリンクエラーが起きなくなったことを確認した。

1

norio_nomura

Nightly Dockerイメージの更新状況 https://ci.swift.org/view/all/job/publish-nightly-main-docker-images-aarch64/

CentOS 7のサーバーが落ちてるだけで、CentOS以外のDockerイメージビルドまで止まってしまうのは勘弁してほしい。

9:20 AM

この CI のパイプラインってどこで定義されているんでしょうね？

とりあえずDockerfileが公開されているリポジトリには見当たりませんね。 https://github.com/swiftlang/swift-docker

1

norio_nomura

qemu-user-staticでaarch64のSwift製バイナリを動かすとクラッシュするのだけど、swift -versionしか実行してないから、引っかからないぽい。

ちょっと試しに ci.swift.org のDockerイメージ作成に使われているqemu-user-staticをGitHub Actionsでも使ってみたら、QEMUエミュレーションでaarch64なswiftlintが全くクラッシュしない！ (edited)

2:37 PM

rootful dockerへdocker run --rm --privileged multiarch/qemu-user-static --reset -p yes使ってインストールする方法。 (edited)

2:40 PM

docker/setup-qemu-action、ubuntuやdebianからaptで配布されてるモノ、qemuのソース取得してビルドする、とか色々試してダメだったのに。

rootless dockerでも使うためにmultiarch/qemu-user-staticがインストールしているバージョンを調べたらdebian bookwormで使われてた7.2で、ubuntuでは使われていないバージョンだった。ちなみにubuntuでのqemu-user-staticは focal: 4.2 jammy: 6.2 mantic: 8.0 noble: 8.2 で、僕が試してダメだったのは 6.2, 8.0, 8.2, 9.0.1(自前ビルド)

swift-6.0-DEVELOPMENT-SNAPSHOT-2024-07-02-aにリンクエラー対策パッチがチェリーピックされてて swiftlang/swift:nightly-6.0-jammy も更新されてたので、対策なしでリンクエラーが起きないことも確認した。

GitHub Actions Runner ubuntuにqemu-user-staticを、ubuntuパッケージ, debianパッケージ, tonistiigi/binfmt, multiarch/qemu-user-static の各バージョンをインストールして、arm64版swiftlintを2回動作確認で起動するDockerfileを10回ビルドし、クラッシュやハングアップしないかテストしてみた。 https://github.com/norio-nomura/compare-qemu-user-static/actions/runs/9856830637 (edited)

12:57 PM

ubuntu-22.04のデフォルト, tonistiigi/binfmt:latest はダメで、multiarch/qemu-user-static:latestは通る。

おおむね7.2.0以降は通ってるけど、新しめのバージョンはpthread周りでクラッシュするバグが9.0.1でなおったとかあるはずだから注意。

1:39 PM

個人的にはaarch64版Swiftツールチェインをaarch64エミュレーションで動かしSwiftLintのビルドを通せたdebian bookwormの7.2.0系が推し。

dockerイメージnorionomura/swiftlintにaarch64追加した。そしてqemu-user-staticのバージョンによりクラッシュ回避する情報をforumへ投稿した。 https://forums.swift.org/t/swift-runtime-unable-to-suspend-thread-when-compiling-in-qemu/67676/20

swift-runtime: unable to suspend thread when compiling in QEMU

To add an aarch64 image to the Docker image norionomura/swiftlint, I encountered an issue while creating an aarch64 executable using the x86_64 version of the Swift Toolchain on GitHub Actions' ubuntu-latest. The final verification step was to use aarch64 emulation with qemu-user-static, where the issue arose. This issue occurs not only with the...

2

norio_nomura

CentOS 7のサーバーが落ちてるだけで、CentOS以外のDockerイメージビルドまで止まってしまうのは勘弁してほしい。

こっちの件も CentOS 7 のジョブが削除されて解決したっぽいですね． https://ci.swift.org/view/all/job/publish-nightly-main-docker-images-aarch64/

1

Rosetta for LinuxのAOT Cachingってのを試してみたら、Cachingなしの時よりも遅くなった。使うための条件がなかなか厳しくて、色々工夫が必要だったのに残念。

OpenCVをリンクするとLinuxのSwift5.10でargvが読めなくなるって現象に遭遇しているのですが何か分かる方いますか‥？ Swift5.9では読めてたのでargvをメモリ直読みになった影響かと思ってますが、その先がわからず。最小再現はこちらです https://github.com/t-ae/empty-args-test

https://github.com/swiftlang/swift/blob/afe1fa0c09ff240756bd3e15d3e441bc4a71e776/stdlib/public/CommandLineSupport/CommandLine.cpp#L319 追跡したらここに侵入してるところまでわかった environっていう環境変数ポインタが意図しない場所にある？ setenvとかを使うとずれてしまうことがあるらしい？

9:21 AM

***GRABBING ARGV for 5534*** envp = 0xaaaaffb21da0, stack is from 0xffffebec0000 to 0xffffebee1000 ARGV is at (nil) with count 0 ***ARGV GRABBED***

setenvを使うとenvironが大きくずれることはわかったけど、自前でsetenvを_swift_stdlib_getUnsafeArgvArgcよりも先に呼び出す方法がわからなくてうまく再現できない

attribute((constructor))でsetenvしてんのかな

おおなんか悪そうなテクニックだ

cxxのコンストラクタセクションに登録させるリンカ向けのアトリビュート

自前のC++コードにそれ書いても負けちゃう（先にSwiftの_swift_stdlib_getUnsafeArgvArgcが呼ばれてそう？）なぁ

明示的に呼び出さなくてもロードされてるイメージに含まれてるとglibcが呼んでくれるはず

9:46 AM

うーん、少なくともmainよりは先に呼ばれるはずなんだけどなぁ

https://github.com/swiftlang/swift/blob/0cbf541194159e0576548a0f2b9bf41bf16ef631/stdlib/public/core/CommandLine.swift#L35 こいつがmainより先に評価されてるって可能性はありますか？

9:49 AM

こいつに勝たないといけない

そこは最初のアクセスでレイジーに評価されるはず (edited)

実はSwift自体の初期化部分でしれっと触ってるとかないかなぁ

9:50 AM

まあSwiftが動いてる時点でC++部分の初期化は全部終わってるだろうから結局負けそうだけど

C++側どう書いてます？

9:51 AM

こういう感じで、AppCモジュールをAppターゲットがimportする形にしてます

良さそうに見える。あと確認するのはinit_arrayセクションがexecutableに生成されてるか、かなぁ

a.cppの中にhttps://github.com/swiftlang/swift/blob/afe1fa0c09ff240756bd3e15d3e441bc4a71e776/stdlib/public/CommandLineSupport/CommandLine.cpp#L231 のArgvGrabberのコピペ実装を置いていて、そっちはsetenvのあとに呼び出されていい感じに壊れるんですよね

9:56 AM

ただCommandLine.argumentsで出てくるSwift標準ライブラリのArgvGrabberは正しい結果を返していて、うまく再現できない

あー、libswiftCoreのctor関数だけが先に呼ばれちゃってるのか

9:56 AM

つまりどのイメージにctorがあるかが重要？

9:57 AM

AppCをdynamic libraryにするとどうですかね

9:57 AM

ctorがsoに含まれるようにしつつ。

簡単にdynamicにする方法ありましたっけ

無い気がする…

1

10:01 AM

いや、ctorを含んだ.soはCで書くだけだから普通にclang -dynamic的なやつで作ればいいか

dynamicにしてみたけ変わらない気がする？

ムズイ

ダイナミックライブラリのロード順が絡んでるのかw

こういう感じにしたらlibBadLib.soができたのでdynamicになったっぽい

プロダクトがsoになってるだけでターゲット間のリンクは静的なままになってたりしません？

10:05 AM

あ、新しいパッケージか

root@36e7be3c11c2:/empty-args-test# swift run Building for debugging... [10/10] Linking App Build complete! (0.41s) 😈 use 'setenv' in static constructor a.cpp: ***GRABBING ARGV for 6756*** a.cpp: envp = 0xaaaaf3b8a940 a.cpp: envp = 0xaaaaf3b8a940, stack is from 0xffffd25d0000 to 0xffffd25f1000 ARGV is at (nil) with count 0 // ←自前実装のArgvGrabberは壊れてる a.cpp: ***ARGV GRABBED*** Hello, World! CommandLine.arguments: [".build/aarch64-unknown-linux-gnu/debug/App"]　// ←SwiftStdLibのほうはうまく動いてる

OpenCVの再現環境でsetenvにブレーク貼ってみて誰がsetenvしてるか調べたいな

1

(lldb) bt * thread #1, name = 'App', stop reason = breakpoint 1.1 2.1 * frame #0: 0x0000fffff5adc9f4 libc.so.6`__setenv(name="ZES_ENABLE_SYSMAN", value="1", replace=1) at setenv.c:255:6 frame #1: 0x0000fffff7fc7624 frame #2: 0x0000fffff7fc772c

10:12 AM

でねぇ〜

クソー

ZES_ENABLE_SYSMANとかいう怪しい文字列は得られた

露骨に怪しい

image lookup -a <addr>でそのフレームのpcが含まれるイメージ出ませんか？

こうですか？

(lldb) image lookup -a 0x0000fffff58ac9f4 Address: libc.so.6[0x000000000003c9f4] (libc.so.6.PT_LOAD[0]..text + 88500) Summary: libc.so.6`__setenv at setenv.c:255:6

あ、そうです。それを親のフレームに対してやるとどうかなと

https://spec.oneapi.io/level-zero/latest/sysman/PROG.html

(lldb) breakpoint set -n setenv Breakpoint 1: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. (lldb) run Process 7724 launched: '/empty-args-test/.build/debug/App' (aarch64) 1 location added to breakpoint 1 Process 7724 stopped * thread #1, name = 'App', stop reason = breakpoint 1.1 frame #0: 0x0000fffff58ac9f4 libc.so.6`__setenv(name="ZES_ENABLE_SYSMAN", value="1", replace=1) at setenv.c:255:6 (lldb) bt * thread #1, name = 'App', stop reason = breakpoint 1.1 * frame #0: 0x0000fffff58ac9f4 libc.so.6`__setenv(name="ZES_ENABLE_SYSMAN", value="1", replace=1) at setenv.c:255:6 frame #1: 0x0000fffff7fc7624 frame #2: 0x0000fffff7fc772c (lldb) image lookup -a 0x0000fffff7fc7624 (lldb) image lookup -a 0x0000fffff7fc772c (lldb)

10:17 AM

なんもでないですね・・・

ざんねん

(lldb) breakpoint set -n setenv Breakpoint 1: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. (lldb) breakpoint set -r '^\$ss11CommandLine.*' Breakpoint 2: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. (lldb) run Process 8380 launched: '/empty-args-test/.build/debug/App' (aarch64) 17 locations added to breakpoint 2 1 location added to breakpoint 1 Process 8380 stopped * thread #1, name = 'App', stop reason = breakpoint 1.1 frame #0: 0x0000fffff58ac9f4 libc.so.6`__setenv(name="ZES_ENABLE_SYSMAN", value="1", replace=1) at setenv.c:255:6 (lldb) c Process 8380 resuming :smiling_imp: use 'setenv' in static constructor Process 8380 stopped * thread #1, name = 'App', stop reason = breakpoint 1.1 frame #0: 0x0000fffff58ac9f4 libc.so.6`__setenv(name="FOO", value="BAR", replace=1) at setenv.c:255:6 (lldb) c Process 8380 resuming a.cpp: ***GRABBING ARGV for 8380*** a.cpp: envp = 0xaaaaaafee220 a.cpp: envp = 0xaaaaaafee220, stack is from 0xfffffffdf000 to 0x1000000000000 ARGV is at (nil) with count 0 a.cpp: ***ARGV GRABBED*** Hello, World! Process 8380 stopped * thread #1, name = 'App', stop reason = breakpoint 2.10 frame #0: 0x0000fffff7c20dec libswiftCore.so`$ss11CommandLineO9argumentsSaySSGvgZ libswiftCore.so`$ss11CommandLineO9argumentsSaySSGvgZ: -> 0xfffff7c20dec <+0>: stp x29, x30, [sp, #-0x10]! 0xfffff7c20df0 <+4>: adrp x0, 795 0xfffff7c20df4 <+8>: add x0, x0, #0x60 0xfffff7c20df8 <+12>: adrp x1, 0

main.swiftの中が走るまでの間にCommandLineに誰も触ってないな・・・

あ、違うか。StdLibのArgvGrabberはそれ自体も状態を持ってるからCommandLineの呼び出しに関わらずargvを保持してるわ

readelf使ってArgvGrabberのシンボルがないか調べても綺麗に消えてるのでlldbでブレークできない

11:36 AM

これはいよいよDEBUG_ARGVGRABBERをセットしてstdlibを自前でビルドする必要が・・・

ようやく壊し方がわかった --static-swift-stdlibしたらstdlibより先に自前コードのコンストラクタセクションが開始されてそこでsetenvすれば壊せる（dynamicにして壊せなかったのは、SwiftPMのdynamic libという時点でlibSwiftCoreの依存が自動で追加されてそっちが先にinitされるため。clang単体でやれば変わったかも） (edited)

自前コードのほうが先なのは偶然だろうけど、同一バイナリ内なら__attribute__((constructor(0)))とかすれば誤魔化せそう

https://github.com/swiftlang/swift/issues/76080 回答もらえた。これはコンストラクタセクションで変なことしてるほうが悪いということで、ワークアラウンドを提案してくれた。

If you run your program with ZES_ENABLE_SYSMAN=1 already set, that should work, I believe.

へえ～・・・ｗ

Swift Package Manager plugin for building container images 外部ツールに頼らずOCIイメージを作ってregistryへ登録できるぽい？ https://github.com/apple/swift-container-plugin

GitHub - apple/swift-container-plugin: Swift Package Manager plugin...

Swift Package Manager plugin for building container images - apple/swift-container-plugin

手元でビルドしたバイナリをswift:slimの中にポンと放り込んでくれるっぽい？

Musl SDK でビルドするなら swift:slim じゃなくて scratch をベースイメージにしても動いたりしないんだろうか？と気になりました (edited)

@swift-6.0.3 -swift-version 6 import Foundation fflush(stdout)

Iceman

@swift-6.0.3 -swift-version 6 import Foundation fflush(stdout)

exit status: 1 with

<stdin>:2:8: error: reference to var 'stdout' is not concurrency-safe because it involves shared mutable state 1 | import Foundation 2 | fflush(stdout) | `- error: reference to var 'stdout' is not concurrency-safe because it involves shared mutable state 3 | SwiftGlibc.stdout:1:12: note: var declared here 1 | public var stdout: UnsafeMutablePointer<FILE>! | `- note: var declared here

こういう、定義側でvarになってるグローバル変数を黙らせながら使ういい方法ありますか？って思ったけど@preconcurrencyでよかった

Swift 6.0 になってから Linux だと swift-format が .swift-format がないディレクトリで実行した場合に動かなくなったなとおもっていたのですが，どうやら設定ファイルを探す処理で無限ループしていたみたいです． macOS では問題ないので Foundation の URL の挙動の違いが原因だったようです． https://github.com/swiftlang/swift-format/issues/694#issuecomment-2397669986 (edited)

1

それ例の swift-foundation の URL のせいだな

なんかうっすら記憶の彼方にあったんですがやっぱりそこで繋がるんですね

そもそも deletingLastPathComponent() の単体テストって String に対してはあるけれど，URL に対してのテストコードは一切無いんですね．

1

3:10 PM

https://github.com/swiftlang/swift-foundation/blob/5141cf69577f26cdbabd65f6b12ff643b93f4685/Tests/FoundationEssentialsTests/DataIOTests.swift#L255

https://github.com/swiftlang/swift-foundation/pull/969

[6.0.x] URL path bug fixes by jrflat · Pull Request #969 · swiftl...

Explanation: Fixes various URL path API behaviors to match the expected behavior from before the Swift URL implementation: Drops trailing slashes from URL.fileSystemPath and URL.path Strips traili...

5:26 PM

修正進みそう

確かにそれって main ではマージされてますが，main の nightly では URL(filePath: "/foo", directoryHint: .isDirectory).deletingLastPathComponent().path() が "/" になりました．

/foo から一つ登ったら/になるのは前からそうだったような？

6.0 ではそうじゃありません https://github.com/swiftlang/swift-format/issues/694#issuecomment-2397669986

Formatting not working on Windows · Issue #694 · swiftlang/swift-fo...

The formatting does not seem to work properly when compiled on Windows. The compilation went smoothly, however, when used as CLI as well as together with vscode formatter, the behavior is incorrect...

1

fooから登ったら./になってほしいのに空になるのが困り

kebo

6.0 ではそうじゃありません https://github.com/swiftlang/swift-format/issues/694#issuecomment-2397669986

/fooの上が空はヤバいですね

9:51 AM

どういう感覚だ

swift-format は "/" が来るまで上に登って設定ファイルを探索してたのでいつまでも来なくて無限ループしてました (リリース版のツールチェーンに同梱のバージョンが) (edited)

なるほどそれめっちゃ踏みやすいバグになってそう？

9:54 AM

登って見つからないケースで無限ループですよね

macOS で動かす人は踏まないのと，.swift-format がすでにあるディレクトリでしか実行しない人は踏まないので，踏む環境は限られると思いますがハマる人はめっちゃ踏みやすいですね． (edited)

/fooの上が空はヤバいですね

少し前にMakefileの変数でrelativePathを作る方法を調べてて、参考にしたコードに含まれるdirnameが同じ動作をしてたのを思い出した。はまりがちな罠なのかな。 override define dirname $(patsubst %/,%,$(dir $(patsubst %/,%,$1))) endef $(info dirname: $(call dirname,/foo)) test: $ make test dirname: make: Nothing to be done for `test'. (edited)

どうやら / の上が /.. になる環境もあるらしくて，その環境での無限ループを修正するために /foo の上が空になる環境 (Linux の Swift 6.0) でまた無限ループが再発してしまった... この辺は連鎖的に問題が起こっていて大変そうですね... https://github.com/swiftlang/swift-format/pull/845

Fix infinite looping if swift-format is run in a directory that doe...

#802 this sort of infinite looping issue on Windows but introduced it on Unix platforms where URL.deletingLastPathComponent on / returns /...

これは大変そう・・・

issue を立てたら (あくまで応急措置的な修正ですが) サクッと修正してもらえました． https://github.com/swiftlang/swift-format/issues/847

swift-format causes a infinite loop on Linux if .swift-format is ...

Description On Linux, when all ancestor directories do not have .swift-format, swift-format causes a infinite loop. swift-format lint and swift-format format do not work. Steps to reproduce Please ...

norio_nomura

qemu-user-staticでaarch64のSwift製バイナリを動かすとクラッシュするのだけど、swift -versionしか実行してないから、引っかからないぽい。

最近 github.com/kkebo/zyphy のリポジトリの swift test を aarch64 Linux の実機で実行するとクラッシュもしくはカーネルごとハングするので qemu-user-static の問題と関連していたりしないか気になってます． Fedora 40 (Asahi Linux) だとシェルごとクラッシュして，Raspberry Pi OS (Debian 12) だとカーネルごとハングしてマシンごと強制再起動するしかなくなります．どちらも aarch64 Linux です．x86_64 Linux 環境だと今のところ同じ条件でもこのような問題が起きたことはないです．aarch64 Linux 環境でもこのリポジトリの swift test 以外で同じ Swift ツールチェーンを使っている上では何も問題が起こったことがないです．

2:25 AM

たまに再現しないことがあったり条件の切り分けもまだ全然できていないので (以前の問題と関連があるかどうかは) もしかしてくらいのレベルですが． (edited)

Docker Hub にある Swift の公式イメージ，jammy から noble に上がって xz がプリインストールされなくなってますね．(一部の GitHub Actions が壊れて気づいた)

arm64のDockerイメージ内でだけ Process.waitUntilExit() がハングするんですがそんなことってあります？

import Foundation let process = Process() process.executableURL = URL(fileURLWithPath: "/bin/sh") process.arguments = ["-c", "echo 'Hello, World!'"] let stdout = Pipe() process.standardOutput = stdout try process.run() let stdoutData = stdout.fileHandleForReading.readDataToEndOfFile() let stdoutString = String(data: stdoutData, encoding: .utf8)! process.waitUntilExit() // <- ここで固まって先に進まない print(stdoutString)

(edited)

1

3:37 AM

waitUntilExit の前に while process.isRunning {} するだけで通るようになるのも謎

417_72ki

arm64のDockerイメージ内でだけ Process.waitUntilExit() がハングするんですがそんなことってあります？

import Foundation let process = Process() process.executableURL = URL(fileURLWithPath: "/bin/sh") process.arguments = ["-c", "echo 'Hello, World!'"] let stdout = Pipe() process.standardOutput = stdout try process.run() let stdoutData = stdout.fileHandleForReading.readDataToEndOfFile() let stdoutString = String(data: stdoutData, encoding: .utf8)! process.waitUntilExit() // <- ここで固まって先に進まない print(stdoutString)

(edited)

Sandbox(amd64?)は動いた https://discord.com/channels/291054398077927425/430242233468452865/1320957087957651528

Swift botをSwiftで書いてた頃、実行環境の自前ビルドSwiftツールチェイン入りDockerイメージのubuntuを16.04から18.04へバージョンアップしたら、waitUntilExit()がハングアップするようになって、16.04へ戻したことがある。 (edited)

1

調べたら2019/4/1でswift-5.0-RELEASEの時だった。まあ今でも実行環境により動かなくなる実装になっててもおかしくはない？

ちなみに、そのころのbotはherokuでubuntu:16.04、今のbotはrenderでubuntu:22.04

https://forums.swift.org/t/can-you-dynamically-link-swift-libraries-on-linux/77442

Can You (Dynamically) Link Swift Libraries on Linux?

this is something that has bedeviled generations and generations of Swift Developers for hundreds of years! SwiftPM and dynamic linking Use a dynamic library in a swift package on Linux Swift shared libraries as plugins Dynamic library support on Linux with library evolution · Issue #5714 · swiftlang/swift-package-manager · GitHub in this threa...

12:15 PM

swiftpmでLinuxで後から差し替え可能なダイナミックライブラリをビルド・リンクできるようにしようとしてるらしいお試し実装ももうある

12:16 PM

これによりサーバーサイドSwiftなどで、巨大なライブラリレイヤーを固定して、アプリケーションレイヤーだけダイナミックにして差し替えできるようにすることで、開発サイクルを早めるなどが検討されてる

12:18 PM

サーバーサイドのdeployにめっちゃ時間かかるから気になるけどdocker image作る場合だとその辺は同じ事かなあ

アプリケーションレイヤーというより想定してるのはサービスの中のカスタム部分みたいな感じか

とりあえずxcframework的なものはほしいですね

それがartifactbundleっぽい

1:01 AM

so ファイルを手で入れるみたいだけど

artifactbundleってexecutableなものしか入れられないと思ってたけどライブラリも入れられるんですね

https://github.com/swiftlang/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md

1:12 AM

SE-0305でartifactbundleが提案されてるんだけど、Apple platformにはxcframeworkがあるけど、他のところにはないからSwiftPMのためのxcframeworkが必要だ、というモチベーションになってる。

逆にこれあればxcframeworkいらなくない・・・？

基本的にはそうだけど、Appleが勝手に新しい仕組みを追加したりしやすいようにxcframeworkは残りそう

artifactbundleはSwiftSDKにも使われてる。

1

確かに。

https://github.com/swiftlang/swift-package-manager/pull/8249 このPRでartifactbundleでもlibraryが使えるようになるという話か

Support dynamic linking on Linux via Artifactbundles by tayloraswif...

proof-of-concept for enabling self-managed dynamic library dependencies on Linux! Motivation: see Forums discussion, #5714 Modifications: adds an ArtifactType called “library”, which can be used i...

ああ結局そういう事なのか。

LinuxでのmacOS向けクロスコンパイルとか、まだできないのかな？

4:25 AM

Linuxでのクロスアーキテクチャは調べて試したけど、クロスプラットフォームは調べてないや。

試したことないけど一応こういうのがあります https://github.com/kabiroberai/swift-sdk-darwin

GitHub - kabiroberai/swift-sdk-darwin: Darwin Swift SDK for Linux (...

Darwin Swift SDK for Linux (experimental). Contribute to kabiroberai/swift-sdk-darwin development by creating an account on GitHub.

1

4:27 AM

lldで本当にちゃんと動くのかはわからない

Xcodeの中に入ってるiOS SDKをLinuxマシンのツールチェーンにブッ込めば理屈上いけるの？ (edited)

4:28 AM

リンカーがダメな可能性があるのか。

https://github.com/kabiroberai/darwin-tools-linux-llvm を使うみたいですね

GitHub - kabiroberai/darwin-tools-linux-llvm

Contribute to kabiroberai/darwin-tools-linux-llvm development by creating an account on GitHub.

1

4:43 AM

artifactbundleがあった https://github.com/kabiroberai/swift-sdk-darwin/releases

手元でテスト用のbotにそのSwiftSDKを入れようとしてるんだけど、docker compose up --buildが30分経っても終わらない

botのCLIでどうやってSwiftSDKを使わせたら良いのだろう。

とりあえず、Linux上で swift package init --type executable して swift build --swift-sdk arm64-apple-macosx --product test で作成したtestがmacOS上で動くところまで確認できたけど、botに使わせるのはかなりハードルが高いな。

そうか、実行させるのはどうしようもないか

swift build --swift-sdkが生成するコマンドラインを、botのCLIへ渡す必要がある。

6:06 AM

実行できなくてもビルドが通るだけで価値がありそうだけど

1

それもそうか

実行は手元でやればいいし・・・

6:09 AM

新しいコンパイラでビルドできるかどうかがbotでわかったらそれだけで便利

swift build --verbose --swift-sdkで観測できる、生成されるfrontendへのコマンドラインオプションをコピーしてbotのCLIへ渡そうとすると、Discordのメッセージ長制限に引っかかる。

あ、ちなみにswift build --swift-sdkは、最後codesignしようとしてcodesignがなくて失敗する。

あー、ビルドだけならいけるかも。

6:31 AM

というかテストbotでいけた。

6:31 AM

import SwiftUIもいける

6:36 AM

新しいbot作ればいけるかも？需要的にはやはりiOSのコードをビルドできた方が良いのかな？

新しいコンパイラでビルドできるかどうかがbotでわかったらそれだけで便利

全てのbotで--swift-sdk相当のオプションを暗黙で渡せるようにするのは現状では難しいです。特定バージョンのコンパイラに最新SDKの組み合わせが常に使われるbotを別途用意するのはできるかも？ってところ。

コンパイラバージョンとSDKバージョンの組み合わせになるのが大変なんですね。

例えばmacOS向けだと、とりあえず以下のようなオプションが必要だった。 (不要なものもあるかもしれないけど)

-target arm64-apple-macosx15.0 -Onone -resource-dir /home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift -color-diagnostics -swift-version 6 -sdk /home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk -use-ld=lld -Xfrontend -tools-directory -Xfrontend /home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/toolset/bin -sdk /home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk -ld-path=/home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/toolset/bin/ld64.lld -g -Xcc -isysroot -Xcc /home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk -Xcc -g -I /home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Platforms/MacOSX.platform/Developer/usr/lib -

7:31 AM

swift buildが--swift-sdkオプションの指定で上記オプションを生成する部分が、botが利用しているswiftには存在しないので、この面倒をみないと簡易にSwiftSDKを切り替えられる様にはできない。 (edited)

7:37 AM

あれ？そんな難しくないかも。

クロスビルドが遅すぎて、renderで動くbotだとまともに応答が返ってこないかも。 @swift-6.0.3 macos -version -v (edited)

norio_nomura

クロスビルドが遅すぎて、renderで動くbotだとまともに応答が返ってこないかも。 @swift-6.0.3 macos -version -v (edited)

/usr/bin/swift-frontend --version Swift version 6.0.3 (swift-6.0.3-RELEASE) Target: x86_64-unknown-linux-gnuTarget: x86_64-apple-macosx15.2 Swift version 6.0.3 (swift-6.0.3-RELEASE) Target: x86_64-apple-macosx15.2 (edited)

@swift-6.0.3 ios-macabi -v import SwiftUI (edited)

norio_nomura

@swift-6.0.3 ios-macabi -v import SwiftUI (edited)

execution timeout with stdout:

/usr/bin/swift-frontend -frontend -interpret - -target x86_64-apple-ios18.2-macabi -enable-objc-interop -sdk /home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk -I /home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Platforms/MacOSX.platform/Developer/usr/lib -tools-directory /home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/toolset/bin -empty-abi-descriptor -resource-dir /home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift -Xcc -isysroot -Xcc /home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk -module-name main -target-sdk-version 18.2 -target-sdk-name macosx15.2 -prebuilt-module-cache-path /home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/prebuilt-modules -external-plugin-path '/home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Platforms/MacOSX.platform/Developer/usr/lib/swift/host/plugins#/home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Platforms/MacOSX.platform/Developer/usr/bin/swift-plugin-server' -external-plugin-path '/home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Platforms/MacOSX.platform/Developer/usr/local/lib/swift/host/plugins#/home/bot/.swiftpm/swift-sdks/darwin.artifactbundle/Developer/Platforms/MacOSX.platform/Developer/usr/bin/swift-plugin-server' -plugin-path /usr/lib/swift/host/plugins -plugin-path /usr/local/lib/swift/host/plugins

Target: x86_64-apple-ios18.2-macabi Swift version 6.0.3 (swift-6.0.3-RELEASE) Target: x86_64-apple-ios18.2-macabi (edited)

だめだこりゃ

@swift-6.0.3 musl #if canImport(Musl) print("Hello, Musl!") #endif

norio_nomura

@swift-6.0.3 musl #if canImport(Musl) print("Hello, Musl!") #endif

Hello, Musl!Target: x86_64-swift-linux-musl

@swift-6.0.3 sdk configure --show-configuration swift-6.0.3-RELEASE_static-linux-0.0.1 x86_64-swift-linux-musl (edited)

norio_nomura

@swift-6.0.3 sdk configure --show-configuration swift-6.0.3-RELEASE_static-linux-0.0.1 x86_64-swift-linux-musl (edited)

sdkRootPath: /home/bot/.swiftpm/swift-sdks/swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle/swift-6.0.3-RELEASE_static-linux-0.0.1/swift-linux-musl/musl-1.2.5.sdk/x86_64 swiftResourcesPath: /home/bot/.swiftpm/swift-sdks/swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle/swift-6.0.3-RELEASE_static-linux-0.0.1/swift-linux-musl/musl-1.2.5.sdk/x86_64/usr/lib/swift_static swiftStaticResourcesPath: /home/bot/.swiftpm/swift-sdks/swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle/swift-6.0.3-RELEASE_static-linux-0.0.1/swift-linux-musl/musl-1.2.5.sdk/x86_64/usr/lib/swift_static includeSearchPaths: not set librarySearchPaths: not set toolsetPaths: ["/home/bot/.swiftpm/swift-sdks/swift-6.0.3-RELEASE_static-linux-0.0.1.artifactbundle/swift-6.0.3-RELEASE_static-linux-0.0.1/swift-linux-musl/toolset.json"]

(edited)

@swift-6.0.3 @swift-6.1.3 @swift-main musl import Musl print("Hello, Musl!")

norio_nomura

@swift-6.0.3 @swift-6.1.3 @swift-main musl import Musl print("Hello, Musl!")

exit status: 1 with

Target: x86_64-swift-linux-musl <unknown>:0: error: compiled module was created by an older version of the compiler; rebuild 'Swift' and try again: /home/bot/.swiftpm/swift-sdks/swift-DEVELOPMENT-SNAPSHOT-2025-01-05-a_static-linux-0.0.1.artifactbundle/swift-DEVELOPMENT-SNAPSHOT-2025-01-05-a_static-linux-0.0.1/swift-linux-musl/musl-1.2.5.sdk/x86_64/usr/lib/swift_static/linux-static/Swift.swiftmodule/x86_64-swift-linux-musl.swiftmodule

norio_nomura

@swift-6.0.3 @swift-6.1.3 @swift-main musl import Musl print("Hello, Musl!")

Hello, Musl!Target: x86_64-swift-linux-musl

norio_nomura

@swift-6.0.3 @swift-6.1.3 @swift-main musl import Musl print("Hello, Musl!")

Hello, Musl!Target: x86_64-swift-linux-musl

mainのStatic Linux SDKはかなり古い。 (edited)

Static Linux SDKの6.1スナップショットが壊れてる。 [https://download.swift.org/swift-6.1-branch/static-sdk/swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a/swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a_static-linux-0.0.1.artifactbundle.tar.gz] checksumは壊れたものに一致してて役立たずだった。

$ curl -fLsS https://download.swift.org/swift-6.1-branch/static-sdk/swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a/swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a_static-linux-0.0.1.artifactbundle.tar.gz -O $ sha256 swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a_static-linux-0.0.1.artifactbundle.tar.gz SHA256 (swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a_static-linux-0.0.1.artifactbundle.tar.gz) = c701d3f5bb69464fd443f20c4748cab068c9c6d8f6995f1ba5be70022778d21f $ cat swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a_static-linux-0.0.1.artifactbundle.tar.gz <?xml version="1.0" encoding="UTF-8" standalone="no"?><Error><Code>404</Code><Message>No message</Message><RequestId>7e2efc3d-e9a6-48be-935e-8c25252d5475</RequestId></Error>

botの自動更新でインストールが失敗してて気づいた。手元でも失敗。

$ swift sdk install --checksum c701d3f5bb69464fd443f20c4748cab068c9c6d8f6995f1ba5be70022778d21f https://download.swift.org/swift-6.1-branch/static-sdk/swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a/swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a_static-linux-0.0.1.artifactbundle.tar.gz Downloading a Swift SDK bundle archive from `https://download.swift.org/swift-6.1-branch/static-sdk/swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a/swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a_static-linux-0.0.1.artifactbundle.tar.gz`... Downloading 100% [=====================================================================================================] Downloading swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a_static-linux-0.0.1.artifactbundle.tar.gz Swift SDK bundle archive successfully downloaded from `https://download.swift.org/swift-6.1-branch/static-sdk/swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a/swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a_static-linux-0.0.1.artifactbundle.tar.gz`. Verifying if checksum of the downloaded archive is valid... Downloaded archive has a valid checksum. Swift SDK bundle at `https://download.swift.org/swift-6.1-branch/static-sdk/swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a/swift-6.1-DEVELOPMENT-SNAPSHOT-2025-03-12-a_static-linux-0.0.1.artifactbundle.tar.gz` is assumed to be an archive, unpacking... Error: tar: Error opening archive: Unrecognized archive format

8:28 AM

チェックサムが通った上でインストールに失敗するケースは想定してなかった

手動でコミットされているんですね．しかもよくみたら .sig のファイル名も -a がダブっていて間違ってそうですね... https://github.com/swiftlang/swift-org-website/commit/018ca4354ef294a4d6fd74418f1cb7b97908b7b9 https://github.com/swiftlang/swift-org-website/commit/b6509e838d3f75c7d7b592fd43359bf40f6004ad リリースフローが手作業なのかもしれませんね．

まさにそこへコメントを~~書こうとしてた。~~書いた。 (edited)

反応なかったからissue起こした。 [https://github.com/swiftlang/swift-org-website/issues/931]

Nightlyのツールチェインをダウンロードしてgpgでシグネチャ検証時、鍵 [https://swift.org/keys/all-keys.asc] をダウンロードする。この時curlでAccept-Encoding: ...を渡していないのにたまにContent-Encoding: gzipで返されて、鍵のインポート時にエラー gpg: no valid OpenPGP data found. で失敗してた。 curlで明示的に--compressedを使うことでエラー回避。

これですね https://github.com/swift-actions/setup-swift/issues/591

Unexpected error, unable to continue. Please report (gpg: no valid ...

Describe the bug Please see this report Workflow configuration (please complete the following information): Action version (uses): swift-actions/setup-swift@v1 Platform (runs-on): ubuntu-latest Swi...

結構前から起きてたのね

3:25 AM

今までサーバーガチャ運が良かったのか。

3:27 AM

解決策わかってるのにopenのままなのね。

swiftのサブコマンド追加、macOSだとPATHが通ってればどこに置いても良いけど、Linuxだとswiftと同じディレクトリしか認識しない。

これずっと困ってるけど対策入らなくて謎

ここでCommandLine.arguments[0]がAbsolutePathだとそのパスのディレクトリ決め打ちになる。 [https://github.com/swiftlang/swift-driver/blob/8cbf26f4024d333cc5108403d08f8dd07048141f/Sources/swift-driver/main.swift#L125]

確かにフルパスだったら明確にその隣のやつになってほしい気持ちもわかるな・・・

Linuxでもarguments[0]はフルパスじゃなかったから、その条件は関係ないみたい。

1

swift-driverをmacOSでビルドして実行すると、Linux同様swiftと同じディレクトリからしか見つけてくれない macOSでPATHが通ってればサブコマンドが動く動作は、もしかしてmacOSの/usr/bin/swiftがswift-driverとは関係なく、勝手にやってる動作なのでは (edited)

norio_nomura

Nightlyのツールチェインをダウンロードしてgpgでシグネチャ検証時、鍵 [https://swift.org/keys/all-keys.asc] をダウンロードする。この時curlでAccept-Encoding: ...を渡していないのにたまにContent-Encoding: gzipで返されて、鍵のインポート時にエラー gpg: no valid OpenPGP data found. で失敗してた。 curlで明示的に--compressedを使うことでエラー回避。

これのせいで Linux の swiftly でツールチェーンのインストールに失敗したり，swiftlang/swift-docker の Dockerfile をビルドしようとしてもいつまで経ってもビルドに失敗し続けたり，いろんなところで影響してますね... (edited)

ちょくちょく https://hub.docker.com/r/swiftlang/swift の Docker イメージのビルドが失敗しているのを ci.swift.org で見かけるのですが，それもよくみたら同じ原因で失敗してました． https://ci.swift.org/view/Swift%206.1/job/publish-nightly-6.1-docker-images/131/execution/node/30/log/

それぞれのプロジェクトで修正するPRとか出てるのに、直されてないのね。根本原因は、swift.orgのCDNがおかしい、なのかな

@Iceman もそう言っていた、アップルのサーバーがおかしそうって

根本原因はAppleのCDNがaccept gzipするリクエストとそうでないリクエストへのレスポンスを同じキャッシュにして混ぜ込むところですね

1

12:35 AM

クライアント視点では—compressed すれば透過的に展開できるけど、とはいえ対処療法なので嫌がられる気持ちはわからなくもなく、とはいえCDN直す気なさそうなので対処療法でもやって欲しいという気持ち

めっちゃわかりやすいバグだ　同じクエリとみなしちゃいけないものが同じキャッシュなのか

CDN直す気ないんですか？

原因はコミュニティ内で知れ渡ってそうだし、何年もこのままだからそう思ってるだけではあります (edited)

ここまで原因がはっきりしてるなら突いてみる価値ありそう。

Dockerfileのツールチェインインストールをswiftlyへ変えようかと思ったけど、キーのgzip対策がされてなさそうなので却下。

突くならどこなんでしょうねこれ？

リポジトリは無いからbug reporter？でも現象は複数のリポジトリに出てるから全部まとめてforumのdevelopmentカテゴリとかでも良さそう

管理してる人にメッセージ連絡しておきます

2

2

1

norio_nomura

swift-driverをmacOSでビルドして実行すると、Linux同様swiftと同じディレクトリからしか見つけてくれない macOSでPATHが通ってればサブコマンドが動く動作は、もしかしてmacOSの/usr/bin/swiftがswift-driverとは関係なく、勝手にやってる動作なのでは (edited)

swiftly経由だと直接swift-driverを起動するから、macOSでもサブコマンドをPATHから探してくれない、Linux版ツールチェインの動作と同じになる。 (edited)

Linux でも swift hoge じゃなくて swift-legacy-driver hoge なら PATH にある swift-hoge を呼び出してくれるので，macOS かどうかじゃなくてそもそも legacy driver と new driver (swift-driver repo) の違いだと思います．swift-driver は drop-in replacement を目指していると書いていたので，issue を立てたら確認してもらえたりしないですかね？ https://github.com/swiftlang/swift-driver/issues (edited)

Issues · swiftlang/swift-driver

Swift compiler driver reimplementation in Swift. Contribute to swiftlang/swift-driver development by creating an account on GitHub.

5:13 AM

macOS の /usr/bin/swift は legacy driver なんじゃないかと予想 (edited)

5:17 AM

swift hoge -disallow-use-new-driver でも swift-legacy-driver hoge と同じで PATH にある swift-hoge を呼び出してくれます．

macOSの/usr/bin/swiftにはTOOLCHAINS環境変数によって実行するswiftを切り替える機能が入っています。これって、swift-legacy-driverの挙動ですかね？

$ /usr/bin/swift -version swift-driver version: 1.120.5 Apple Swift version 6.1 (swiftlang-6.1.0.110.21 clang-1700.0.13.3) Target: arm64-apple-macosx15.0 $ TOOLCHAINS=org.swift.610202503251a /usr/bin/swift -version Apple Swift version 6.1-dev (LLVM 83bb915697f5992, Swift 1e211b4d3227ecc) Target: arm64-apple-macosx15.0

(edited)

TOOLCHAINS は xcrun の機能ですね．/usr/bin/swift のシンボルを nm で一覧してみても xcrun を呼んでいるっぽいです．

とりあえず/usr/bin/swiftはlegacy-driverではなさげ。

swift-driver は drop-in replacement を目指していると書いていたので

とりあえず、最初にswift-driverへサブコマンド機能が移植された時点でロジックが変わってしまってるぽい。 https://github.com/swiftlang/swift-driver/commit/eeab9a631e1308e41179c8be4a98ce584d896b64#diff-1e920c3af1340bd633526f526ae0d6b734b448ebadf128e699cbd4c212591180R29-R36

Add subcommand handling based on the original driver · swiftlang/s...

norio_nomura

とりあえず/usr/bin/swiftはlegacy-driverではなさげ。

swift-driver は drop-in replacement を目指していると書いていたので

とりあえず、最初にswift-driverへサブコマンド機能が移植された時点でロジックが変わってしまってるぽい。 https://github.com/swiftlang/swift-driver/commit/eeab9a631e1308e41179c8be4a98ce584d896b64#diff-1e920c3af1340bd633526f526ae0d6b734b448ebadf128e699cbd4c212591180R29-R36

言葉足らずでしたが，/usr/bin/swift が xcrun 経由で legacy driver を呼び出して使っているんじゃないかという推測です．

うーん、sudo fs_usage -w|grep legacyに何も出ないから違うと思うけどな。

それじゃわからないんじゃないでしょうかね？swift -disallow-use-new-driver とかはそれだと出てこないけれど legacy driver を使いますし．

そうか、サーチしないで決め打ちだから出ないのか。

macOSだとswift-legacy-driverってコマンドが無い。そしてLinuxだとswift-frontendへのシンボリックリンクだ。

swift-legacy-driver が legacy driver 本体だと思われているならそれは違いますよ．あれは swift のデフォルトが legacy driver から new driver に切り替わったときに色々問題が起こることを想定して，デフォルトで legacy driver を選択する swift コマンド，として用意されたものだったはずです．

6:38 AM

なので従来の swift build とかの swift を swift-legacy-driver に置き換えて，swift-legacy-driver build とか書くとこれまで通りビルドしてくれるという．

6:39 AM

あれが無い時から legacy と new どっちも動かせたんで本体は別ですね．

いや、でもswift-dirverはSWIFT_USE_OLD_DRIVERが定義されていたり-disallow-use-new-driverが渡されたりすると、swift-legacy-driverをexecしてますよ。 [https://github.com/swiftlang/swift-driver/blob/swift-6.0.3-RELEASE/Sources/swift-driver/main.swift#L74-L84]

swift-driver/Sources/swift-driver/main.swift at swift-6.0.3-RELEASE...

Swift compiler driver reimplementation in Swift. Contribute to swiftlang/swift-driver development by creating an account on GitHub.

なるほど．そうしたら私が何か見落としていたかもしれません．(もしくは後から swift-legacy-driver ができたからそっちを呼び出すようにしよう！となったか)

逆にmacOSで-disallow-use-new-driverが渡された時に、どうやってlegacy-driverを起動しているのかという謎が気になってしまったw

Xcode 同梱のツールチェーンってそもそも swift-driver が legacy driver で new driver が入っていないかもしれないです．(今 ls を見ました) (edited)

マジ

legacy driverとnew driverでヘルプメッセージとか違うよね。 (edited)

6:52 AM

otool -L (xcrun -find swift)を見るとlibswiftCore.dylibとかリンクされてるからswift-driverだと思うけど。

やっぱり swift-legacy-driver は swift-frontend を point しているだけなので，legacy driver 本体は swift-frontend 内部にあるのでは？ https://github.com/swiftlang/swift/pull/69834/files#diff-5cb31b06c53f34196c0672f1e85fbbcf1a3fc62c679da51f199b6b14238bd461R93

Symlink swift and swiftc to swift-driver, when available by a...

Remove redundant calls to add_swift_tool_symlink on /bin executables of the driver CMake target Symlink swift and swiftc to swift-driver, when available (when earlyswiftdriver was built with the ho...

legacy driverってswiftリポジトリのlib/DriverTool/driver.cppのswift::mainEntry()から起動するやつだと思ってた。

ここで追加されたテストケースを見ると，Darwin では swift-legacy-driver を /usr/bin/swift にハードリンクするみたいな記述があってそれも関係しそうです

まあ/usr/bin/swiftの小ささからすると、実装は/usr/lib/libxcselect.dylibにあるのだろうけど、dylibはOSに隠されてしまって見られないから、その中に警告メッセージを削ったswift-legacy-driverが入っていてもおかしくはない。

$ otool -L /usr/bin/swift /usr/bin/swift: /usr/lib/libxcselect.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0) $ otool -tv /usr/bin/swift|wc -l 149

けど確認しようがない。 (edited)

/usr/bin/swift にはなんとかなんとか_invoke_xcrun みたいなシンボルがあったんで，xcrun を外部コマンドとして呼び出していて xcrun が legacy driver を呼び出している可能性の方が高そうな気がします．xcrun を呼び出しているかどうかだけであれば多分観測できるんじゃないでしょうかね？ (edited)

ああ、今時の /usr/lib の実体が見えないやつ・・・

SIP切ってexecsnoop(1m)ってのを使えばプロセス起動を監視できそうだけど、そこまでしたくないw

7:14 AM

xcrunも実装は/usr/lib/libxcselect.dylibの中。/usr/bin/xcrunは逆アセンブルをここに貼れるほど小さい。

$ otool -tv /usr/bin/xcrun /usr/bin/xcrun: (__TEXT,__text) section 0000000100000520 pacibsp 0000000100000524 stp x22, x21, [sp, #-0x30]! 0000000100000528 stp x20, x19, [sp, #0x10] 000000010000052c stp x29, x30, [sp, #0x20] 0000000100000530 add x29, sp, #0x20 0000000100000534 mov x19, x1 0000000100000538 mov x20, x0 000000010000053c bl 0x100000578 ; symbol stub for: _getprogname 0000000100000540 mov x8, x0 0000000100000544 ldrb w9, [x8], #0x1 0000000100000548 cmp w9, #0x2d 000000010000054c csel x21, x0, x8, ne 0000000100000550 adrp x1, 0 ; 0x100000000 0000000100000554 add x1, x1, #0x5a8 ; literal pool for: "xcrun" 0000000100000558 mov x0, x21 000000010000055c bl 0x100000588 ; symbol stub for: _strcasecmp 0000000100000560 cmp w0, #0x0 0000000100000564 csel x0, xzr, x21, eq 0000000100000568 sub w1, w20, #0x1 000000010000056c add x2, x19, #0x8 0000000100000570 mov w3, #0x0 0000000100000574 bl 0x100000598 ; symbol stub for: _xcselect_invoke_xcrun

(edited)

そっちはあくまで呼び出す側で，呼び出される側は Xcode.app の中に入っている libxcrun.dylib なんじゃないかと思います．_xcrun_main を持ってますし．

7:20 AM

Command Line Tools でも降ってきますね．(/Library/Developer/CommandLineTools 以下に)

ああ、そういうことか。

$ dive_in /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin; ls -la swift swift-frontend swift-driver lrwxr-xr-x 1 norio staff 14 3 26 10:24 swift@ -> swift-frontend -rwxr-xr-x 1 norio staff 9265296 3 18 19:40 swift-driver* -rwxr-xr-x 1 norio staff 356405232 3 18 19:40 swift-frontend* $ DOCKER_UBUNTU_IMAGE=swift docker-ubuntu all contents will be removed after the container is stopped root@swift:~# cd /usr/bin root@swift:/usr/bin# ls -la swift swift-frontend swift-driver lrwxrwxrwx 1 root root 12 Dec 11 17:01 swift -> swift-driver -rwxr-xr-x 1 root root 38219560 Dec 11 18:23 swift-driver -rwxr-xr-x 1 root root 182984296 Dec 11 16:38 swift-frontend

macOSは swift -> swift-frontend Linuxは swift -> swift-driver だ。 (edited)

で、

swift-frontendは-disallow-use-new-driverが無ければswift-driverを起動する。
swift-driver は-disallow-use-new-driverが有ればswift-frontendを起動する。

ってなってる。

ちょうど私も fs_usage -w | grep swift-help しながら swift help と swift help -disallow-use-new-driver を比較した場合も swift-help を execve しているのが swift-driver (new driver) か swift-frontend (legacy driver) かでクッキリ分かれてました．

xcrunに特別な機能はなくて、単純にswiftシンボリックリンク先の違いだけだ。

7:38 AM

Linuxでもswiftをswift-frontendへのシンボリックリンクにしてswift-legacy-driverを削除してしまえば、サブコマンド検索について望む動作になるのでは。

言われてみたら確かに swift-driver があるのに swift-frontend にリンクされてました．(なぜそこに気づかなかったのか)

norio_nomura

Linuxでもswiftをswift-frontendへのシンボリックリンクにしてswift-legacy-driverを削除してしまえば、サブコマンド検索について望む動作になるのでは。

それがさっきの #69834 がマージされる前までの世界です．

ドライバの切り替えは、swift-driver側ではサブコマンドの解釈前、swift-frontend側ではサブコマンドの解釈後に起こる。

norio_nomura

Linuxでもswiftをswift-frontendへのシンボリックリンクにしてswift-legacy-driverを削除してしまえば、サブコマンド検索について望む動作になるのでは。

試したらなった。

7:47 AM

Linuxでswiftlyでのツールチェインインストール後に、それぞれのツールチェイン内のswiftシンボリックをいじる必要があるけど、それぞれにオレオレサブコマンドを入れるよりマシか。 (edited)

まとめると Apple 版のツールチェーンでは #69834 の対応が無かった (or 無効化された) 状態になっていて，swift.org のツールチェーン (macOS でも Linux でも) は #69834 がちゃんと効いている状態になっているので，この差が生まれているようですね．多分 Apple の方は過去との互換性を気にしてわざとそうしてそうですね． (edited)

1

xcrunにswiftの挙動を切り替えるような謎機能がなさそうで良かった (edited)

あったとしても xcrun が swift-frontend を直接呼び出して argv[0] を swift に書き換えているとかかなと思ってましたw

1

norio_nomura

swiftly経由だと直接swift-driverを起動するから、macOSでもサブコマンドをPATHから探してくれない、Linux版ツールチェインの動作と同じになる。 (edited)

そしてmacOS版のOSSツールチェインはLinux版と同じくswiftはswift-driverを指してて、swiftlyを使った時の挙動になるw (戻ってきた!)

なので swiftly のせいでは無い，と

swiftlyがツールチェインの選択にxcrun (TOOLCHAINS環境変数)を使ってくれれば、サブコマンド検索も望む動作になるのでは？と考えてたけど、今までの理由を考えるとダメってことだよね。インストールされたツールチェインのswiftシンボリックリンクを変えないと望む動作にはならない。

norio_nomura

とりあえず/usr/bin/swiftはlegacy-driverではなさげ。

swift-driver は drop-in replacement を目指していると書いていたので

とりあえず、最初にswift-driverへサブコマンド機能が移植された時点でロジックが変わってしまってるぽい。 https://github.com/swiftlang/swift-driver/commit/eeab9a631e1308e41179c8be4a98ce584d896b64#diff-1e920c3af1340bd633526f526ae0d6b734b448ebadf128e699cbd4c212591180R29-R36

swift-driverへの移植時にコメントと違う動作になってしまったのを、直さないと治らない。 (edited)

legacy driver を使えば良いっていうのがわかったなら，alias swift=swift-legacy-driver で解決じゃ無いですか？廃止されるまでの命ですが．

いや、shellから起動するとは限らんし。

cp swift-legacy-driver swift (or mv) で上書きする． (edited)

w

8:10 AM

まあでも、どうでも良くなってきたw

8:11 AM

お付き合いありがとうございました。

1

8:13 AM

とりあえずswiftlyへ無駄なPR書かずに済んだ。

LinuxのCIでSwiftの関数はスタックトレースが出るけどlibcの部分は出ない

*** Signal 11: Backtracing from 0x7f38f3844c1d... done *** *** Program crashed: Bad pointer dereference at 0x00007f3f27880849 *** Thread 0 "jsvPackageTests": 0 0x00007f38f384280a <unknown> in libc.so.6 Thread 1: 0 0x00007f38f391e88d <unknown> in libc.so.6 Thread 2: 0 0x00007f38f3925e2e <unknown> in libc.so.6 ... Thread 10 crashed: 0 0x00007f38f3844c1d <unknown> in libc.so.6 Thread 11 "SGLTN-TP-#0": 0 0x00007f38f3891117 <unknown> in libc.so.6 ... Backtrace took 29.94s

(edited)

11:11 AM

他のスレッドのいくつかはSwiftのコールスタックが出るんだけど肝心のcrashedになっているスレッドがlibcのunknownが1行だけになっていて何もわからない

11:13 AM

@norio_nomura のこれかなあ https://discord.com/channels/291054398077927425/430242233468452865/1348820605117665432

11:14 AM

バックトレースに29秒って出てるのも気になる。時間かかりすぎやろ

11:15 AM

- run: swift test

11:15 AM

CIだからreleaseビルドにもしてないし、static-stdlibも付けてないや

11:19 AM

そもそもlibcレベルで落ちてるってことはユーザ側のバグじゃないんじゃないかと思っているんだけど、swift-testingの並列実行が関係してるっぽくて、やり直すと通ったりするし、よくわからない

ディストリビューションによってパッケージ名は違うと思いますけど，libc6-dbg みたいなデバッグシンボルのパッケージを使うようにしても出ないんですかね？

そういうことか GitHubの用意してる ubuntu-22-8cpu をそのまま使ってるのだけど、これにデバッグシンボルが入ってないのかも

12:19 PM

apt-getで入れて、試してみますね

Swift 6.1ボットのビルドが失敗する様になり調べたら、swift-sdk-darwinがアーカイブされてXcodeから直接Swift SDKをインストールして使うツールへ誘導されてた。 https://github.com/xtool-org/xtool

GitHub - xtool-org/xtool: Cross-platform Xcode replacement. Build a...

Cross-platform Xcode replacement. Build and deploy iOS apps with SwiftPM on Linux, Windows, macOS. - xtool-org/xtool

4

1:21 AM

LinuxでビルドしてiOSデバイスへインストール＆実行が出来る的なチュートリアルが用意されてる。 https://xtool.sh/tutorials/xtool/first-app

結構前にフォーラムに投稿されてて見ました．Apple の規約的に Apple のハード上でしか動かしちゃダメってのがちょっと注意点ですが面白いですよね． https://forums.swift.org/t/xtool-cross-platform-xcode-replacement-build-ios-apps-on-linux-and-more/79803

Xtool: cross-platform Xcode replacement. Build iOS apps on Linux an...

Hi folks! A few months ago I shared my Swift SDK for Darwin, which allows you to build iOS Swift Packages on Linux, amongst other things. I mentioned that a lot of work still needed to be done, such as handling codesigning, packaging, and bundling. I'm super excited to share that we've finally reached the point where all of these things are now...

1:28 AM

以前 Swift のマクロのビルドが遅い問題を解決するためにマクロをホストターゲットじゃなくて Wasm ターゲットにビルドするようにする PR を出してた人と同じ人ですね．

なるほど。最新のXcodeがサポートされなくなった古いMacでも、Linux VM経由で最新SDKでビルド＆インストールできるのかな。 (edited)

確かにメンテナンスされ続ける限りはそういう用途でも使えそうですね．VM でもデュアルブートでも．

Xcode12とかで動作するレガシーコードの技術的負債の確認に使えればいいですね。

Swift SDK のインストール時とビルド時に今使っているツールチェーンのバージョンを見て自動で合わせてくれるようになるみたいです．インストールは Static Linux SDK みたいに swift.org で配布されているやつ変亭になりそうですが． https://github.com/swiftlang/swift-package-manager/pull/8703

Simplify Swift SDK installation/selection with aliases by MaxDesiat...

Motivation: As Swift SDKs require host toolchain version to exactly match the version used to build a Swift SDK that&#39;s used, we need to automate Swift SDK installation and selection process...

https://github.com/apple/container をmacOS 15.5で少し使ってみた。ここで動かしてるボットのイメージは、ビルドは出来なかったけどpullしてrunする分には普通に動いた。 (edited)

GitHub - apple/container: A tool for creating and running Linux con...

A tool for creating and running Linux containers using lightweight virtual machines on a Mac. It&#39;s written in Swift, and optimized for Apple silicon. - GitHub - apple/container: A tool for...

https://x.com/shibu_jp/status/1932192886751461428

渋川よしき (@shibu_jp)

Linuxからすりゃ自分のカーネルの管轄外のプロセスの都合なんて知らない。だからWSL2はLinuxから見えるメモリを当初のWindowsの8割から5割に減らしたし、定期的に再起動が必要というのが現状である。macOSはコンテナごとにvminitdのみの最小限のVMを起動する。WSL2...

イメージpullで複数レイヤーを並列でダウンロードとかしてくれないから、dockerとかと比べてめちゃ遅かった。

2

メモリ消費の少ないDockerとして使えるのでしょうか

仕組みとしてはLinux VM内でコンテナを動かしてるのは同じだから、劇的には変わらない気がする。 (edited)

1:20 AM

いや、そんなことないかも

1:26 AM

もしかするとmemory balloonとかちゃんと使ってるかも

containerそのものも便利なのですが、containerization自体がオープンソースで公開されたことがすごく大きなニュースで、ほぼプロセスと同じコストでLinuxバイナリが動かせる、って考えてみるのがいいと個人的には思ってます

swift-mainボットをdocker on lima VMとcontainerで動かした時のVMのメモリ使用量比較。 (edited)

1:28 AM

あと、コンテナ毎にVMが立ち上がる感じみたい。

norio_nomura

あと、コンテナ毎にVMが立ち上がる感じみたい。

それが実装の肝です。元来にはmicroVMとかnanoVMと呼ばれていたものです

ほぼプロセスと同じコストでLinuxバイナリが動かせる

すごい

Kata container Amazon Firecracker Microsoft Hyperlight あたりと考え方は似てて、わりと普通の実装(Cloud Runの裏側もそうなっています

1

Docker on mac はDocker用の仮想Linuxが1台立ち上がってて、その中でコンテナをたくさん立ち上げるという構造で、 Containerization Framework はコンテナ1個に対して専用の小さいVMがそれぞれ用意される、というのが原理的に違うということ？ (edited)

norio_nomura

swift-mainボットをdocker on lima VMとcontainerで動かした時のVMのメモリ使用量比較。 (edited)

これに関しては、vminitdが軽量なのがかなり助力してそう

omochimetaru

Docker on mac はDocker用の仮想Linuxが1台立ち上がってて、その中でコンテナをたくさん立ち上げるという構造で、 Containerization Framework はコンテナ1個に対して専用の小さいVMがそれぞれ用意される、というのが原理的に違うということ？ (edited)

概ねそんな感じです

1

norio_nomura

swift-mainボットをdocker on lima VMとcontainerで動かした時のVMのメモリ使用量比較。 (edited)

関係ないけどこの文字化け前から気になっている

1:32 AM

安全な文字化けなんだろうか。null文字貫通してそうで不安になる。

コンテナ毎にVMが立ち上がるから、コンテナ毎にkernel指定できるようになってて面白い

6.12動くようになったのかな

vminitdはSwift製なのか

そこもなのか

はい

2:00 AM

今のところまだ日本で1番詳しいがそのうち人々に抜かれそうだ

仮想化基盤にSwift使うのはハイパフォーマンス言語としての本気を感じるな・・・

1

2:02 AM

ownershipとかinline arrayも使ってるのかな、後で見てこよう

Virtualization.framework にLinux Kernelを直接渡して起動すると、kernelが認識できるRTCデバイスが無くてVMの時刻合わせが出来なくて以前困ったのだけど、vminitdは普通に時刻合わせしてるぽいログを出してるな

containerはVSCodeのdevcontainerで使える様になると嬉しいな

norio_nomura

イメージpullで複数レイヤーを並列でダウンロードとかしてくれないから、dockerとかと比べてめちゃ遅かった。

内部でも確認しましたがpullは並列化されてそうですよ

container image pull ghcr.io/norio-nomura/swift_discord_bot:main と docker pull ghcr.io/norio-nomura/swift_discord_bot:main を同時に開始すると、dockerが完了した時点でcontainerは30%ちょっとくらいでした。

5:28 AM

並列化とは関係なく遅い？

5:32 AM

ああ、もしかしてmulti archイメージだと全部のarchをpullしてるのか？

docker pullはlinux/arm64だけで5分43秒 container image pullはlinux/amd64,linux/arm64の2つで24分30秒 (edited)

pullだけで24分は遅いですね

—platform を指定しないと全部取ってくるって話かも (edited)

全部にしても遅そう？

遅いのはネットワークの帯域によっても違ったりする気がするので、どうかなあ

6:20 AM

今週はずっとホテルでまともに計測ができない

https://github.com/apple/containerization/blob/cbb1ee4cffbcf6149f817a5b75537dee2676a8b0/Sources/Containerization/Image/ImageStore/ImageStore%2BImport.swift pullしてる実態はこれかなあ

containerization/Sources/Containerization/Image/ImageStore/ImageSto...

Containerization is a Swift package for running Linux containers on macOS. - apple/containerization

6:35 AM

特段遅そうな感じなさそう(swiftなんもわからん

https://github.com/apple/containerization/blob/cbb1ee4cffbcf6149f817a5b75537dee2676a8b0/Sources/Containerization/Image/ImageStore/ImageStore%2BImport.swift#L123-L147

6:42 AM

これはpullするレイヤーをチャンクに分割して並列でリクエストしてそうですが、1チャンクごとに全部終わるまで待ってるので、暇してることが多そうですね

6:42 AM

あるべき姿としてはチャンク分割などせず、常時X本並列してリクエストなんだと思います

(本題と関係ないが)これFoundationの新しいprogress handler 使ってそう (edited)

同じマシンでdockerとcontainerを同時(1秒差)で開始しての結果なので、ネットワーク帯域云々は処理時間差に関係ないかと。 (edited)

https://github.com/apple/containerization/pull/75 少しだけ速くなった

Fetch without chunking in parallel by sidepelican · Pull Request #...

Issue When pulling images, the download speed appears to be slower compared to Docker. I found that parallel chunk generation was being performed during the layer download process. While individual...

6

1

知ってたことだけど、うちのネット遅いなw

4:05 AM

https://github.com/apple/containerization/pull/75/files#diff-7d1bc6b0175b40079a77439cfa5f8c3678c4d9e769077ce45e1a616f49838446R124

for _ in 0..<8 {

この8ってどこから来てるんだろう (edited)

apple siliconの一般的なコア数な気がする

magic numberやめろって言われそうだけど、元のコードもそうなのか。

元のコード踏襲してますね

マージされましたね！内部でも声かけておきました

Iceman

これはpullするレイヤーをチャンクに分割して並列でリクエストしてそうですが、1チャンクごとに全部終わるまで待ってるので、暇してることが多そうですね

ありがとうございます bow2

1

containerizationをmacOS 15.5でビルドしようとしたけど、Xcode_26_betaで使えるStatic Linux SDKが無さげ。

~~containerizationはXcode 26じゃなくてもよかった。~~いや、やっぱりビルドできない (edited)

僕はmacOS15 26Betaでビルドしてました

7:41 AM

macOS用だけですが。

7:42 AM

Linuxは試してないです

macOS 15.5でビルドするには、Xcode 26 betaに含まれるSDKを使えるSwift 6.2 スナップショットとStatic Linux SDKが必要な感じ

8:29 AM

vminitdだけLinuxでビルドする方法を試してみる

vminitdだけswift-6.2-DEVELOPMENT-SNAPSHOT-2025-05-30-aのLinux版でビルドして、残りはXcode 26 betaでビルドする方法でいけた。

あー、Fetchingはそこそこ遅いだけで、Unpackingがめちゃめちゃ遅いみたい。 (edited)

1:32 AM

UnpackingにFetchingの2倍くらい時間がかかってる。

おお、興味深い。

1:34 AM

そこはSwiftで負けたくないところ

pullの時の進捗がログに残せないから、めちゃめちゃ使いづらい。

1

まさかBuildKit相当？までSwiftで実装し直そうとしてるとは思わなかった。 https://github.com/apple/container/blob/main/Sources/NativeBuilder/README.md

container/Sources/NativeBuilder/README.md at main · apple/container

A tool for creating and running Linux containers using lightweight virtual machines on a Mac. It is written in Swift, and optimized for Apple silicon. - apple/container

3

すご

ライセンスの問題回避なのかな？

12:44 AM

apple配布のバイナリでgolang製のモノって無かったりする？

一応 Apple Open Source の 2 番目は k8s (Go) ですけどね． https://opensource.apple.com

norio_nomura

まさかBuildKit相当？までSwiftで実装し直そうとしてるとは思わなかった。 https://github.com/apple/container/blob/main/Sources/NativeBuilder/README.md

https://github.com/apple/container/blob/main/Sources/NativeBuilder/docs/Design.md を読むと、BuildKitとは違ってMacホスト側で動くらしい。 Dockerfile内のRUNとかはMacのファイルシステムをvirtio-fsでマウントしたVM内で実行して、ファイルシステムへの変更はMac側で収集するらしい。 Virtualization.frameworkのvirtio-fsマウントはVM内でのファイルのオーナー操作が無視される筈だから、そのあたり非互換になりそう。 (edited)

container/Sources/NativeBuilder/docs/Design.md at main · apple/con...

A tool for creating and running Linux containers using lightweight virtual machines on a Mac. It is written in Swift, and optimized for Apple silicon. - apple/container

面白い

10:21 AM

読んでみてる Dockerfile実装するのにIRとか必要なんか・・・

container run --name docker --detach --publish-socket /var/run/docker.sock:/var/run/docker.sock --memory 16G docker.io/library/docker --feature containerd-snapshotter

この一文でcontainerにdockerホストを作れるけど、docker compose buildとか実行するとVMがkernel panic起こして途中で止まってしまう。残念。 (edited)

omochimetaru

読んでみてる Dockerfile実装するのにIRとか必要なんか・・・

そうですね、基本的にビルドツリーは有向グラフになっているので、中間表現を持ってきたほうがスケールしやすいと思います

1

norio_nomura

https://github.com/apple/container/blob/main/Sources/NativeBuilder/docs/Design.md を読むと、BuildKitとは違ってMacホスト側で動くらしい。 Dockerfile内のRUNとかはMacのファイルシステムをvirtio-fsでマウントしたVM内で実行して、ファイルシステムへの変更はMac側で収集するらしい。 Virtualization.frameworkのvirtio-fsマウントはVM内でのファイルのオーナー操作が無視される筈だから、そのあたり非互換になりそう。 (edited)

既存のDocker toolingにおいてBuildKit自体がVM上で動くようになっているのはどちらかというとパッケージングの問題だと思っていて、単純に今までだれもon macOSでBuildKitを動かそうって思ったことがないから、ってだけなんじゃないですかねえ。事実、BuildKitもRedHat製のBuildahも、コンテナランタイムへの依存性は皆無で純粋に単体で動作します

norio_nomura

apple配布のバイナリでgolang製のモノって無かったりする？

アクティブなものでって意味だとpkl-goとcontainer-builder-shimの2つだけですねえ

2:18 PM

既存のツールは最低でもコンテナ、あるいはランタイムが動いているVM環境が必要でbuild自体のリソースがひっ迫しうるようなケースでかなり大きなパフォーマンス上のオーバーヘッドがあったので、ホストネイティブなビルダーが入るのはかなり大きな改善だなと思いますね。実行中のコンテナに対する影響もだいぶ減りますし、ユーザー側でリソースのコントロールもしやすくなるんで (edited)

なるほど。コンテナイメージの中に、docker buildができるようにするためのものが無駄に入っちゃってるんですね。

Docker Desktopでいわゆる次世代ビルダー（BuildKit、最近のバージョンではデフォルトのはず）を使ってdocker buildを実行すると、https://hub.docker.com/r/moby/buildkit がコンテナとして内部的に動いてイメージの生成を行うようになっています。

CDIっていう仕組みを使って、docker build中にRosetta for LinuxのAOT Cachingを有効にできる事がわかった。 https://github.com/cncf-tags/container-device-interface/blob/main/SPEC.md

container-device-interface/SPEC.md at main · cncf-tags/container-d...

Contribute to cncf-tags/container-device-interface development by creating an account on GitHub.

1

3:05 PM

CDIは元々コンテナビルド中にGPUなどを使うために作られたぽい。 https://docs.docker.com/build/building/cdi/

Container Device Interface (CDI)

Using CDI to access GPUs and other devices in your builds

3:10 PM

RUN --device=lima.io/rosetta=enable-aot-caching ... みたいな記述をすることで、RUNの環境にホスト側で動くAOT Cachingを受け持つrosettad daemonが使うソケットをコンテナ内にbindマウントする様に構成できる。すると、コンテナ内のrosettaがrosettadと通信できるようになり、AOT Cachingが動くようになる。 (edited)

3:14 PM

macOSのdarwin環境下のRosettaサポートが終わっても、Virtualization.frameworkでのRosetta for Linuxの提供は終わらないらしいから、この方法もまだ活用できるはず。 (edited)

AOT Cachingを有効にするためだけにDockerfileの修正が必要なのはイマイチ。

golang製Swiftボット実行ファイルのビルドが、AOT Caching無し約52秒、有り約25秒

3:35 PM

ちょっと予想より効果が大きかった。

RosettaのAOT Cachingについては、limaと依存するvzにPRを出すつもり。

norio_nomura

Nightlyのツールチェインをダウンロードしてgpgでシグネチャ検証時、鍵 [https://swift.org/keys/all-keys.asc] をダウンロードする。この時curlでAccept-Encoding: ...を渡していないのにたまにContent-Encoding: gzipで返されて、鍵のインポート時にエラー gpg: no valid OpenPGP data found. で失敗してた。 curlで明示的に--compressedを使うことでエラー回避。

swiftlang/swift-docker ではついに --compressed が付きましたね．swiftly にもついて欲しい... https://github.com/swiftlang/swift-docker/pull/495

add --compressed to curl gpg keys command by justice-adams-apple ·...

Our keys file is large and this causes our packaging/CI jobs to fall over frequently with 02:01:59 #11 17.60 gpg: no valid OpenPGP data found. 02:01:59 #11 17.60 gpg: Total number processed: 0 02...

なんでこれ渋るんだろうなぁ

3:48 PM

とは言え僕は最近swiftlyでこれ起きてないんですが、起きてます？

1.0.1 以降も起きてますねー．GitHub-hosted runner (ubuntu-24.04-arm) で走らせてる CI ジョブでは 1 ヶ月くらい何度かリトライしながら様子見しましたが失敗率高めだったので，諦めて curl --silent --retry 3 --location --fail --compressed https://swift.org/keys/all-keys.asc | gpg --import - で先に鍵がインポート済みの状態になるようにして解決しました．(なので swiftly の外側で回避自体は可能ではある) (edited)

改めてログを見返していたら，3 週間ほど前に 1 回は確実に起こっているんですが，他の再現例は別のスクリプトのミスが原因の可能性も出てきたので再現頻度が高いというのは思い込みだったかもしれないので，改めて再現頻度は測り直してみます．ただ再現自体はしてますね．

5:23 PM

いや，その 1 回は curl による事前の鍵ダウンロードのワークアラウンド (その時点では --compressed なし) を入れた後の再現だったので，swiftly というより curl での再現例でした… すみません普通に私の勘違いかもしれないので，改めて確認し直します．

norio_nomura

golang製Swiftボット実行ファイルのビルドが、AOT Caching無し約52秒、有り約25秒

SwiftLint x86_64版のRosettaでのビルド、AOT Caching無し約660秒、有り約600秒。 1プロセスあたりの仕事量が多くて、AOT Cachingの恩恵が薄れてそう。 aarch64でx86_64向けにクロスコンパイルすると約400秒で済むしRosettaも不要だから、成果物ビルド用には微妙。テスト実行とかには向いているのかも。 (edited)

昨日limaへPR投げた。やはりGolangでのビルドはRosetta AOT Cachingがとてもよく効く。Golangはクロスビルド標準装備だから使わないのだけど。 https://github.com/lima-vm/lima/pull/3858

feature: use Rosetta AOT Caching with CDI by norio-nomura · Pull R...

Description This change introduces device configuration to enable Rosetta AOT Caching in Docker VMs. Modify Rosetta Caching Options from Abstract Socket to Unix Domain Socket: Unix Domain Socket ...

Iceman

とは言え僕は最近swiftlyでこれ起きてないんですが、起きてます？

あれから複数リポジトリで環境やタイミングを変えながら結構な回数試行してみたんですが，やっぱり私の勘違いだった可能性が高そうです．swiftly では gpg key が gzip で返ってきてインポート失敗するというエラーは起こってなさそうです．申し訳ありませんでした．

1

https://forums.swift.org/t/review-sf-0033-string-encoding-names/81965

[Review] SF-0033: String Encoding Names

Hello community, The review of SF-0033: String Encoding Names begins now and runs through 2025-09-11, Thursday. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager by DM. When contacting the review manager directly, please include proposal name in t...

2:20 AM

ヨッコーさんが進めていたIANAエンコーディング名との変換が審査入りした

norio_nomura

昨日limaへPR投げた。やはりGolangでのビルドはRosetta AOT Cachingがとてもよく効く。Golangはクロスビルド標準装備だから使わないのだけど。 https://github.com/lima-vm/lima/pull/3858

Lima 2.0.0-alpha系でRosetta AOT Cachingを試せるようになってます。 https://github.com/lima-vm/lima/releases/tag/v2.0.0-alpha.1 macOS 15までのRosetta for LinuxはLinux Kernel 6.13以降でクラッシュするバグがあるので、macOS 26か、VMで少し古めのLinux Kernel (Ubuntuだと24.04以前)を使う必要がありますが。 (edited)

1

norio_nomura

Lima 2.0.0-alpha系でRosetta AOT Cachingを試せるようになってます。 https://github.com/lima-vm/lima/releases/tag/v2.0.0-alpha.1 macOS 15までのRosetta for LinuxはLinux Kernel 6.13以降でクラッシュするバグがあるので、macOS 26か、VMで少し古めのLinux Kernel (Ubuntuだと24.04以前)を使う必要がありますが。 (edited)

あー、v2.0.0-alpha.1はちょっとお勧めできないバグを見つけてしまった。

SwiftLintのStatic Linux SDKでビルドされたバイナリが公開されてて試してみたらクラッシュするので、色々調べてPRを送ってみた。 muslのstack sizeが小さいからというのがわかってmuslの勉強になった。 https://github.com/realm/SwiftLint/pull/6291

1

すごい。よく原因わかりましたね

ainame

SwiftLintのStatic Linux SDKでビルドされたバイナリが公開されてて試してみたらクラッシュするので、色々調べてPRを送ってみた。 muslのstack sizeが小さいからというのがわかってmuslの勉強になった。 https://github.com/realm/SwiftLint/pull/6291

プルリクの方で書かれている「-Xlinker -z -Xlinker stack-size=... が macOS だと使えない問題」って，WASI 向けのクロスコンパイル時も以前は同様だったので困っていたんですが，最近のツールチェーンでは起こらなくなってませんか？私の方では起こらなくなりました．(そもそも Wasm のリンクだと wasm-ld が使われるはずなのに ld-prime (ld64) がエラーを吐いているのはなぜなんだろうとずっと思ってました) (edited)

あれ，同じ環境で試してみたら

# swift-syntax swift build -c release --build-tests --swift-sdk swift-6.2-RELEASE_wasm -Xlinker -z -Xlinker stack-size=16777216

では起こらなくなりましたが

# SwiftLint swift build -c release --product swiftlint --swift-sdk aarch64-swift-linux-musl -Xswiftc -DSWIFTLINT_DISABLE_SOURCEKIT -Xlinker -z -Xlinker stack-size=0x80000

では起こりますね... (edited)

詳しくは知らないですが、別の何でもないプロジェクトでは動いたので、Macroが含まれるとホストのmacOS向けにビルドするときに失敗するみたいな感じなんですかね、もしかしたら。

2

あれ、-Xlinkerってマクロビルドにも適用されちゃうのか

8:33 AM

ワークアラウンドはtoolset.jsonを書いて--toolsetで渡す、くらいかなー

1

ainame

詳しくは知らないですが、別の何でもないプロジェクトでは動いたので、Macroが含まれるとホストのmacOS向けにビルドするときに失敗するみたいな感じなんですかね、もしかしたら。

確かにリポジトリによるというのはおっしゃる通りでした．WASI 向けのビルドでも，swift-syntax のリポジトリでは大丈夫だけど swift-format のリポジトリでは同様のエラーが出ました．なので私はリポジトリが変わったことに気づかず治ったと思い込んでいたようです．そして kateinoigakukun さんの toolset の方も試してみました．簡易的に以下のような toolset.json を用意して，-Xlinker -z -Xlinker stack-size=4194304 の代わりに --toolset toolset.json を指定してみたらビルドが通りました． { "schemaVersion": "1.0", "linker": { "extraCLIOptions": [ "-z", "stack-size=4194304" ] } }

1