Runtime: FreeBSDのサポート

https://github.com/dotnet/corefx/issues/1576に関する限り、合意があるようです。

https://github.com/dotnet/corefx/issues/1625でも決定が下されたら、コードの出荷を開始できるはずです。

dotnet / runtime＃14536に関する合意は、MSFTが別の方法で選択しない限り、ポートチームによって達成されました。それ以外の場合はFreeBSDます。 問題dotnet / corefx＃1999は、パブリックAPIに定義を導入する問題になる可能性があります。

dotnet / runtime＃14536に関する合意は、MSFTが別の方法で選択しない限り、Portteamによって達成されました。

私がその権利を読んだ場合、これはhttps://github.com/dotnet/corefx/pull/1999がマージされたときに、このMSFTが新しいパブリックAPIを承認したと見なすことができることを意味し

もしそうなら、それは私にはいいですね。

https://github.com/dotnet/corefx/pull/1999#issuecomment-111279577による次の手順は次のとおりです。

1. 「FreeBSDポートチーム」は、CoreFXのFreeBSDバージョンを作成するための作業を続けています（dotnet / corefx＃1626によって追跡されています）。
2. ポートチームは、FreeBSDでCoreFXおよびCoreCLRスタックを十分に立ち上げて、FreeBSDでCoreFXユニットテストの実行を開始できるようにします。
3. テストは最低限の品質レベルに達します。 これがどのように見えるかはまだ正確にはわかりませんが、テストの大部分が合格したようなものだと思います。 理想的には、FreeBSDだけで多数の特定のテストを無効にしないでください（LinuxやOSXと比較して、FreeBSDを他の* NIXプラットフォームよりも高い水準に保ちたくありません）。
4. CoreFXチームは、FreeBSDポートチームと協力して、FreeBSDで実行されているCIシステムにCoreFXテストを追加します。
5. プロパティを追加する問題dotnet / runtime＃14536に基づくPRのマージについて説明します。

それは私には完全に合理的な計画のように聞こえます。

それでは、corefxを機能させる作業を始めましょう。

FreeBSDでcorefxを構築する際の最初の障害は、モノラルのようです。 ビルドスクリプトは、バージョン4.1が必要であると主張しています。 @ajensenwaudはフランクフルトのホストでこれについていくつかの作業を行いましたが、それがどれほど完全かはわかりません。

今のところビルドをキューに入れて、出力がどのようになるかを確認します。

編集:(モノラル）ビルドは、最後に次のキッカーでクラッシュします：

Making all in mini
make[1]: "/usr/home/josteink/mono/mono/mini/Makefile" line 2906: warning: duplicate script for target "%.exe" ignored
make[1]: "/usr/home/josteink/mono/mono/mini/Makefile" line 2899: warning: using previous script for "%.exe" defined here
  CC       genmdesc-genmdesc.o
In file included from genmdesc.c:9:0:
mini.h:17:34: fatal error: ./mono/metadata/loader.h: Too many levels of symbolic links
 #include <mono/metadata/loader.h>
                                  ^
compilation terminated.
*** Error code 1

Stop.
make[1]: stopped in /usr/home/josteink/mono/mono/mini
*** Error code 1

Stop.

FreeBSDでcorefxを構築する際の最初の障害はモノラルのようです

FWIW、私は個人的にこれが最初の障害だとは思いません。 ビルドに関連する2つの問題があります。

1. FreeBSDで正しく動作するアセンブリの構築
2. FreeBSDでそれらのアセンブリを構築する

（1）は重要であり、この問題が何を意味するのかを私は信じています。 （2）は非常に便利ですが、それがなくても、FreeBSDでマネージコードを実行するための優れたシステムを作成できます。

もちろん、適切と思われる方法で優先順位を付けることは自由ですが、（2）ではなく（1）に焦点を当てることをお勧めします。

LinuxでのcorefxのビルドとOSXでのビルドにはまだ問題があり、CIシステムがWindowsでこれらのプラットフォームのアセンブリをビルドすることに注意してください。 次に、結果のアセンブリをターゲットプラットフォームにシャトルして、テストを実行します。

それは十分に公平です。 FreeBSDで実際にビルドできれば、一般的なFreeBSDプラットフォームのサポートをcorefxに組み込む方が簡単だと思いました。

今のところ、Windowsで開始されたビルドを使用して、ビルド構成を一緒に忍び寄ろうとします。

@josteinkところで。 corefxはMono4.0.1.44でビルドする必要があります。

@akoeplingerニース。 それは私たちがFreeBSDでもそれを実行できるようになるという希望を私に残します:)

良い点。 ただし、corefxをFreeBSD環境の一部にしたい場合は、ソースからコンパイルしてPortsシステムに取り込むことができる必要があります。

Mono 4.0.1.44でこれらの問題の多くが修正されると聞きましたが、まだ試してみる時間がありませんでした。 ポートチームがポートMakefileを更新していること、および新しいパッチについて話していることを知っています。

2015年6月12日には、20：21で、スティーブンToubの[email protected]は書きました：

FreeBSDでcorefxを構築する際の最初の障害はモノラルのようです

FWIW、私は個人的にこれが最初の障害だとは思いません。 ビルドに関連する2つの問題があります。

FreeBSDで正しく動作するアセンブリの構築
FreeBSDでそれらのアセンブリを構築する
（1）は重要であり、この問題が何を意味するのかを私は信じています。 （2）は非常に便利ですが、それがなくても、FreeBSDでマネージコードを実行するための優れたシステムを作成できます。

もちろん、適切と思われる方法で優先順位を付けることは自由ですが、（2）ではなく（1）に焦点を当てることをお勧めします。

Linux上に構築されたcorefxとOSX上に構築されたcorefxがほとんどないため、CIシステムはWindows上でこれらのプラットフォームのアセンブリを構築することに注意してください。 次に、結果のアセンブリをターゲットプラットフォームにシャトルして、テストを実行します。

—
このメールに直接返信するか、GitHubで表示してください。

はい、私は決して異議を唱えていません... Linux、OSX、およびFreeBSDでcorefxを_ビルド_できることは重要です。 私は単に、優先順位の観点から、Linux、OSX、およびFreeBSDで実際にcorefxを実行できることがより重要であることを示唆しています。 ：wink：両方を並行して処理できるのであれば、なおさらです。

@ghuntley 、
何が残っているかを概説するマークダウンタスクのチェックリストがある場合：

- [x] task 1
- [ ] task 2
- [ ] task 3

次のようにレンダリングされます：

• [ ] タスク1
• []タスク2
• []タスク3

これはおそらく他の人がそれらの偉業を獲得することを奨励し、FreeBSDのサポートは予想よりも早く着陸するでしょう！ ：サングラス：

私の知る限り、FreeBSDをサポートするには、CoreFXで次の作業が必要です。

• [x]ビルドツールとスクリプトにFreeBSDプラットフォームを導入します。 （ @josteinkと私によって行われ、PR dotnet / corefx＃2021がマージされ、dotnet / corefx＃2030がマージされました）

13アセンブリはそれ自体ではコンパイルされず、FreeBSD固有の変更が必要です。 ほとんどの場合、Linux / OS X用にすでに存在する相互運用機能（ビルド出力での出現順に）：

• [x] System.Private.URI （完了、PR dotnet / corefx＃2032がマージされました）
• [x] System.Console （完了、PR dotnet / corefx＃2031がマージされました）
• [x] System.Diagnostics.Debug （完了、PR dotnet / corefx＃2039がマージされました）
• [x] System.Diagnostics.Process （ディスカッションdotnet / corefx＃2070、PR dotnet / corefx＃3257）
• [x] System.IO.Compression.ZipFile （完了、PR dotnet / corefx＃2041がマージされました）
• [x] System.IO.FileSystem.DriveInfo （ディスカッションdotnet / corefx＃2526、PR dotnet / corefx＃2606）
• [x] System.IO.FileSystem.Watcher （ディスカッションdotnet / corefx＃2046、PR dotnet / corefx＃3257）
• [x] System.IO.FileSystem （完了、PR dotnet / corefx＃2049がマージされました）
• [x] System.IO.MemoryMappedFiles （ディスカッションdotnet / corefx＃2527、PR dotnet / corefx＃3143）
• [x] System.IO.Pipes （ディスカッションdotnet / corefx＃2528、PR dotnet / corefx＃2974）
• [x] System.Net.NameResolution （ディスカッションdotnet / corefx＃2988、PR dotnet / corefx＃3471）
• [x] System.Security.Cryptography.Hashing.Algorithms （完了、PR dotnet / corefx＃2040がマージされました）
• [x] System.Security.SecureString （完了、PR dotnet / corefx＃2039がマージされました）
• [x] System.Runtime.Environment （dotnet / corefx＃1999によってブロックされています）
• [x] System.Runtime.InteropServices.RuntimInformation （完了、PR dotnet / corefx＃2068がマージされました）

開いてマージしたPRに基づいて、そのリストを更新しようとします。

参考：PR dotnet / corefx＃2039が統合されました

ここで時代の先を行くことを試みているだけです... System.IO.FileSystem.Watcherをどのように実装する予定ですか？

Iirc FreeBSDには、LinuxやWindowsのようなinotifyはありません（これが、前回チェックしたときにDropboxがない理由でもあります）。 これは私たちの道に来る問題の潜在的な原因になるでしょうか？ または、これを回避する方法について誰かがアイデアを持っていますか？

Stephen Toubが他のトピック（https://github.com/dotnet/corefx/pull/2021#issuecomment-111602342）で提案したように、今のところそれをスタブして、PlatformNotSupportedExceptionをスローすることをお勧めします。 次に、少なくともアセンブリの完全なセットがあり、それ以上の手順をブロックすることなく、その特定の問題に取り組み続けることができます。

そのために別の問題を開いていただけませんか。

System.IO.FileSystem.Watcherディスカッションをdotnet / corefx＃2046に移しましょう

みんなSystem.Diagnostics.Processためのそのようなブロッカーはありますか？

@ jasonwilliams200OKは今朝早くにFreeBSDをCheckPlatformTests内のFreeBSDテストはdotnet/buildtoolsが更新されるまでバックアウトする必要がありました。

• [] FreeBSDをサポートするようにビルドツールを更新します-https：//github.com/dotnet/buildtools/pull/180
• [] [Fact,PlatformSpecific(PlatformID.FreeBSD)]テストをCheckPlatformTestsに再適用します-https https://github.com/dotnet/corefx/pull/2068#discussion_r32570244を参照して
• [] https://github.com/dotnet/corefx/pull/2068にpublic static OSPlatform FreeBSDを追加します

@ jasonwilliams200OK昨夜、gitterのSystem.Diagnostics.Processについていくつかの議論があり、 https：//github.com/dotnet/corefx/issues/2070に形式化されました

@ghuntley 、ありがとう。 私は実際にそれらのメッセージを読みました。 System.Diagnostics.Processはトリッキーなものです。 AFAIK、io.jsチームは、FreeBSDプロセス管理に関して同様の課題を抱えていました。 モノチームはおそらくそれを釘付けにしているので、 @ akoeplingerと共同で期待し

System.IO.FileSystem.DriveInfo

ギッターで説明したように、これについては、 getmntinfo基本的な使用法を調べてみました。

#include <sys/param.h>
#include <sys/ucred.h>
#include <sys/mount.h>
#include <stdio.h>

int main() {
  struct statfs *mntbuf;
  int mntsize = getmntinfo(&mntbuf, MNT_NOWAIT);

  for( int i = 0; i < mntsize; i++ ) {
    printf("%s\n", mntbuf[i].f_mntonname);
  }
}

そのサンプルを実行すると、次の出力が得られました。

$ ./a.out
/
/dev
/tmp
/usr/home
/usr/ports
/usr/src
/var/crash
/var/log
/var/mail
/var/tmp
/dev/fd
/usr/compat/linux/proc
/proc
$

だから、それは私たちが必要なことをしているようです。 問題は、結果に対して何らかの種類のフィルタリングを行う必要があるかどうかです。

.NETのWindowsの世界から来たDriveInfoオブジェクトの「意図」を見ると、ファイルを保存または取得するために利用可能な場所を列挙することがよくあります（ C: 、 D:など）。 ただし、Unix階層ファイルシステムを使用する場合は、 /を返すだけでこれらのニーズに対応できます。

では、何を返す必要がありますか？ 何が役に立ちますか？ それが有用であるかどうかさえ考慮すべきですか？

Linuxバージョンは、無視するように設定されているものを除いて、すべてをダンプするだけです。

https://github.com/dotnet/corefx/blob/master/src/System.IO.FileSystem.DriveInfo/src/System/IO/DriveInfo.Linux.cs#L98 -L99

次のフィルターを入れてみましたが、出力に関しては何も変わりませんでした。

    if ((mntbuf[i].f_flags != MNT_IGNORE)) {
        printf("%s\n", mntbuf[i].f_mntonname);
    }

何か意見はありますか？

@josteink 、素晴らしい掘り出し物！ https://github.com/dotnet/corefx/issues/815#issuecomment -113825960およびhttps://github.com/dotnet/corefx/issues/1729に基づいて、@ sokketと協力して考え出す必要があると思いますさまざまなユニス間で機能するソリューション。

getmntinfoとstatfsを使用して各マウントポイントに関する情報を取得するバージョンがOSXで実行されています。これは、Windowsドライブの概念から最も論理的なマッピングのようです。 OSXの関数と構造体の定義がFreeBSDの定義と一致することを再確認します。一致する場合は、OSXのコミットがBSDでも機能します。

私のPR @ josteinkにあなたを必ず追加します

いいですね。 頭を上げてくれてありがとう、そしてFreeBSDにも愛を与えてくれてありがとう。

これらの機能の基本的なピンボークを調べたところ、すべてのマーシャリングと変換を自分で行う必要があるようです。他の誰かがすでに努力している場合、誰がノーと言いますか？ ;）

問題ありません...主な違いは構造体宣言にあったようです。 将来的にはもっとヒットする可能性があるため、多くのPInvokeシグネチャを共有できるようにするリファクタリングを行っています。 PRにもっと大きな説明を追加します（テストの実行方法に基づいて、今日または明日）が、基本的にFreeBSDのPInvoke署名と構造体署名（オンラインで見つけたヘッダーに基づく）を追加してコンパイルします。 私はMacでテストしたので、（理論的には...）FreeBSDで動作するはずです。これは、構造体宣言の変更にすぎないためですが、マイレージは異なる場合があります:)。 そうでない場合は、DriveInfoクラスとPInvokesが99％あり、FreeBSDのニュアンスに基づいて微調整する必要があります。

素晴らしいニュース@sokket。 ポートチームが開発に使用するマシンでアカウントを作成しました。これはヨーロッパベースですが、常にオンであり、大量のメモリと処理能力を備えています。 うまくいけば、これがFreeBSDで作業するときの摩擦の一部を助け、取り除くのに役立つでしょう。

# ssh [email protected]

パスワード認証が無効になっています。ください。

@josteink問題も参照してください： https ：

更新はありますか？ 誰かが残りのアセンブリをFreeBSDに実装しましたか？

私は新しい赤ちゃんの世話をするのに忙しく、どこにもコーディングする時間がありませんでした。

このような問題は休眠状態にあるのではないかと疑っていますが、これはある程度それを裏付けていると思います。

まだ実装されていないアセンブリについては、上記のリストの「実装方法」の問題をリンクしました。 これが、これらの残りのアセンブリを実装するための取り組みの調整に役立つことを願っています。

私たちが何をどこで行ったかを追跡するのに苦労していたことを認めなければならないので、それは間違いなく良い動きです。 よくできた ：）

どこにありますか？ 残りのアセンブリを入手できれば幸いです
実装されました。

25/07/15 22:10に、JanHenkeは次のように書いています。

まだ実装されていないアセンブリについては、「
実装する」-上記のリストの問題。調整に役立つことを願っています
これらの残りのアセンブリを実装するための努力。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/dotnet/corefx/issues/1626#issuecomment-124838781 。

このコメントはこちら： https ：

FreeBSDでこれらのアセンブリを動作させるための作業のほとんどをこれらが引き継ぐはずなので、私は現在、ネイティブシムが終了するのを待っています。

@nguerreraは、進捗状況をお知らせいただければ幸いです。 :)

アップデート：
@janhenkeは、 https：//github.com/dotnet/corefx/pull/2974がマージされ、 System.IO.PipesがFreeBSD上に構築されることを確認しました。 ：サングラス：

アップデート：
dotnet / corefx＃2527は終了し、 System.IO.MemoryMappedFilesはFreeBSD上に構築されています。
確認してくれてありがとう@janhenke ！

シムのアプローチのおかげで、シムがFreeBSDでコンパイルされることを確認することができます。 ありがたいことに、それは人生をずっと楽にしてくれます。 :)

dotnet / corefx＃3257は、 System.Diagnostic.ProcessとSystem.IO.FileSystem.Watcher両方をもたらし、 System.Net.NameResolution未解決のままになるはずです。 （PRがマージされてFreeBSDで動作したら、前述の2つのアセンブリを確認します）

dotnet / corefx＃3471はSystem.Net.NameResolutionをもたらし、上記のリストを完成させるはずです。

dotnet / corefx＃3471がマージされました:)

@sokket 、更新してくれてありがとう。 私はこのガイドを使用してFreeBSD上にマスター（f467911）を構築しました：https：//gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24。 現在のブロッカーはhttps://github.com/dotnet/buildtools/issues/292です。これはアップストリームで修正されていますが、次のbuildtoolsのロールアウトを待っています。 :)

更新：dotnet / buildtools＃292を修正した新しいbuildtoolsがCoreFXマスターに追加されました。 buildtoolsの次のストッパーはhttps://github.com/dotnet/buildtools/issues/300です：テストを実行できるOS固有のツールがありません。

@janhenke 、 System.Diagnostics.Process （＃2070）とSystem.IO.FileSystem.Watcher （＃2046）を完了としてマークしました。 しかし、それらは実装されておらず、FreeBSDでコンパイルされていません。 マネージコードをコンパイルして実際にリストを確認しましたか？

コミット60c78da3c918b0d256cc1f878de06d351dbe3342（ msbuild.logを参照）に関する最近の経験に基づくと、次のアセンブリはコンパイルされません。

• System.Diagnostics.Process
• System.Diagnostics.ProcessManager
• System.Diagnostics.ThreadInfo
• System.IO.FileSystemWatcher
• System.Net.SocketAddress _（わかりました、これは最近追加されました）_

私が覚えている限り、関連するシムのコンパイルを確認しました。 マネージコードにはFreeBSD固有のコードが含まれていてはならないためです。 あなたが言及するそれらのシムは、上にリンクされたPRでシムアウトされるべきでした。
しかし、その間にフルコンパイルも実行しました。 少なくともSystem.Diagnostics.ThreadInfoとSystem.IO.FileSystemWatcherはコンパイルされました。 したがって、何かが後退したに違いありません。

あなたが言及するそれらのシムは、上にリンクされたPRでシムアウトされるべきでした。

実際、PRhttps ：//github.com/dotnet/corefx/pull/3257はshimとは関係ありません。 管理対象プロジェクト内にはまだいくつかのPALコードがあります（古いアプローチ）。したがって、絶対に確実にするために管理対象アセンブリをビルドする必要があります。

実際、PR dotnet / corefx＃3257はshimとは関係ありません。

同意しません。 P / InvokeコードをSystem.Nativeシムにリファクタリングしています。 また、上記で編集したように、その間にコンパイルされたアセンブリの少なくとも一部を思い出します。

同意しません

https://github.com/dotnet/corefx/pull/3257/files ：のインスタンスを参照.Unix.csと.Linux.csについてSystem.Diagnostics. 。 .OSX.csは変更されていないことに注意してください。

P / InvokeコードをSystem.Nativeシムにリファクタリングしています。

はい、 System.Native下でいくつかの一般的なヘルパーをリファクタリングしますが、 System.Diagnostics.*はリファクタリングしません。

これらのアセンブリがSystem。* libsへのP / Invokingのみである場合でも、System.Diagnostics.ProcessやSystem.IO.FileSystem.Watcherなどの一部のアセンブリにはFreeBSDの作業が必要な場合があります。 彼らはLinuxとOSXに固有の機能を使用しており、ネイティブシムの背後でそれを抽象化しようとはしていません。 シムの目標は、Unix用の単一のマネージドバイナリで終わることではありませんが、それは仕事から来るときは非常に素晴らしいプロパティです。 主な目標は、脆弱性の原因となるABIの違いを回避することです。 少なくとも少数のアセンブリには、Linux / OS X固有のバイナリが引き続き含まれていると思います。ここでは、FreeBSDバイナリも必要になります。

参考までに、System.Diagnostics.ProcessManagerという名前のcorefxアセンブリはありません。
System.Diagnostics.ThreadInfo、
System.IO.FileSystemWatcher、または
System.Net.SocketAddress。 これらは他のアセンブリのタイプです。

少なくとも少数のアセンブリには、Linux / OS X固有のバイナリが引き続き含まれていると思います。ここでは、FreeBSDバイナリも必要になります。

それは、SolarisとAlpineサポートなどのLinuxを対象とする非glibc（muslとμlibc）が到着するたびに、別々のバイナリを持つことを意味しますか？ そして、異なるアーキテクチャのARM、MIPS、RISC、SPARCなどでは、別のレベルの分離が必要になりますか？

それらを可能な限りPOSIXインターフェース/ sys-callsに収束し、同じバイナリで使用される構成（CMake経由）を使用して違いを機能検出することは意味がありません（サイズ/パフォーマンスに影響を与えない限り）アセンブリが大幅に）？ 私が理解しているように、 System.Native.soバイナリには、他の特定のSystem.*.Native.soに対する共通のヘルパーがあり、関心の分離の原則に準拠するには十分と思われます。 ただし、 System.Net.Http.FreeBSD.ARM.Native.soまたはSystem.Net.Http.Solaris.SPARC.soに変換されると、「可動部品が多すぎる」などの理由で管理できなくなります。

名前の付いたcorefxアセンブリはありません

いい視点ね。 私は実際にmsbuildログの失敗インスタンスと.OSX.csおよび.Linux.csファイルの数を調べていました。 ：笑顔：

それらを可能な限りPOSIXインターフェース/ sys-callsに収束させることは意味がありませんか？

します。 POSIXを介してファイルウォッチングをうまく行うことをどのように提案しますか？ POSIXを介してプロセス列挙をうまく行うことをどのように提案しますか？

ただし、System.Net.Http.FreeBSD.ARM.Native.soまたはSystem.Net.Http.Solaris.SPARC.soに変換されると、「可動部分が多すぎる」などの理由で管理できなくなります。

わかりません。 ネイティブ.soファイルの要点は、ターゲットプラットフォームごとに異なるネイティブバイナリを取得することですが、それらの名前はSystem.Whatever.Platform.extではなく、System.Whatever.extだけです。 これにより、コンパイラは同じ一般的なロジックを使用して、そのプラットフォームに固有の定義で使用できます。 これは、各プラットフォームに同じシンボルが存在する場合にのみ機能します。 コンパイラは、inotifyを使用するように記述されたコードを魔法のように取得せず、他のシステムのファイル監視インターフェイスで動作できるようにします。 一般に、標準化されたAPIを適切な場所で使用するように努めましたが、そのようなAPIが存在しないか、十分に標準化されていない場所、またはより優れたプラットフォーム固有のソリューションがある場所では、より優れたプラットフォームを使用しました- Linuxでのプロセス列挙にprocfsを使用する、Linuxでファイルシステムを監視するためにinotifyを使用するなど、特定のソリューション。このようなプラットフォーム固有のロジックがマネージドコードにあるかネイティブコードにあるかは、移植のしやすさからそれほど重要ではありません。追加プラットフォームの観点。これらの新しいプラットフォームが登場したときのように、既存のAPIが機能する場合は、既存のソリューションも機能します。機能しない場合は、そのプラットフォーム用の新しいソリューションを作成する必要があります。 そのため、ターゲットAPIが移植可能である場合に、マネージコードをはるかに移植可能にする1：1シムにネイティブを使用して、マネージコードで可能な限り多くのことを実行しようとしました。 ネイティブコードで#ifdefを使用して、細部を詳しく説明しました。どのプラットフォームのこのAPIは、別のプラットフォームのAPIに十分に近いですが、ソリューション全体が完全に異なるわけではありません。 その時点で、抽象化はマネージAPIになり、システムごとに異なるマネージ実装を実行します。

FreeBSDがLinuxのようにinotifyを公開する場合、またはOS XのようにEventStreamを公開する場合、それらのOS APIがshimの背後にあると、shimをFreeBSDで簡単に動作させることができ、同じマネージドバイナリをFreeBSDで使用できます。 FreeBSDがそのようなAPIを公開していない場合は、FreeBSDで利用可能なファイル監視ソリューションを使用してSystem.IO.FileSystem.Watcherのカスタム実装を作成する必要があります。 System.Diagnostics.Processに対する同様のコメント。 ファイル監視のコードがシムにあるかどうかは、ほとんど影響しません。

計画では、そのようなすべてのネイティブAPIを最終的にシムの後ろに移動する予定です。 しかし、それらはあまり移植性がないため、優先順位からはほど遠いので、どこにでも公開されている（または公開されることになっている）libcのAPIから始めているのを見てきました。

POSIXを介してファイルウォッチングをうまく行うことをどのように提案しますか？

inotifyはLinux固有であるため、すべてをPOSIXで実行することはできません。 FreeBSD / OSXは、個別の実装を提供します。

提案：

ネイティブバイナリ配布の観点から、すべてのOSは、同じ名前で機能が異なる同じバイナリセットを受け取る必要があります。

提案された構造は次のとおりです。

# cmake

check_include_files( "inotify.h" HAVE_INOTIFY_ABILITY )

// config.h.in
cmakedefine01 COREFX_HAVE_INOTIFY_ABILITY
// always a good idea to prefix our headers with project id :)

// header (pal_fsw.hpp) file

#pragma once

class file_system_watcher_shim
{
public:
  void common_function_for_posix_compliants();
  void slightly_diverged_function();
  void painfully_diverged_watch_function();
}

// source (pal_fsw_commons.cpp) file

#include "pal_fsw.hpp"

void file_system_watcher_shim::common_function_for_posix_compliants() {
 // TODO: implement common function for all
}

void file_system_watcher_shim::slightly_varied_function() {

#if COREFX_HAVE_XYZ_ABILITY

  // your way

#else

  // my way

#endif // COREFX_HAVE_XYZ_ABILITY

}

// source (pal_fsw_inotify.cpp) file

// this is a separate compilation unit and will clash with others,
// therefore guarding it with preprocessor directive

#if COREFX_HAVE_INOTIFY_ABILITY

#include "pal_fsw.hpp"

void file_system_watcher_shim::painfully_diverged_watch_function() {
 // TODO: implement inotify based watcher
}

#endif // COREFX_HAVE_INOTIFY_ABILITY

// source (pal_fsw_non_inotify.cpp) file

// this is a separate compilation unit and will clash with others,
// therefore guarding it with preprocessor directive

#if !COREFX_HAVE_INOTIFY_ABILITY

#include "pal_fsw.hpp"

void file_system_watcher_shim::painfully_diverged_watch_function() {
 // TODO: implement non-inotify way
}

#endif // !COREFX_HAVE_INOTIFY_ABILITY

これは本質的に私たちが持っているものです、例えば

• 「common_function_for_posix_compatibles」は、共有Unixマネージバイナリのロジックから消費されるネイティブシムの1：1関数です。
• 「slightly_diverged_function」は、ほぼ1：1のネイティブ関数であり、共有Unixマネージバイナリのロジックからいくつかのネイティブ#ifdefが消費されます。
• 「painfully_diverged_watch_function」は、プラットフォーム固有のマネージバイナリのロジックから消費されるネイティブシムの1：1関数です。

本当の違いは、「痛々しいほど分岐した」ロジックを実装するコードがC＃で行われるかC ++で行われるかであり、C＃を選択し、すでにすべてC＃で実装されています。 そのような場合にすべてをC ++で書き直すことが、はるかに説得力のあるオプションになる理由について、説得力のある議論は見たことがありません。

@ jasonwilliams200OK今日のmonoへのアップデートで、FreeBSD自体にcorefxを再度ビルドします。 前回ビルドしてから、たくさんの新しいエラーメッセージがあります。
Interop.Libcが最終的になくなるのだろうか？

@stephentoubそれはすべてパッケージングに
さらに、これらの「プラットフォームに依存するマネージコードの汎用実装が必要だと強く思います。NotImplementedExcpetionをスローするだけでも。そうすれば、少なくともすべてをすぐにコンパイルすれば、新しいプラットフォームへの移植がはるかに簡単になります。少なくともサポートされていないプラットフォームで実行してみるチャンス。
一般に、少なくともすぐに正常にコンパイルできれば、はるかに簡単です。

@stephentoub 、申し訳ありませんが、C ++とC＃を混在させていました。 これで、ネイティブレイヤーがこれらのエントリポイント（ネイティブライブラリの関数またはシステムコール）を公開し、IOとマネージコードをサニタイズすることで、プラットフォーム固有のラップされたユーティリティメソッド/ラップされたシステムコールを使用するかどうかを決定できることがわかりました。 さらに、両方の（ネイティブ層とマネージド）層は、POSIX以外の機能が消費されるOSに依存しないものにすることはできません。

@janhenke 、同意します。 私も話しているようにマスターを構築しています。 別の定期的なアセンブリ署名の問題があります、私は打っています：

CSC : error CS7027: Error signing output with public key from file '/root/corefx/packages/Microsoft.DotNet.BuildTools.1.
0.25-prerelease-00104/lib/ECMA.snk' -- mscoree.dll [/root/corefx/src/System.IO.Compression.ZipFile/ref/System.IO.Compres
sion.ZipFile.csproj]
CSC : error CS7033: Delay signing was specified and requires a public key, but no public key was specified [/root/corefx
/src/System.IO.Compression.ZipFile/ref/System.IO.Compression.ZipFile.csproj]

CSC : error CS7027: Error signing output with public key from file '/root/corefx/packages/Microsoft.DotNet.BuildTools.1.
0.25-prerelease-00104/lib/ECMA.snk' -- mscoree.dll [/root/corefx/src/System.IO.Compression/ref/System.IO.Compression.csp
roj]
CSC : error CS7033: Delay signing was specified and requires a public key, but no public key was specified [/root/corefx
/src/System.IO.Compression/ref/System.IO.Compression.csproj]

完全なmsbuild.log要点リンクをまもなく投稿します。

さらに、これらの「プラットフォームに依存するマネージコード」の汎用実装が必要だと強く思います。

同意します。 部分クラスの代わりに、抽象基本クラスの共通およびほとんど共通の仮想メソッドで継承を使用し、必要に応じて「ほとんど共通/部分的に異なる」をオーバーライドできます。 次に、OSごとにまったく異なる抽象メソッドを実装します。 このアプローチIMOを使用すると、専門化/一般化によってDRYが失われている場合に、複数度の継承の祖先を従業員にすることができます。 しかし、前回チェックしたとき、CoreFXでは親子の関連付けよりも部分的なクラスが優先されていました（何らかの理由で思い出せません）。 :)

コミット2d36889のmsbuild.logは次のとおりです。

https://gist.githubusercontent.com/jasonwilliams200OK/b375ce52c7b0c90e24af/raw/c895d405a3044dd6acdb26ec49c4b0ced0c76d1a/corefx-msbuild.log

/ cc： @akoeplinger

@ jasonwilliams200OKなぜそんなに複雑なのか。 必要なのは、プロジェクトファイルの「Windows、Linux、OSXでない場合」の状態だけです。 したがって、ビルドにプラットフォーム固有のファイルセットを含めるか、汎用ファイルを含めます。

一部のアセンブリがFreeBSDでビルド/動作できないという事実は、残りのアセンブリをテストするための主要なブロッカーになるはずだとは思いません。 FreeBSDでのビルドとテストの実行で、作業が保留されているもの（FileSystemWatcher、Process、Networking）がスキップされるようにする必要があります。 次に、すでに機能しているもののリグレッションを防ぐプロセスを持ちながら、それらを個別に立ち上げることができます。

一部のアセンブリがFreeBSDでビルド/動作できないという事実は、残りのアセンブリをテストするための主要なブロッカーになるはずだとは思いません。

同意しました

FreeBSDでのビルドとテストの実行で、作業が保留されているもの（FileSystemWatcher、Process、Networking）がスキップされるようにする必要があります。

または、 @ janhenkeが提案したのと同様に、PlatformNotSupportedをスローするファイルを

@ellismgの最近の変更（＃3684）を使用すると、以前の方法（https://github.com/dotnet/coreclr/issues/1633#issuecomment-143669303）を簡略化してテストを実行できます。

• https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 （特に、ネイティブシムを個別にビルドするステップ_後_、build.shがステータス1で終了した後）、 CoreCLRアーティファクトzipをダウンロードします： cd /root; curl -o bins.zip "http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/debug_freebsd/lastSuccessfulBuild/artifact/*zip*/archive.zip （忘れないでください） URLを引用符で囲みます）、次にunzip bins.zip; chmod -R 0777 archive/; rm bins.zip; cd corefx 。

（Windowsマシンからは何も必要ありません）

• テストを実行しました：

./run-test.sh \ --coreclr-bins ../archive/bin/Product/FreeBSD.x64.Debug \ --mscorlib-bins ./packages/Microsoft.DotNet.CoreCLR/1.0.0-prerelease/lib/aspnetcore50 \ --corefx-native-bins ./bin/FreeBSD.x64.Debug/Native

それは言う：

40回のテストに失敗しました

一部のアセンブリがFreeBSDでビルド/動作できないという事実は、残りのアセンブリをテストするための主要なブロッカーになるはずだとは思いません。

私はこれに同意する必要があります。 テストを開始する前にすべてが完了するのを待つのではなく、行った作業のQAを開始することをお勧めします。

それは言う：40のテストが失敗した

いくつのうち40？ 私たちはどの球場にいますか？ :)

いくつのうち40？ 私たちはどの球場にいますか？ :)

私も殴ります。 テストはテストアセンブリ（マネージドdll）から生成されており、テストの総数は表示されません。

スクリプトが最後に生成する数は、失敗したテストアセンブリの数です。 xUnitは、実行の一部として、アセンブリごとに失敗したテストの数をstdoutに書き込む必要があります。 番号は、各テストアセンブリフォルダーで生成されるXMLファイルにも含まれている必要があります。

ランタイムもクラッシュしている可能性があり、その場合、テストアセンブリごとにログが生成されない可能性があります。

@ jasonwilliams200OKアセンブリの署名の問題で進展があったかどうか知っていますか？ 私はUbuntuでも同じことをしています。 誰もそれに取り組んでいない場合は、おそらく別の問題を開く必要があります。

@ naamunds 、 https：//github.com/dotnet/corefx/issues/3739の一部としてCoreFXマスターで修正されました

更新-今日、私はFreeBSDでテストを実行しましたが、何千ものテストが合格し、System.Diagnostics.Processと友人のsnafuが明らかに不足しているために失敗するものもありました。 約40分間正常に実行された後、System.IO.FileSystemテストでハングしました（Ctrl + Cを押して終了する前に約15分間）。

@ jasonwilliams200OKどのようにしてfreebsdでcorefxをコンパイルしましたか？ gssapiに関するエラーで立ち往生しています

@sec 、これらのメモを作成する時点で： https ：//gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24、GSSAPIはCoreFXでは必要ありませんでした。 ただし、pkgは最近FreeBSDに移植されたようです： http ： pkg upgrade pkg && pkg update && pkg install p5-GSSAPIを試してみてください。

@ jasonwilliams200OK 、私はすでにこれを手に入れました（perlext。btw。）問題はgssapi_ext.hがありませんでした。 秘訣は「pkginstallkrb5」を実行することでした-現在はネイティブコンパイルされています。
それらをcoreclrランタイムにコピーしましたが、それでもASP.NETCoreアプリを実行できません:)その後戦いが続きます。

このタスクの現在のステータスは何ですか？ @janhenkeのリストは完全で正確ですか？ 実行する必要のあるすべての作業は実行されていますか？ それなら閉めるべきですよね？

もしそうなら、なぜ私たちはまだこのタスクを持っているのですか？ https://github.com/dotnet/corefx/issues/2070

まだやるべきことがある場合、現在の状況に基づいて新しい問題を登録する必要がありますか？

これも必要だと思います-dotnet / corefx＃2046

現在の状況に基づいて新しい問題を登録する必要がありますか？

はい：+1：

FreeBSDのコミュニティ主導の移植について、 @ RussellHaley （FreeBSDコミュニティから）と@wfurt （.NET Coreチームから）と
これが私たちがまとめた計画提案です（フィードバック/提案は大歓迎です）：

1. FreeBSDをターゲットにしたCoreCLRおよびCoreFXリポジトリでバイナリを生成します-ハックを使用しても問題ありません
   
   
   
   • 並列化するのは難しいですが、 取り組みます
   
   
   • ビルドは、FreeBSDを対象とする他のプラットフォーム（Mac、Linux）からのビルドを組み合わせて使用​​できます。
   
   
   • FreeBSD固有のバグ修正を使用してビルドを再現するには、文書化された手順（FreeBSD wiki上）が必要になります。
   
   
2. CoreCLRテストの実行と安定化（corerunを使用）
   
   
   
   • テストは別のプラットフォームで構築できます
   
   
   • 目標：ランタイムの基本的な品質を提供します
   
   
3. CoreFXテストの実行と安定化（corerunを使用）
   
   
   
   • テストは別のプラットフォームで構築できます
   
   
   • これにはxunitが必要であることに注意してください。 過去の移植経験に基づいて、[2]が完了すると、xunitは正常に機能すると考えています。
   
   
   • これは理論的には[2]と並列化できます-xunitのショートカットが必要になる場合があります（たとえば、別のプラットフォームで静的実行レシピを生成する）
   
   
4. FreeBSDでのフルスタックビルド（[1]-[3]のブートストラッパーとしてcorerunを使用）
   
   
   
   • .NET Coreのブートストラップに取り組むには、すべてのツール（nuget、msbuild、roslyn）が必要です。
   
   
5. インストーラー（FreeBSDポート）
   
   
   
   • 第1段階：Nugetフィードの製品バイナリを使用する
   
   
   • 第2段階：ソースから製品をビルドします（ソースからのビルドでブロックされます）
   
   
   • FreeBSDコミュニティの専門知識と設計に関するガイダンスが必要です
   
   
   • 注：FreeBSDパッケージは、公式の.NETCoreダウンロードページからコミュニティサポートパッケージとしてリンクすることもできます。
   
   
6. FreeBSDでの定期的なビルドとテストの実行
   
   
   
   • 目標：FreeBSDを破る.NETCoreリポジトリの変更が早期に知られていることを確認する
   
   
   • 必要な設計
   
   
   • FreeBSDコミュニティの専門知識と設計に関するガイダンスが必要です
   
   

動作原理：

• [2]-[4]の変更は、主にCoreCLR / CoreFXリポジトリで行う必要があります（CLA署名要件、.NET Coreチームの専門家/メンバーによるコードレビューなどのため）。
• この問題に関する高レベルの作業を追跡します。 特定のバグは別の問題として提出されます。

誰かが助けに興味があるなら、ここで私たちに知らせてください。 [1]で十分な距離があれば、上記の[2]と[3]の作業項目を簡単に配布できます。

提案の最新バージョンは、この問題のトップポストにあります。

freebsd-monoリスト（このスレッド）に興味を示したより多くの人々にタグを付ける： @smortex @radovanovic @ Echo-8-ERA

ところで： Mathieu PrevotGitHubアカウントが見つかりません-[更新] https://github.com/dotnet/corefx/issues/1626#issuecomment -330348424で見つかりました：@mprevot

NetBSDの場合、堅牢なposixミューテックスが欠落しています。これは、名前付きrobusミューテックスを生成するためにまだ欠落している唯一の機能です。 LLDB / NetBSDでマネージコードの失敗をデバッグできるようになりました。コアファイルで正常に動作します。 以前の試みでは、LLDBにこの機能がないために死亡しました（このデバッガーを.NETに移植し始めました）。

より良いFreeBSDサポートを持つことは大いに役立ちます。

過去には、NetBSDビルドボットをCIマシンに接続し、パッチを検証するためのHypervゲストサポートがないという問題もありました...このためには、MSの支援が必要な場合があります。 それを実行するには、私が所有していないプロプライエタリソフトウェアが必要だと思います... NetBSD FoundationとMicrosoftの間に共同の利益（投資）があれば、開発者がその仕事をするかもしれません。

「堅牢なposixミューテックス」をどこで見逃しますか？ .NET Core PALの一部ですか？

どのCIシステムを参照していますか？ なぜそれが.NETCoreポートの取り組みに結びついているのですか？

「堅牢なposixミューテックス」をどこで見逃しますか？

NetBSDカーネル（およびlibc / libpthread）では、これはCoreCLRの一部です。 FreeBSDは過去2年間にそれを開発しました。 最新の安定版リリースで利用できる可能性がありますが、確認する必要があります。

.NET移植を再開する前に、この機能を追加したいと思います。 （ネットワークルーティング用の小さな欠落しているAPIも検出されました。しかし、今はスキップします）。

.NET Core PALの一部ですか？

コードをチェックせずに、今は覚えていません。これは、堅牢なミューテックス（またはおそらくsemapthores）という名前の.NETの実装に使用されるAPIです。

どのCIシステムを参照していますか？

NetBSD。

なぜそれが.NETCoreポートの取り組みに結びついているのですか？

前回見たときはオプション機能でした。 カーネルインターフェイスとユーティリティ（LLDBなど）で機能のパリティを取得することにしました。 機能的なビルディングブロックを取得し、後で家を建てるという私のスタイルの仕事です。 とにかくいつか必要になるので、一度に開発してみませんか。 理解に感謝 ：）

おそらく、GHのfreebsd-dotnetグループにタグを付けることができますか？ 彼はそこのメンバーです（またはあなたは彼のアカウント名を調べることができます）。 彼のメールアドレスは[email protected]です。

[編集] @karelzによる聞いたメールと以前の返信を削除する

@RussellHaleyは、適切だと思われる場合は、より大きなグループにタグを付けてください。 マシューのGHアカウントを彼の名前やメールで見つけることができなかったので、それが上記の意味でした（BTW：メールで直接彼にpingを送信しました）。

グループのタグ付けについて見ていきます。

これがマシューのアカウントです。 おそらくプライバシー設定？

https://github.com/mprevot

乾杯、

ラス

13:01時月、2017年9月18日には、カレル・Zikmund [email protected]
書きました：

@RussellHaleyhttps ：//github.com/russellhaleyお気軽にタグを付けてください
あなたがそれが適切であると思うならば、より大きなグループ。 マシューのGHが見つかりませんでした
彼の名前やメールでのアカウント、それは私が上で意味したことです。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/dotnet/corefx/issues/1626#issuecomment-330338996 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/ACENF_N6mtOo3fptvku-LUMioNpZG7coks5sjswWgaJpZM4EPG-N
。

ここで言及されている場所はどこにも見当たりませんが、ここでターゲットにしているFreeBSDの最低バージョンはどれですか（少なくとも10以降、おそらく9も想定しています）。
（私はまた、mono @freebsdメーリングリストでどのような議論が行われるべきか、そしてここで何が起こるべきかについて少し混乱していますか？）

ええと、Fedoraが行くべきものなら、MSは現在サポートされているバージョン、つまり10.3（まもなく10.4）と11.1のみをサポートします。

@radovanovic FreeBSD 9はサポートされなくなりました。2018年4月に10がEoLになり、2021年に11になります。私の経験から、11対10（必要に応じて9）でのコンパイルに問題はないはずです。 FreeBSDは、下位互換性を念頭に置いて開発されています。

@radovanovicまた、 mono @ freebsdメーリングリストでどのような議論が行われるべきか、そしてここで何が起こるべきかについて少し混乱しています。

これはmono @ freebsdメーリングリストよりも幅広い聴衆であるため、ここでの技術的な議論、作業の調整、およびステータスを期待していました。 OTOH 1つの問題について何億ものランダムな議論をしたくないので、妥当な回答数を超えた場合は、特定の設計に関する議論をこの問題とは別の問題にまとめる可能性があります。

私はついにFreeBSD11.0でcorefxテストを実行することができました（outerloopテストなしで）
合格総数：144208
失敗した合計：2622
合計スキップ207

https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSDを手順で更新し
本格的な戦闘が始まります。 ボランティアが必要です。

そして、はい、私は提案されたステップ2をスキップしました。 私もそれに戻ります。

進行中の変更により、現在の統計は次のようになります。
合格総数：238892
失敗した合計：58
合計スキップ1628

System.Runtime.Tests.dll、1
System.Net.Ping.Functional.Tests.dll、7
System.Net.NameResolution.Pal.Tests.dll、3
System.Net.NameResolution.Functional.Tests.dll、4
System.IO.MemoryMappedFiles.Tests.dll、1
System.IO.FileSystem.Tests.dll、7
System.Globalization.Tests.dll、2
System.Drawing.Common.Tests.dll、31
System.Console.Tests.dll、2

dotnet / corefx＃24538は、壊れたカップのサポートを追跡するために開かれました。

大きな進歩です！ ツリー内でFreeBSDをサポートしているときにNetBSDを追加するのは簡単なはずです。

@wfurtはEメールアドレスを共有してください、私は数行を落とします。

初期サポートはマスターブランチにマージされました。 ビルドは、WIKIページで説明されているように機能するはずです。
私はdotnet / corefx＃24386でゆっくりと進んでいますが、それはほとんどのユーザーを妨げるべきではありません。

FreeBSDで.NETをすでにブートストラップできますか？

しばらく試していない@krytarowskiツールを2.0リリースに更新するプッシュがあり、その努力が安定するのを待っていました。 もう一度試して、更新を投稿します。

こんにちは。clrが管理するテストが実行されていないので困っています。 https://pastebin.com/B5KhtKX5

それはしばらくの間問題であったので、どんな入力でも素晴らしいでしょう。 また、最近、Windowsでのcorefxビルド（マスター、Gitリビジョン749194e）でビルドエラーが発生しました。 https://pastebin.com/JXUySLTY

それは断続的な問題だと思いますが、今夜は遅くなりました。

エラーを見ると：

tests/runtest.sh: line 786: ((: i<: syntax error: operand expected (error token is "<")

そして、問題のあるコード行：

bash for (( i=0; i<$maxProcesses; i++ )); do

私の直感では、 $maxProcessesが定義されていないため、ブール式が不完全になります。

diff +for (( i=0; i<$maxProcesses; i++ )); do -for (( i=0; i<; i++ )); do

これはかなりテスト可能であるはずです。 もしそうなら、あなたはあなたがどのようにしてこのようになってしまったのかを見つけるために後ろ向きに狩りに行く必要があります。

ご協力いただきありがとうございます！ @josteink :)その通りです。 パッチはここにあります： https ：

これにより、テストを実行できますが、同じ性質のエラーが約1000回発生することを諦めました。

失敗-JIT / Methodical / casts / iface / _il_dbgiface2 / _il_dbgiface2.sh
実行を開始
/usr/home/russellh/Git/coreclr/bin/tests/Windows_NT.x64.Debug/Tests/coreoverlay/corerun _il_dbgiface2.exe
coreclr_initializeが失敗しました-ステータス：0x80004005
予想：100
実際：255
実行の終了-失敗しました

さて、 @ janvorliからの非常に優れた情報によると、ビルドインデバッグの一部を実行していました。 恥ずかしいコピー/貼り付けの間違い。 私は今再建しています。

https://github.com/dotnet/coreclr/issues/1419

パッチはここにあります： https ：

壊れたビルドを修正するパッチがある場合は、プルリクエストとして送信して、すべての人が修正できるようにすることをお勧めします:)

ありがとう！そうするよ。 私はまだテストを実行するために取り組んでいますが、昨夜、その後のエラーの原因がわかりませんでした。

私は、Netcore 2.1（リリース後）に対するFreebsd 11の「pkginstall」サポートは起こらないと思いますよね？

TLDR; 多くの作業が行われていますが、それを家に持ち帰る人が必要です。 ポートMakefileの作成は簡単です。

@wfurtは、Linuxを使用してCLRとFXをビルドすることができましたが、ほとんどテストされていませんでした。 「ネイティブ」パーツをFreeBSDでビルドすることはできましたが、マネージパーツをWindows（FreeBSD用）でビルドすることはできませんでした。 全体として、オペレーティングシステム間でファイルを転送するという混乱がありました。

[email protected]メーリングリストとは@ dragonsaはLinuxエミュレーションを使用してMintOSからDotNet Core 1のバイナリバージョンとすべてのツールチェーン（msbuild、nugetなど）をインポートしました。 私は彼のパッチを使用していくつかのツールを実行することができましたが、何かを構築することはできませんでした。 これらのパッチがまだコミットされているかどうかはわかりません。 私はそれらをレビューしている最中で、転職しました。 私は現在の役割にDotNetを持っておらず、現在他のことを急いでいます。

それはどういう意味ですか？ 誰かが@dragonsaのパッチを検証[email protected]メーリングリストにジャンプすることをお勧めします。 https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html

@russellhadleyラッセルの

やあ、

ここで.NET開発者とこれについて議論し、FreeBSDポート/パッケージの開発を支援したいと思います。

完全な開示：私は.NET開発者ではありませんが、これをツリーに組み込むために誰とでも協力したいと思っています。

〜cy

@cschuber忙しすぎて現在の状況を監視できませんでしたが、FreeBSDパッチをたくさん提出し、3年ほど前にHello Worldを実行できた人として、ようやくできたら素晴らしいと思います。この事が適切に着陸するのを見てください。 あなたは私の完全なサポートを持っています:)

@cschuber 、現在アクティブな問題はhttps://github.com/dotnet/coreclr/issues/18067です。 主にこれらの4つの機能は残されていますhttps://github.com/dotnet/corefx/issues?q=is：open + label：os-freebsd + label ：up-for-grabs + is：issue、その中にはファイルシステムウォッチャーが含まれているようです最もトリッキーで骨の折れるものhttps://github.com/dotnet/corefx/issues/2046。

@cschuberのオファーをありがとう。 私たちは、それが可能になるかもしれない時期にほぼ近づいています。
私たちは最近、 @ mateusrodriguesと機能させることに取り組んでおり、彼はPowerShellを機能させようとしています。 送信されたリスト@ kasper3は、主に不足している機能です。 今のところPNSPを投げることができると思います。 私の予想される最も差し迫った問題は、dotnet / corefx＃30698とhttps://github.com/dotnet/coreclr/issues/18481です。 コミュニティの誰もがそれらを掘り下げることができれば素晴らしいでしょう。 最近はテストをしていませんが、失敗が増えるのではないかと心配です。
新しい失敗したグループごとに問題を開く必要があります。

ソースビルドの修正も開始しますが、まだいくつかの課題があります。
c＃コンパイラはc＃で記述されています。 現在の.netビルドは、以前のバージョンの.netを使用してマネージアセンブリを生成します。 また、Nugetのパッケージにも依存します。
現在、FreeBSDでcoreclr、corefx、およびその他のいくつかのリポジトリをビルドできる十分なブートストラップcliがあります。 2.1の変更とソースビルドを反映するために、ビルド手順をまだ更新していません。

+1これがまだ勢いを持っていることを嬉しく思います。 非常に多くの可動部分を追跡するのは難しいですが、人々は進歩しているようです。 少し前にhttps://github.com/dotnet/coreclr/issues/6115を作成しましたが、作業中のプロジェクトが保留になりました。 私はそれが1日pkg install dotnet && dotnet build同じくらい簡単であることを本当に望んでいます（Linux互換なしで）。

これも楽しみにしています

現在、デイリービルドを行っています。 ここでランタイムまたはSDKを取得できます： https ：
https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-freebsd-x64.tar.gz

LinuxやWindowsなどでクロスターゲットすることも可能です。 dotnet publish -r freebsd-x64を実行すると、自己完結型のFreeBSDアプリケーションが作成されます。

それはまだ不完全でサポートされていませんが、誰もが貢献しやすくなるはずです。
人々がそれを試して、問題を報告することができれば素晴らしいでしょう。
また、これは、機能のギャップを埋めてバグを修正するための最後のプッシュに適した時期です。

cc： @mateusrodrigues

よくできました、 @ wfurtと@bartonjs。

2〜3年前に最初のFreeBSDコミットを提案したとき、私は実際にここに来るとは思っていませんでしたが、確かに試してみたかったのです。

これは間違いなく大きなマイルストーンであり、新しい貢献者が移植を完了するのを容易にすることを願っています。

ここまで到達するのを手伝ってくれたすべての人に感謝します👍

大きな進歩です！ 私はまだツールチェーン（LLDBとLLD以外のほとんどのLLVMプロジェクトが終了しています）とNetBSDのハードウェア支援仮想化（Linux / BSDはVTxの致命的な例外まで起動を開始し、FreeDOSのような単純なOSはすでに機能しています）と戦っています。私のNetBSDの移植、できれば遅かれ早かれ。 より良いFreeBSDサポートは、より簡単な再開に役立ちます。

素晴らしい ：）

酔っ払いを祝うのはなぜensilbombsrdment ??

@krytarowski 「FreeBSDサポート」をより良くする方法を開発できますか？

FreeBSDの第一人者がhttps://github.com/dotnet/coreclr/issues/22124を見てくれれば素晴らしいと思いますが、11用のバイナリビルドは12で実行されると思いますが、そうではないようです;（
シンプルなアプリで簡単に再現でき、12.0リリースはdotnetが依存しているものを壊しているようです。

こんにちは、私は第一人者ではありませんが、Lua53ポートで12-RELEASEのスレッドリグレッションに遭遇しました。
元のバグについては、 https ： ください。
識別されたベースシステムのバグについては、 https ：

Luaからの-pthreadの要件がゼロであっても、Luaの修正は-pthreadに対してリンクすることです。

@RussellHaleyに感謝します。 それは有望なリードのように見えます。

お役に立てて嬉しいです。 一緒に遊んでみたいのですが、Luaポートを維持するのに必要な時間はほとんどありません。 これからもいい結果を出し続けてください！

coreclrで修正した人として、ビルドを実行するためにパッチを適用する必要があったため、pthreadはほぼ一貫して使用されていると思います。

そうは言っても、「通常の」スレッドを使用する、私が触れる必要がなかった基本的なバットやピースがあるかもしれません...

たぶん、一般的な実装についてもっと知っている誰かがチャイムを鳴らすことができますか？ @janvorli ？

これで問題が解決します。

[furt<strong i="6">@daemon</strong> ~]$ LD_PRELOAD=/usr/lib/libpthread.so ./dotnet-3.x/dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview-010021
 Commit:    d5c97b7c2a

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  12
 OS Platform: FreeBSD
 RID:         freebsd-x64
 Base Path:   /usr/home/furt/dotnet-3.x/sdk/3.0.100-preview-010021/

Host (useful for support):
  Version: 3.0.0-preview-27218-01
  Commit:  d40b87f29d

.NET Core SDKs installed:
  3.0.100-preview-010021 [/usr/home/furt/dotnet-3.x/sdk]

.NET Core runtimes installed:
  Microsoft.NETCore.App 3.0.0-preview-27218-01 [/usr/home/furt/dotnet-3.x/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

大規模なテストは行いませんでしたが、少なくともdotnet再度実行できます。

わかりました。dotnet実行可能ファイルがLinux以外のシステムのpthreadにリンクされていないことがわかります。
https://github.com/dotnet/core-setup/blob/2ef0b64810530961f492c33d37fc7509128e0a9b/src/corehost/cli/exe.cmake#L59 -L61

これを修正するための答えは、思ったほど簡単だということですか？ つまり、これと同じくらい簡単ですか？ https://github.com/josteink/core-setup/commit/25657ba2e181cce401acd7f4bf9d27a08a668470

もしそうなら、私はそれをPRにしたいと思います。

はい、そう思います。 @joperatorが確認するのを待ってい
「dl」も必要かどうかはわかりませんが、PR @ josteinkを送信すると解決できます。

右。 私の悪い。 だからもっとこのように： https ：

そのためのPRを作成しました。 修正が必要な場合はお知らせください： //github.com/dotnet/core-setup/pull/5072

右。 私の悪い。 だからもっとこのように： josteink / core-setup @ a08f38e

そのためのPRを作成しました。 修正が必要な場合はお知らせください：dotnet / core-setup＃5072

参考までに、これはすでにベースシステムにパッチが適用されているようです： https ：

dotnet / coreclr＃22124の主な問題は
FreeBSD12.0で自己完結型のアプリを公開しようとしたときにのみ問題が発生します。

freebsd-x64の公式NuGetパッケージは、.NET Core 3.0プレビュー2以降削除されており、それ以降、FreeBSD用のアプリを公開できませんでした。 3.0でそれらを再度有効にする計画はありますか？

残念ながら、FreeBSDの起動の優先順位を下げる必要があり（エンドツーエンドのAzureサポートのさまざまな理由と困難さのため）、. NET Core3.0では優先順位が付けられません。
現在の状態で半機能を維持したいのですが、今は投資する時間があまりありません:(。

@karelz返信ありがとうございます

@ hjc4869または、モノラルを試すことができます。 IIRC、.NET Standard3.0をサポートします

もう一度試してみるつもりですが、 @ karelzが

@newsashMonoは私にとって受け入れ可能なオプションです。 ただし、既存の.NET Corecsprojファイルにモノラルターゲットを追加してプロジェクトをビルドするのは難しいことがわかりました。

Linuxマシンで、net472をTargetFrameworksに追加し、FrameworkPathOverride変数を設定しようとしましたが、うまくいきませんでした。 .NETFrameworkではなくmonoと.NETCoreの両方で実装されているAPIを使用すると、monoでのビルドに失敗します。 さらに、monoは.NET Standard 2.1をサポートしていますが、net472csprojに.NETStandard 2.1dllへの参照を追加できませんでした。

別のcsprojを追加して、dotnetツールを使用する代わりにmono msbuildを使用する必要がありますか、それとも問題に関する提案がありますか？

簡単なコメント。

最近の発表[1]によると、monoが.NET 5に飲み込まれようとしているため、FreeBSDに適切なサポートを提供することが急務となっています。

Monoは、非常に優れたクロスプラットフォームサポートを備えていることが証明されており、FreeBSDポートから問題なくビルドできます。 このOSには多くの独自の機能があるため、多くのショップがFreeBSDで.netロードを実行しています。 これまでのところ、monoはギャップを埋めてきましたが、.NET 5では、近い将来、monoがNET 5に統合され、FreeBSDコミュニティが.NETエコシステムから完全に切り離される可能性があります。

Dotnetは、これが発生するかなり前に、成熟したFreeBSDサポートを持っている必要があります。

Microsoftはこの時点でFreeBSDを公式にサポートし、すべてのdotnetツールがこのプラットフォーム上に構築されるようにする必要があると思います。

@jasonpugsleyはhttps://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSDの手順をまとめ、 @ joperatorはソースビルドをhttps：// githubで機能させようとしてい

corefxで失敗した最後のテストは約30回あります。

System.Diagnostics.Tests.ProcessTests.TestPeakWorkingSet64
System.Diagnostics.Tests.ProcessTests.TestPrivateMemorySize
System.Diagnostics.Tests.ProcessTests.Kill_ExitedNonChildProcess_DoesNotThrow(killTree: True)
System.Diagnostics.Tests.ProcessTests.TotalProcessorTime_PerformLoop_TotalProcessorTimeValid
System.Diagnostics.Tests.ProcessTests.Kill_EntireProcessTree_True_EntireTreeTerminated
System.Diagnostics.Tests.ProcessTests.TestPeakVirtualMemorySize
System.Diagnostics.Tests.ProcessTests.ProcessNameMatchesScriptName
System.Diagnostics.Tests.ProcessTests.TestPrivateMemorySize64
System.Diagnostics.Tests.ProcessTests.LongProcessNamesAreSupported
System.Diagnostics.Tests.ProcessTests.TestPeakWorkingSet
System.Diagnostics.Tests.ProcessTests.TestPeakVirtualMemorySize64
System.Diagnostics.Tests.ProcessTests.Kill_ExitedChildProcess_DoesNotThrow(killTree: True)
System.Diagnostics.Tests.ProcessTests.Kill_EntireProcessTree_True_CalledOnTreeContainingCallingProcess_ThrowsInvalidOperationException
System.IO.Tests.DirectoryInfo_MoveTo.MoveDirectory_FailToMoveLowerCaseDirectoryWhenUpperCaseDirectoryExists
System.IO.Tests.FileInfo_Exists.LockedFileExists
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 0, firstLength: 10, secondPosition: 1, secondLength: 2)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 3, secondLength: 5)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 3, secondLength: 4)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 4, secondLength: 5)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 2, secondLength: 6)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 2, secondLength: 4)
System.IO.Tests.FileStream_LockUnlock.OverlappingRegionsFromOtherProcess_ThrowsException(fileLength: 10, firstPosition: 3, firstLength: 5, secondPosition: 4, secondLength: 6)
System.IO.Tests.Directory_Move.MoveDirectory_FailToMoveLowerCaseDirectoryWhenUpperCaseDirectoryExists
System.Net.NameResolution.Tests.GetHostEntryTest.Dns_GetHostEntry_HostString_Ok(hostName: \"\")
System.Net.NameResolution.Tests.GetHostEntryTest.Dns_GetHostEntryAsync_HostString_Ok(hostName: \"\")
System.Net.NameResolution.Tests.GetHostByNameTest.DnsObsoleteBeginEndGetHostByName_EmptyString_ReturnsHostName
System.Net.NameResolution.Tests.GetHostByNameTest.DnsObsoleteGetHostByName_EmptyString_ReturnsHostName
System.Net.NetworkInformation.Tests.PingTest.SendPingAsyncWithIPAddressAndTimeoutAndBufferAndPingOptions_Unix(addressFamily: InterNetwork)
System.Net.NetworkInformation.Tests.PingTest.SendPingWithIPAddressAndTimeoutAndBufferAndPingOptions_Unix(addressFamily: InterNetwork)
System.Net.Sockets.Tests.DualModeAcceptAsync.AcceptAsyncV4BoundToSpecificV4_Success
System.Tests.AppDomainTests.MonitoringIsEnabled
System.Tests.GCExtendedTests.GetGCMemoryInfo

@ am11はSystem.Diagnostics.Tests.ProcessTestsを調べているため、ロックテストの失敗が最大の残りのギャップのようです。 誰かがdotnet / corefx＃30899を見ていただければ素晴らしいと思います。

これに関する更新があるのか​​、それとも放棄されているのか疑問に思っていますか？

@elfalem 、最近はFreeBSD CIレッグ（Ubuntuからクロスコンパイル）がhttps://github.com/dotnet/dotnet-buildtools-prereqs-docker/のDockerイメージを使用しており、すべての前提条件がインストールされています。 同じDockerコンテナーを使用して、ランタイムパッケージ（基本的にはtar.gz）をローカルまたはリモートマシンで公開できます。 たとえば、フォークブランチの1つでGitHubアクションを設定できます。たとえば、 https ： https://github.com/am11/runtime/releases/tag/6.0.0-dev.freebsd.1でGitHubリリースにdotnet-runtime-6.0.0-dev-freebsd-x64.tar.gzアーカイブには、公開されたdotnetアプリケーション（dotnetSDKを備えた別のlinux / macシステムから）を実行するのに十分なビットがあります。 新しい12.2VM（vagrant）を作成してテストし、公開されたアプリをMacからVMに抽出してコピーしたところ、次のように機能しました。

#!/usr/bin/env tcsh

$ sudo pkg install libunwind icu libinotify

$ fetch https://github.com/am11/runtime/releases/download/6.0.0-dev.freebsd.1/dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz
$ mkdir ~/.dotnet
$ tar xzf dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz -C ~/.dotnet

$ set PATH=(~/.dotnet:$PATH)
$ setenv PATH "$PATH"

$ dotnet /vagrant/MyPublishedApp.dll
Hello World!

@Thefrankは、ある時点で適切な

これに関する更新があるのか​​、それとも放棄されているのか疑問に思っていますか？

https://github.com/dotnet/source-build/issues/1139をご覧ください。
dotNET5のファイナルを待つ間、最近は試していませんが、数か月前の時点では、FreeBSDランタイムはLinux上でクロスコンパイルとしてしか構築できませんでした。 ASPNetとSDKもLinuxクロスコンパイルを必要としましたが、スターが整列した場合にのみビルドされました（アーケードの更新またはその他の自動化されたボットが依存関係を壊さなかった）

編集：そして@ am11は、記事を投稿しました。 それを読んで、私のものではない
edit2：句読点を忘れてしまい、2日前にfinalが出されたようです。 私はそれか何かに取り組むべきだと思います

上記のすべてとは別に、私はhttps://github.com/dotnet/runtimelab/でFreeBSDプロジェクトを作成し、パッケージのビルドと公開を徐々に進めています。 目標は、アプリがFreeBSDで実行され、source-buildのシードを持つのに十分なビルドと公開を行うことです。

簡単なアップデートを書こうと思いました。 私はついにすべての惑星を調整して、FreeBSDで5.0.0RTMを構築しました。 私はPreview3以来追いついておらず、5.0を成功させるために、互換性のあるビルドの適切な組み合わせを見つけるのにしばらく（そして_多くの_ビルドの試み）かかりました。
驚くほど少ないハックでPowerShell7.1.0を構築できました。徹底的にテストしていませんが、動作しますが、SDKの優れたテストのようです。
AspNetCoreをビルドしたばかりですが、まだテストしていません。

$ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.100
 Commit:    5044b93829

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  11
 OS Platform: FreeBSD
 RID:         freebsd.11-x64
 Base Path:   /tmp/rtm/sdk/5.0.100/

Host (useful for support):
  Version: 5.0.0
  Commit:  cf258a14b7

.NET SDKs installed:
  5.0.100 [/tmp/rtm/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.0 [/tmp/rtm/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.0 [/tmp/rtm/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download
$ dotnet new console
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on /tmp/test/test.csproj...
  Determining projects to restore...
  Restored /tmp/test/test.csproj (in 106 ms).
Restore succeeded.

$ dotnet run
Hello World!
$

$ LANG=en-US ./pwsh
PowerShell 7.1.0
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS /tmp/powershell> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.1.0
PSEdition                      Core
GitCommitId                    7.1.0
OS                             FreeBSD 11.4-RELEASE FreeBSD 11.4-RELEASE #0 r362094: Fri Jun 12 18:27:15 UTC 2020     [email protected]:/usr/obj/usr/src/sys/GE…
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PS /tmp/powershell> Get-Host

Name             : ConsoleHost
Version          : 7.1.0
InstanceId       : fa711f95-926c-47e4-9e0c-dff0f518f825
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace


PS /tmp/powershell>

この作業を手動で（つまり、CIシステムの外部で）行う場合の唯一の問題は、次のビルドで使用できるように特定のビルドを使用できるようにする必要がある変更を壊すことによって引き起こされる問題です。 頻繁には発生しませんが、正しいコミットを見つけるには多くの試行錯誤が必要です。 LinuxをCIシステムにクロスビルドすることでそれを修正できるはずですが、私はまだそれを見ていません。 それでも、完全なSDKを構築してから、そのSDKを使用して別のSDKを構築できることを知っておくとよいでしょう。

russellh<strong i="5">@freebird</strong>:/www/winlua_net/htdocs/downloads$ pkg search dotnet
linux-dotnet-cli-2.0.7         Cross-platform .NET implementation
linux-dotnet-runtime-2.0.7     Cross-platform .NET implementation
linux-dotnet-sdk-2.1.201       Cross-platform .NET implementation (Software Development Kit)
linux-dotnet10-runtime-1.0.11  Cross-platform .NET implementation
linux-dotnet10-sdk-1.1.9       Cross-platform .NET implementation (Software Development Kit)
linux-dotnet11-runtime-1.1.8   Cross-platform .NET implementation

それは良い進歩です@jasonpugsley。 ビルドのより良い答えを見つけようとしていますが、ここ数か月でまともな時間を入れることができませんでした;（
PowerShellはterminfoのせいであなたに不満を与えましたか、それとも他の場所から端末定義をコピーしましたか？

sshされたMacから端末定義を取得しました。

@jasonpugsleyあなたは私よりずっと先にいます。 コアとSDKはLinuxクロスfreebsdからビルドします。 実行された限られたテストから正常に実行されます。 ランタイムもSDKクロスビルドもfreebsd自体でビルドすることはできません（linuxとfreebsdはllvm9とclang9を使用しています）。
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0
今週末にもっと時間があれば、もう少しそれを突くのは悪いですし、少なくともfreebsd用にLinux上に構築されたaspnetcoreを入手できるかどうかも確認してください

@Thefrank 、どういう意味

$ ROOTFS_ENV="ROOTFS_DIR=/crossrootfs/x64"
$ DOTNET_DOCKER_TAG="mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-18.04-cross-freebsd-11-20201109180854-f13d79e"
$ docker run -e $ROOTFS_ENV -v $(pwd):/runtime $DOTNET_DOCKER_TAG /runtime/build.sh -c Release -cross -os freebsd

失敗しているのですか、それともartifacts/packages/Release/Shipping/dotnet-runtime-5.0.0-dev-freebsd-x64.tar.gzのバイナリの実行に失敗しましたか？
Ubuntu18または20でSDK5xをクロスコンパイルしようとしている場合は、このパッチhttps://github.com/dotnet/sdk/commit/80e42f16422352f725d78be72071781d8365a238 （マスターブランチにあります）を適用することをお勧めします。

半分眠ったら投稿をやめる必要があります。
ランタイムとSDKのビルドはLinuxで完了します。
これらのバイナリはfreebsdで実行されます（dotnet --info、新しいコンソール、および実行）
これらのバイナリは、freebsdのソースからランタイムまたはSDKを作成できません

ああ、わかりました。 FreeBSDでランタイムをHostOSとして再構築するためにstage0バイナリをドッグフォッドしようとしたことはありません。

ld：エラー：/root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim。 exports：1 ：不明なディレクティブ：V1.0

この問題を個別に報告する価値があるかもしれません。 おそらくそれを修正する方法は複数ありますが、このパッチは何か違いがありますか？

--- a/eng/native/functions.cmake
+++ b/eng/native/functions.cmake
@@ -211,7 +211,7 @@ function(generate_exports_file)
   list(GET INPUT_LIST -1 outputFilename)
   list(REMOVE_AT INPUT_LIST -1)

-  if(CMAKE_SYSTEM_NAME STREQUAL Darwin)
+  if(CMAKE_SYSTEM_NAME STREQUAL Darwin OR CLR_CMAKE_HOST_FREEBSD)
     set(AWK_SCRIPT generateexportedsymbols.awk)
   else()
     set(AWK_SCRIPT generateversionscript.awk)
@@ -229,7 +229,7 @@ endfunction()

 function(generate_exports_file_prefix inputFilename outputFilename prefix)

-  if(CMAKE_SYSTEM_NAME STREQUAL Darwin)
+  if(CMAKE_SYSTEM_NAME STREQUAL Darwin OR CLR_CMAKE_HOST_FREEBSD)
     set(AWK_SCRIPT generateexportedsymbols.awk)
   else()
     set(AWK_SCRIPT generateversionscript.awk)

このパッチは何か違いがありますか

FreeBSDは、ダーウィンではなく、シンボルバージョンのスクリプトに関する限りLinuxに従うことを期待しています。 IMO問題は、generateversionscript.awkにGNU-awk固有のものがあることである可能性が高いです。

パッチはエラーを変更しました：
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: _CreateProcessForLaunch
awkバージョンの問題の場合：

awk --version
awk version 20121220 (FreeBSD)

実験が簡単な場合は、gawkパッケージをインストールして、CMakeファイルの呼び出しをgawkに変更してみてください。

パッチを元に戻しました。 gawkpkgをインストールしました。
build.shスクリプトがcmakeargsを渡す方法を理解するには怠惰すぎて、すぐには意味がないので、gawk-> awkをシンボリックリンクしました。
同じ元のエラー
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0

後期編集：Linuxのバイナリが正しくビルドされなかったようです：

# ./dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.101-servicing.20605.0
 Commit:    c3a779b104

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  12
 OS Platform: FreeBSD
 RID:         osx-x64
 Base Path:   /root/runtime/.dotnet/sdk/5.0.100/

Host (useful for support):
  Version: 5.0.1
  Commit:  2ee13ec8e5

.NET SDKs installed:
  5.0.100 [/root/runtime/.dotnet/sdk]

.NET runtimes installed:
  Microsoft.NETCore.App 5.0.1 [/root/runtime/.dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

主にRID: osx-x64がいくつかの問題を引き起こしている可能性があります

主にRID: osx-x64がいくつかの問題を引き起こしている可能性があります

そのRIDは、サポートされているプラ​​ットフォームとサポートされていないプラットフォームのいくつかの解決後にSDKによって表示されます。 基本的にアプリケーションの実行には影響しません。 ランタイムによって検出された実際のRIDは正しいです。そうでない場合、アプリケーション（ dotnet(1) ）は正しく実行されません。
c# using System; using System.Runtime.InteropServices; class Program { static void Main() => Console.WriteLine("Real RID: {0}", RuntimeInformation.RuntimeIdentifier); }
私の箱にReal RID: freebsd.12-x64を印刷します。

ldの問題を追跡するために＃45663を開きました。 私も再現できました。

ldエラーに関する@Thefrank 、これを試してください：

diff --git a/eng/native/configurecompiler.cmake b/eng/native/configurecompiler.cmake
index 006a180fa0a..2a270572532 100644
--- a/eng/native/configurecompiler.cmake
+++ b/eng/native/configurecompiler.cmake
@@ -594,7 +594,7 @@ else (CLR_CMAKE_HOST_WIN32)
         ERROR_QUIET
         OUTPUT_VARIABLE ldVersionOutput)

-    if("${ldVersionOutput}" MATCHES "GNU ld" OR "${ldVersionOutput}" MATCHES "GNU gold")
+    if("${ldVersionOutput}" MATCHES "GNU ld" OR "${ldVersionOutput}" MATCHES "GNU gold" OR "${ldVersionOutput}" MATCHES "LLD")
         set(LD_GNU 1)
     elseif("${ldVersionOutput}" MATCHES "Solaris Link")
         set(LD_SOLARIS 1)

これは、アクティブになりますelseで句をeng/native/functions.cmakeここに：

function(set_exports_linker_option exports_filename)
    if(LD_GNU OR LD_SOLARIS)
        # Add linker exports file option
        if(LD_SOLARIS)
            set(EXPORTS_LINKER_OPTION -Wl,-M,${exports_filename} PARENT_SCOPE)
        else()
            set(EXPORTS_LINKER_OPTION -Wl,--version-script=${exports_filename} PARENT_SCOPE)
        endif()
    elseif(LD_OSX)
        # Add linker exports file option
        set(EXPORTS_LINKER_OPTION -Wl,-exported_symbols_list,${exports_filename} PARENT_SCOPE)
    endif()
endfunction()

正直なところ、私はリンカーの専門家ではないので、これが機能している間、FreeBSDのclangに実際に必要なもの/標準的なものを詳しく調べませんでした。

ああ、リンカーのユーザーエージェントの問題が再び発生します。 LLDのバージョン文字列には、configureテストのGNU ldパスをたどろうとして、 (compatible with GNU linkers)れていますが、この場合は明らかに十分ではありません:)

LD_GNUフラグの名前が多少間違っていても、LLDでのマッチングはここでは適切に見えます。

はい、もっと作業が必要です。 フラグ名がわかりにくくなっています。 誰もこれをそのままコミットしようとしないでください。

投稿者：エド・ザ・マスター[email protected]
送信：2020年12月7日月曜日10:26:48 AM
宛先： dotnet / runtime
Cc：Jason Pugsley [email protected] ; 言及@ noreply.github.com
件名：Re：[dotnet / runtime] FreeBSDのサポート（＃14537）

ああ、リンカーのユーザーエージェントの問題が再び発生します。 LLDのバージョン文字列には、configureテストのGNU ldパスをたどろうとして（GNUリンカーと互換性があります）含まれていますが、この場合は明らかに十分に賢くありません:)

ここでは、LD_GNUフラグの名前が多少間違っていても、LLDでのマッチングは適切に見えます。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/dotnet/runtime/issues/14537#issuecomment-739583816で表示するか、 https：//github.com/notifications/unsubscribe-auth/AECFDEXKTDFRAX4ZEE6VXZTSTQHLRANCNFSM4TS3XPPAの登録を解除して

https://github.com/dotnet/runtime/pull/45664を使用することを選択しました
ClrはClr.Toolsサブセットまで構築され、その後失敗します。

/root/runtime/.dotnet/sdk/5.0.100/Microsoft.Common.CurrentVersion.targets(4818,5): error MSB3030: Could not copy the file "/root/runtime/artifacts/bin/coreclr/FreeBSD.x64.Release/libjitinterface" because it was not found. [/root/runtime/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj]
/root/runtime/.dotnet/sdk/5.0.100/Microsoft.Common.CurrentVersion.targets(4818,5): error MSB3030: Could not copy the file "/root/runtime/artifacts/bin/coreclr/FreeBSD.x64.Release/libclrjit" because it was not found. [/root/runtime/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj]

サブセット「mono」とサブセット「libs」はエラーなしで完了します

@Thefrankこのdiffの2番目の部分で、この問題を修正する必要があります。

diff --git a/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj b/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj
index 2de5f568214..87242a728f0 100644
--- a/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj
+++ b/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj
@@ -12,7 +12,7 @@
     <OutputPath>$(BinDir)/crossgen2</OutputPath>
     <GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>
     <EnableDefaultEmbeddedResourceItems>false</EnableDefaultEmbeddedResourceItems>
-    <RuntimeIdentifiers>linux-x64;linux-musl-x64;win-x64</RuntimeIdentifiers>
+    <RuntimeIdentifiers>linux-x64;linux-musl-x64;win-x64;freebsd-x64</RuntimeIdentifiers>
     <Configurations>Debug;Release;Checked</Configurations>
   </PropertyGroup>

@@ -53,6 +53,7 @@
     <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('WINDOWS'))">.dll</LibraryNameExtension>
     <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('LINUX'))">.so</LibraryNameExtension>
     <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('OSX'))">.dylib</LibraryNameExtension>
+    <LibraryNameExtension Condition="$([MSBuild]::IsOsPlatform('FREEBSD'))">.so</LibraryNameExtension>

     <JitInterfaceLibraryName>$(LibraryNamePrefix)jitinterface$(LibraryNameExtension)</JitInterfaceLibraryName>
   </PropertyGroup>

条件のORとしてLINUX行に追加した方がよい場合があります。

トリックをした@jasonpugsley ！
/root/runtime/src/coreclr/src/tools/aot/crossgen2/crossgen2.csproj : error NU1101: Unable to find package Microsoft.AspNetCore.App.Runtime.freebsd-x64. No packages exist with this id in source(s):
数日前に何かをするのを忘れていたのはわかっていました！ これは面白いはずです

編集：クロスジェンなし（別名、後半）

./build.sh -c Release -bl:buildlog.binlog

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:12:05.56

この投稿の最後の編集を編集することを誓います：
テストには時間がかかることがあり、長時間実行されるテストとは言われていますが、これは1つのテストでは手に負えません。
System.Net.HttpListener.Tests: [Long Running Test] 'System.Net.Tests.HttpListenerResponseTests.AddLongHeader_DoesNotThrow', Elapsed: 00:36:20

2時間待った後にテストを強制終了しました他のテストはまだ失敗していました

/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'Microsoft.Extensions.Hosting.Unit.Tests'. Please check /root/runtime/artifacts/bin/Microsoft.Extensions.Hosting.Unit.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/Microsoft.Extensions.Hosting/tests/UnitTests/Microsoft.Extensions.Hosting.Unit.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.NameResolution.Functional.Tests'. Please check /root/runtime/artifacts/bin/System.Net.NameResolution.Functional.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.NameResolution/tests/FunctionalTests/System.Net.NameResolution.Functional.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.NetworkInformation.Functional.Tests'. Please check /root/runtime/artifacts/bin/System.Net.NetworkInformation.Functional.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.NetworkInformation/tests/FunctionalTests/System.Net.NetworkInformation.Functional.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'Microsoft.VisualBasic.Core.Tests'. Please check /root/runtime/artifacts/bin/Microsoft.VisualBasic.Core.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/Microsoft.VisualBasic.Core/tests/Microsoft.VisualBasic.Core.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Console.Tests'. Please check /root/runtime/artifacts/bin/System.Console.Tests/net5.0-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Console/tests/System.Console.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Runtime.Extensions.Tests'. Please check /root/runtime/artifacts/bin/System.Runtime.Extensions.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Runtime.Extensions/tests/System.Runtime.Extensions.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Sockets.Tests'. Please check /root/runtime/artifacts/bin/System.Net.Sockets.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.Sockets/tests/FunctionalTests/System.Net.Sockets.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.IO.FileSystem.Tests'. Please check /root/runtime/artifacts/bin/System.IO.FileSystem.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.IO.FileSystem/tests/System.IO.FileSystem.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Ping.Functional.Tests'. Please check /root/runtime/artifacts/bin/System.Net.Ping.Functional.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.Ping/tests/FunctionalTests/System.Net.Ping.Functional.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Requests.Tests'. [/root/runtime/src/libraries/System.Net.Requests/tests/System.Net.Requests.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.WebSockets.Client.Tests'. [/root/runtime/src/libraries/System.Net.WebSockets.Client/tests/System.Net.WebSockets.Client.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Security.Cryptography.X509Certificates.Tests'. Please check /root/runtime/artifacts/bin/System.Security.Cryptography.X509Certificates.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Security.Cryptography.X509Certificates/tests/System.Security.Cryptography.X509Certificates.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.WebClient.Tests'. [/root/runtime/src/libraries/System.Net.WebClient/tests/System.Net.WebClient.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.Security.Tests'. Please check /root/runtime/artifacts/bin/System.Net.Security.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Net.Security/tests/FunctionalTests/System.Net.Security.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Diagnostics.Process.Tests'. Please check /root/runtime/artifacts/bin/System.Diagnostics.Process.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Diagnostics.Process/tests/System.Diagnostics.Process.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Security.Cryptography.Xml.Tests'. [/root/runtime/src/libraries/System.Security.Cryptography.Xml/tests/System.Security.Cryptography.Xml.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Runtime.Tests'. Please check /root/runtime/artifacts/bin/System.Runtime.Tests/net5.0-Unix-Release/testResults.xml for details! [/root/runtime/src/libraries/System.Runtime/tests/System.Runtime.Tests.csproj]
/root/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Net.HttpListener.Tests'. [/root/runtime/src/libraries/System.Net.HttpListener/tests/System.Net.HttpListener.Tests.csproj]
    0 Warning(s)
    18 Error(s)

Time Elapsed 02:11:29.07
Build failed (exit code '1').