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 的问题。

portteam 已就 dotnet/runtime#14536 达成一致，除非 MSFT 选择否则它将是 FreeBSD

如果我没看错，这意味着当https://github.com/dotnet/corefx/pull/1999合并时，我们可以考虑 MSFT 批准新的公共 API，因此可以继续推进剩余的问题无需 MSFT 批准的常规拉取请求。

如果是这样，那对我来说听起来不错。

根据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 移植团队合作，将 CoreFX 测试添加到我们在 FreeBSD 上运行的 CI 系统中。
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，我个人认为这不是第一个障碍。 有两个与构建相关的问题：

1. 构建在 FreeBSD 上正常工作的程序集
2. 在 FreeBSD 上构建这些程序集

(1) 很关键，我相信这个问题的意思是什么。 (2) 非常好，但缺少它并不妨碍创建一个伟大的系统来在 FreeBSD 上运行托管代码。

您当然可以根据自己的喜好自由确定优先级，但我的建议是关注 (1) 而不是 (2)。

请注意，我们在 Linux 上构建 corefx 并在 OSX 上构建它仍然存在问题，因此我们的 CI 系统在 Windows 上为这些平台构建程序集； 然后它将生成的组件传送到目标平台以执行测试。

这很公平。 我只是假设如果我们可以在 FreeBSD 上自己构建它，那么将通用的 FreeBSD 平台支持融入 corefx 会更容易。

我将暂时使用 Windows 启动的构建，并尝试将构建配置结合在一起。

@josteink顺便说一句。 corefx 现在应该建立在 Mono 4.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，我个人认为这不是第一个障碍。 有两个与构建相关的问题：

构建在 FreeBSD 上正常工作的程序集
在 FreeBSD 上构建这些程序集
(1) 很关键，我相信这个问题的意思是什么。 (2) 非常好，但缺少它并不妨碍创建一个伟大的系统来在 FreeBSD 上运行托管代码。

您当然可以根据自己的喜好自由确定优先级，但我的建议是关注 (1) 而不是 (2)。

请注意，我们几乎没有在 Linux 上构建和在 OSX 上构建的 corefx，因此我们的 CI 系统在 Windows 上为这些平台构建程序集； 然后它将生成的组件传送到目标平台以执行测试。

—
直接回复此邮件或在 GitHub 上查看。

是的，我绝不反对……能够在 Linux、OSX 和 FreeBSD 上 _build_ corefx 很重要。 我只是建议，从优先级的角度来看，能够在 Linux、OSX 和 FreeBSD 上实际 _run_corefx 更为重要。 :wink: 如果两者可以同时进行，那就更好了。

@古特利，
将是超级：酷：如果我们有一个降价任务清单，概述剩余的内容：

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

呈现为：

• [ ] 任务1
• [ ] 任务 2
• [ ] 任务 3

这可能会鼓励其他人获得这些成就，而且 FreeBSD 支持将比预期更快地落地！ ：太阳镜：

据我所知，FreeBSD 支持需要 CoreFX 中的以下工作：

• [x] 将 FreeBSD 平台引入构建工具和脚本。 （由@josteink和我完成，PRs 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 没有inotify ，如 Linux 和 Windows 那样（这也是我上次检查时没有 Dropbox 的原因）。 这会成为我们遇到的麻烦的潜在来源吗？ 或者有人知道如何解决这个问题吗？

我建议我们暂时将其存根并抛出 PlatformNotSupportedException，正如 Stephen Toub 在另一个主题 (https://github.com/dotnet/corefx/pull/2021#issuecomment-111602342) 中建议的那样。 然后我们至少有一套完整的程序集，我们可以继续处理那个特定问题，而不会阻止进一步的步骤。

你介意为此开一个单独的问题吗？

让我们将System.IO.FileSystem.Watcher讨论移至 dotnet/corefx#2046

伙计们， System.Diagnostics.Process有没有这样的拦截器？

@jasonwilliams200OK 今早将 FreeBSD 添加到 S.RT.I.RI 并合并，但CheckPlatformTests内的 FreeBSD 测试必须退出，直到dotnet/buildtools更新。

• [ ] 更新构建工具以支持 FreeBSD - https://github.com/dotnet/buildtools/pull/180
• [ ] 将[Fact,PlatformSpecific(PlatformID.FreeBSD)]测试重新应用到 CheckPlatformTests - 参见https://github.com/dotnet/corefx/pull/2068#discussion_r32570244和https://github.com/dotnet/corefx/pull/2068#discussion_r32570244
• [ ] 将public static OSPlatform FreeBSD到https://github.com/dotnet/corefx/pull/2068

@jasonwilliams200OK 昨晚有一些关于System.Diagnostics.Process讨论，这些讨论已经正式化为https://github.com/dotnet/corefx/issues/2070

@ghuntley ，谢谢。 我实际上阅读了这些消息。 System.Diagnostics.Process是一个棘手的问题。 AFAIK，io.js 团队在 FreeBSD 进程管理方面遇到了类似的挑战。 Mono 团队可能已经解决了它，所以如果@akoeplinger和 co. 能给我们启发吗？ :)

System.IO.FileSystem.DriveInfo

正如 gitter 中所讨论的，对于这个，我尝试研究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
$

所以它似乎做了我们需要的。 问题是，我们应该对结果进行任何类型的过滤吗？

看看DriveInfo对象的“意图”，它来自 .NET 的 Windows 世界，通常是枚举可用的位置来存储或检索文件（ 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合作提出适用于不同 Unices 的解决方案。

我有一个在 OSX 上运行的版本，它使用 getmntinfo 和 statfs 来获取有关每个挂载点的信息，这似乎是 Windows 驱动器概念中最合乎逻辑的映射。 我将仔细检查 OSX 上的函数和结构定义是否与 FreeBSD 定义匹配，如果是，我对 OSX 的提交也将适用于 BSD。

我一定会把你加到我的公关@josteink

听起来不错。 感谢您的提醒，也感谢您对 FreeBSD 的喜爱。

我研究了这些函数的一些基本 pinvoke，似乎我们需要自己完成所有的编组和转换，所以如果其他人已经付出了努力，我还能拒绝谁？ ;)

没问题...看起来主要区别在于结构声明； 由于我们将来可能会更多地使用此功能，因此我正在进行一些重构，这将使我们能够共享大量 PInvoke 签名。 我将在我的 PR 中添加一个更大的描述（今天或明天，基于测试运行的方式），但我基本上为 FreeBSD 添加了 PInvoke 签名和结构签名（基于我在网上找到的头文件）并编译。 我已经在 Mac 上对其进行了测试，因此它_应该_（理论上...）在 FreeBSD 上工作，因为它只是结构声明更改，但您的里程可能会有所不同:)。 如果没有，您将拥有 DriveInfo 类和 PInvokes 99% 的方式，并且只需要基于 FreeBSD 的细微差别进行一些调整。

好消息@sokket。 我已经在端口团队用于开发的机器上为您创建了一个帐户，它是基于欧洲的，但它始终处于打开状态，并具有大量内存和处理能力。 希望这会在使用 FreeBSD 时帮助并消除一些摩擦。

# ssh [email protected]

密码验证已禁用，请使用您的其中一个密钥。

@josteink另见问题： https :

有更新吗？ 有人在 FreeBSD 上实现了剩余的程序集吗？

我一直忙于照顾我的新宝宝，没有时间在任何地方进行任何编码。

我怀疑这些问题一直处于休眠状态，我想这在一定程度上证实了这一点。

对于仍未实现的程序集，我在上面的列表中链接了“如何实现”问题。 我希望这有助于协调实现这些剩余程序集的工作。

我必须承认我很难跟踪我们做了什么以及在哪里完成，所以这绝对是一个很好的举措。 做得好 ：）

我在哪里找到那个？ 很高兴获得剩余的程序集
实施的。

在 25/07/15 22:10，Jan Henke 写道：

对于尚未实现的程序集，我链接了“如何
实施” - 上面列表中的问题。我希望有助于协调
实现这些剩余程序集的努力。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/dotnet/corefx/issues/1626#issuecomment -124838781。

这个评论在这里： https :

我现在正在等待本机 shim 完成，因为它们应该接管让这些程序集在 FreeBSD 上运行的大部分工作。

@nguerrera如果您可以让我们了解进展情况，那就太好了。 :)

更新：
@janhenke证实，与https://github.com/dotnet/corefx/pull/2974合并后， System.IO.Pipes建立在 FreeBSD 上！ ：太阳镜：

更新：
dotnet/corefx#2527 已关闭， System.IO.MemoryMappedFiles构建在 FreeBSD 上。
感谢@janhenke的确认！

多亏了 shims 方法，它只是确保 shims 在 FreeBSD 上编译。 值得庆幸的是，这让生活变得更加轻松。 :)

dotnet/corefx#3257 应该给我们带来System.Diagnostic.Process和System.IO.FileSystem.Watcher只留下System.Net.NameResolution未解决。 （一旦 PR 合并并在 FreeBSD 上工作，我将检查提到的两个程序集）

dotnet/corefx#3471 应该给我们带来System.Net.NameResolution并完成上面的列表。

dotnet/corefx#3471 刚刚合并 :)

@sokket ，感谢您的更新。 我使用本指南在 FreeBSD 上构建了 master (f467911)：https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24。 当前阻止程序是 https://github.com/dotnet/buildtools/issues/292，已在上游修复，但等待下一次构建工具推出。 :)

更新：修复了 dotnet/buildtools#292 的新 buildtools 已登陆 CoreFX master。 buildtools 的下一个障碍是https://github.com/dotnet/buildtools/issues/300 ：缺少能够运行测试的特定于操作系统的工具。

@janhenke ，您已将System.Diagnostics.Process (#2070) 和System.IO.FileSystem.Watcher (#2046) 标记为完成； 但它们既没有实现，也没有在 FreeBSD 上编译。 您是否通过编译托管代码来验证列表？

根据我最近提交 60c78da3c918b0d256cc1f878de06d351dbe3342（参见msbuild.log ）的经验，以下程序集无法编译：

• 系统.诊断.过程
• System.Diagnostics.ProcessManager
• System.Diagnostics.ThreadInfo
• System.IO.FileSystemWatcher
• System.Net.SocketAddress_（好吧，这个是最近加的）_

据我回忆，我验证了相关的垫片编译。 由于托管代码应该没有 FreeBSD 特定代码。 你提到的那些垫片应该已经用上面链接的 PR 来消除了。
但我也在两者之间运行了完整的编译。 至少System.Diagnostics.ThreadInfo和System.IO.FileSystemWatcher确实编译了。 所以一定有什么东西倒退了。

你提到的那些垫片应该已经用上面链接的 PR 来消除了。

实际上，PR https://github.com/dotnet/corefx/pull/3257与 shim 无关。 托管项目中仍然有一些 PAL 代码（旧方法），因此需要构建托管程序集才能绝对确定。

实际上，PR dotnet/corefx#3257 与 shim 无关。

我不同意。 它正在将 P/Invoke 代码重构为 System.Native shim。 同样正如我在上面编辑的那样，我至少回忆了一些在两者之间编译的程序集。

我不同意

https://github.com/dotnet/corefx/pull/3257/files ：查看.Unix.cs和.Linux.cs的实例System.Diagnostics. 。 请注意， .OSX.cs未受影响。

它将 P/Invoke 代码重构为 System.Native shim

是的，它确实重构了System.Native下的一些常见助手，但不是System.Diagnostics.*等。

即使这些程序集只是 P/Invoking 到 System.* 库，它们中的一些可能仍然需要 FreeBSD 工作，例如 System.Diagnostics.Process 和 System.IO.FileSystem.Watcher。 他们正在使用特定于 Linux 和 OS X 的功能，我们不打算尝试将其抽象为原生垫片。 shims 的目标不是最终​​为 Unix 提供一个单一的托管二进制文件，尽管当它来自工作时这是一个非常好的属性； 主要目标是避免导致脆弱性的 ABI 差异。 我预计至少有少数程序集将继续具有 Linux/OS X 特定的二进制文件，其中还需要 FreeBSD 二进制文件。

仅供参考，没有名为 System.Diagnostics.ProcessManager 的 corefx 程序集，
System.Diagnostics.ThreadInfo,
System.IO.FileSystemWatcher，或
System.Net.SocketAddress。 这些是其他程序集中的类型。

我预计至少有少数程序集将继续具有 Linux/OS X 特定的二进制文件，其中还需要 FreeBSD 二进制文件。

这是否意味着每当面向 Linux 的 Solaris 和非 glibc（musl 和 μlibc）（例如 Alpine 支持）到来时，它们都会有单独的二进制文件？ 那么不同的架构 ARM、MIPS、RISC、SPARC 等是否需要另一个级别的分离？

将它们尽可能地融合到 POSIX 接口/系统调用并使用配置（通过 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 接口/系统调用是否有意义

我们的确是。 您如何建议通过 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 有效，那么现有解决方案也有效，如果无效，则您需要为该平台编写新解决方案。 因此，我们尝试在托管代码中做尽可能多的事情，仅将本机用于 1:1 垫片，使托管代码在目标 API 可移植的情况下更具可移植性。 我们在本机代码中使用 #ifdefs 来掩盖小细节，其中哪个平台上的这个 API 与另一个平台上的那个 API 足够接近，但这并没有扩展到完全不同的整个解决方案； 那时抽象成为托管 API，我们为每个系统执行不同的托管实现。

如果 FreeBSD 像 Linux 一样公开 inotify 或者它像 OS X 那样公开 EventStream，那么当这些 OS API 位于 shim 之后时，可以很容易地使 shim 与 FreeBSD 一起工作，并且可以在 FreeBSD 上使用相同的托管二进制文件。 如果 FreeBSD 没有公开这样的 API，那么您将需要编写 System.IO.FileSystem.Watcher 的自定义实现，其中包含一些 FreeBSD 上可用的文件监视解决方案。 System.Diagnostics.Process 的类似评论。 文件监视的代码是否在 shim 中对此影响不大。

计划是将所有此类本机 API 最终移到 shim 后面。 但是它们远不是优先事项，因为它们不是很便携，所以你已经看到我们从 libc 的 API 开始，这些 API 是（或应该是）在任何地方公开的。

您如何建议通过 POSIX 很好地查看文件？

我们不能在 POSIX 上完成所有这些，因为 inotify 是特定于 Linux 的。 FreeBSD/OSX 提供了一个单独的实现。

提议：

从本机二进制文件分发的角度来看，每个操作系统都应该接收相同名称但功能不同的二进制文件集。

这是一个建议的结构：

# 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_compliants" 是从共享 Unix 托管二进制文件中的逻辑消耗的本机垫片 1:1 函数
• “slightly_diverged_function”是本机填充的几乎 1:1 的函数，其中一些本机 #ifdefs 从共享的 Unix 托管二进制文件中的逻辑消耗
• “painfully_diverged_watch_function”是/将是本地填充的 1:1 函数，这些函数从特定于平台的托管二进制文件中的逻辑消耗

真正的区别在于实现“痛苦发散”逻辑的代码是用C#还是C++完成的，我们选择了C#，而且已经全部用C#实现了。 我没有看到任何令人信服的论据来说明为什么在这种情况下将其全部改写为 C++ 会是一个明显更具说服力的选择。

@jasonwilliams200OK随着今天对单声道的更新，我再次在 FreeBSD 上构建了 corefx。 自从我上次构建它以来，有很多新的错误消息。
我想知道Interop.Libc最终会不会消失？

@stephentoub这一切都归结为包装。 在本机部分拥有所有平台特定代码的好处是为所有类 Unix 平台拥有一个托管程序集。
此外，我强烈认为我们需要对这些“依赖于平台的托管代码进行通用实现。即使它只是抛出一个 NotImplementedExcpetion。这样你就可以更容易地移植到新平台，如果它至少可以立即编译所有内容。它也会给至少有机会尝试在不受支持的平台上运行。
通常，如果您至少可以立即成功编译，则要容易得多。

@stephentoub ，抱歉我将 C++ 与 C# 混合在一起。 现在我明白本机层只是暴露这些入口点（本机库函数或系统调用）并且清理 IO 和托管代码是我们决定使用哪个平台特定的包装实用程序方法/包装系统调用的地方。 此外，在使用非 POSIX 功能的情况下，（本机和托管）层都不能与操作系统无关。

@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 要点链接。

此外，我强烈认为我们需要为这些“依赖于平台的托管代码”的通用实现。

我同意。 代替部分类，我们可能可以在抽象基类中使用具有公共和大多数公共虚拟方法的继承，并在必要时覆盖“大多数公共/部分不同”。 然后实现每个操作系统完全不同的抽象方法。 使用这种方法 IMO，如果专业化/泛化正在失去 DRY'ing，我们可以雇用多度继承祖先。 但是上次我检查时，在 CoreFX 中，部分类比父子关联更受欢迎（出于某种原因，我不记得了）。 :)

这是提交 2d36889 的 msbuild.log：

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

/cc： @akoeplinger

@jasonwilliams200OK为什么这么复杂。 它所需要的只是项目文件中的“如果不是 Windows、Linux、OS X”条件。 因此，要么在构建中包含一组特定于平台的文件，要么包含通用文件。

我不认为某些程序集不能为 FreeBSD 构建/工作的事实应该成为测试其余程序集的主要障碍。 我们可能应该这样做，以便在 FreeBSD 上的构建和测试运行中跳过那些有待处理的工作（FileSystemWatcher、Process、Networking）。 然后我们可以单独提出这些，同时有一个过程来防止已经有效的回归。

我不认为某些程序集无法为 FreeBSD 构建/工作的事实应该成为测试其余程序集的主要障碍

同意

我们可能应该这样做，以便在 FreeBSD 上的构建和测试运行中跳过那些有待处理的工作（FileSystemWatcher、Process、Networking）

或者类似于@janhenke 的建议，只允许他们构建，或者通过使用抛出 PlatformNotSupported 的文件进行存根，或者只是通过将 FreeBSD 映射到有效的情况之一，例如，如果选择了 FreeBSD，只需构建 Linux（它不会工作，但它会建立）。

通过@ellismg最近的更改（#3684），我可以通过简化以前的方法（https://github.com/dotnet/coreclr/issues/1633#issuecomment-143669303）来运行测试：

• 在https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 （特别是单独构建原生垫片的步骤 _after_ build.sh 以状态 1 退出）之后，下载CoreCLR artifacts 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 构建/工作的事实应该成为测试其余程序集的主要障碍。

我必须同意这一点。 最好开始对我们所做的工作进行 QAing，而不是等待一切完成后再开始测试。

它说：40 个测试失败

40出多少？ 我们在哪个球场？ :)

40出多少？ 我们在哪个球场？ :)

也打我。 测试从测试程序集（托管 dll）中产生，并且测试总数不可见。

脚本最后生成的数字是失败的测试程序集的数量。 xUnit 应该将每个程序集失败的测试数量写入标准输出作为其运行的一部分。 这些数字也应该在它在每个测试程序集文件夹中生成的 XML 文件中。

可能是运行时也只是崩溃了，在这种情况下，每个测试程序集可能不会生成日志。

@jasonwilliams200OK你知道在程序集签署问题上是否取得了任何进展吗？ 我在 Ubuntu 上遇到了同样的事情。 如果没有人在研究它，也许我们应该为它打开一个单独的问题。

@naamunds已在 CoreFX master 上修复，作为https://github.com/dotnet/corefx/issues/3739 的一部分

更新 - 今天我在 FreeBSD 上进行了测试，其中数千次通过测试，然后由于明显缺乏 System.Diagnostics.Process 和朋友们的混乱而失败。 成功执行约 40 分钟后，它挂在 System.IO.FileSystem 测试上（在我按 Ctrl+C 终止前约 15 分钟）。

@jasonwilliams200OK你是怎么在freebsd下编译corefx的？ 我被关于 gssapi 的错误困住了

@sec ，在做这些笔记时： https ://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24，CoreFX 不需要 GSSAPI。 然而，似乎 pkg 最近被移植到 FreeBSD： http : pkg upgrade pkg && pkg update && pkg install p5-GSSAPI 。

@jasonwilliams200OK ，我已经得到了这个（它是 perl ext。顺便说一句。）问题是缺少 gssapi_ext.h。 诀窍是做“pkg install krb5”——现在本地编译。
我已将它们复制到 coreclr 运行时，但仍然无法运行 ASP.NET Core 应用程序 :) 战斗还在继续。

此任务的当前状态是什么？ @janhenke的列表是否完整准确？ 所有需要完成的工作都完成了吗？ 那应该关了吧？

如果是这样，为什么我们还有这个任务？ https://github.com/dotnet/corefx/issues/2070

如果还有工作要做，是否应该根据当前的情况注册一个新问题？

我认为这也需要 - dotnet/corefx#2046

是否应该根据当前的情况注册新的问题？

是的：+1：

我们与@RussellHaley （来自 FreeBSD 社区）和@wfurt （来自 .NET Core 团队）讨论了 FreeBSD 的社区驱动端口，他们都对这项工作表示了兴趣。
这是我们汇总的计划提案（欢迎反馈/建议）：

1. 在针对 FreeBSD 的 CoreCLR 和 CoreFX 存储库中生成二进制文件 - 使用 hacks 很好
   
   
   
   • 难以并行化， @wfurt将致力于此
   
   
   • 构建可以是针对 FreeBSD 的其他平台（Mac、Linux）的构建的混合
   
   
   • 我们将需要记录的步骤（在 FreeBSD wiki 上）以使用 FreeBSD 特定的错误修复来重现构建
   
   
2. 运行和稳定 CoreCLR 测试（使用 corerun）
   
   
   
   • 测试可以建立在另一个平台上
   
   
   • 目标：提供运行时的基本质量
   
   
3. 运行和稳定 CoreFX 测试（使用 corerun）
   
   
   
   • 测试可以建立在另一个平台上
   
   
   • 请注意，这需要 xunit。 我们相信，根据我们过去的移植经验，一旦 [2] 完成，xunit 就会正常工作。
   
   
   • 这在理论上可以与 [2] 并行化 - 它可能需要 xunit 的快捷方式（例如在另一个平台上生成静态执行配方）
   
   
4. 在 FreeBSD 上构建全栈（使用 corerun 作为 [1]-[3] 中的引导程序）
   
   
   
   • 我们将需要所有工具（nuget、msbuild、roslyn）来处理 boostrapping .NET Core
   
   
5. 安装程序（FreeBSD 端口）
   
   
   
   • 第一阶段：使用来自 nuget 提要的产品二进制文件
   
   
   • 第二阶段：从源代码构建产品（阻止从源代码构建）
   
   
   • 需要 FreeBSD 社区的专业知识和设计指导
   
   
   • 注意：我们也可以从官方 .NET Core 下载页面链接 FreeBSD 包作为社区支持包
   
   
6. 在 FreeBSD 上定期构建和测试运行
   
   
   
   • 目标：确保尽早了解破坏 FreeBSD 的 .NET Core 存储库中的更改
   
   
   • 需要设计
   
   
   • 需要 FreeBSD 社区的专业知识和设计指导
   
   

操作原则：

• [2]-[4] 中的更改应主要在 CoreCLR/CoreFX 存储库中完成（由于 CLA 签名要求、.NET Core 团队专家/成员的代码审查等）
• 我们将跟踪有关此问题的高级别的工作。 特定的错误将作为单独的问题提交。

如果有人有兴趣提供帮助，请在这里告诉我们。 一旦我们与 [1] 的距离足够远，我们就可以轻松地从上面的 [2] 和 [3] 分发工作项。

该提案的最新版本位于本期的置顶帖。

标记更多对 freebsd-mono 列表（此线程）表示兴趣的人： @smortex @radovanovic @Echo-8-ERA

顺便说一句：我找不到Mathieu Prevot GitHub 帐户 - [更新] 发现于https://github.com/dotnet/corefx/issues/1626#issuecomment -330348424：@mprevo

对于 NetBSD，我们缺少强大的 posix 互斥锁，这是生成命名的 robus 互斥锁仍然缺少的唯一功能。 我们现在可以使用 LLDB/NetBSD 调试托管代码故障。它适用于核心文件。 在我之前的尝试中，我们因 LLDB 中缺少此功能而失败（我开始将此调试器移植到 .NET）。

拥有更好的 FreeBSD 支持将有很大帮助。

过去也存在缺乏 hyperv 来宾支持将 NetBSD 构建机器人附加到 CI 机器并验证补丁的问题……为此，我可能需要 MS 的帮助。 我希望有必要的专有软件来运行它，而我不拥有这些软件……如果 NetBSD 基金会和 Microsoft 之间有共同利益（投资），我可能会找到一个开发人员来完成这项工作。

我们在哪里错过了“强大的 posix 互斥锁”？ 它是 .NET Core PAL 的一部分吗？

你指的是哪个CI系统？ 为什么它与 .NET Core 端口工作相关联？

我们在哪里错过了“强大的 posix 互斥锁”？

在 NetBSD 内核（和 libc/libpthread）中，这是 CoreCLR 的一部分。 FreeBSD 在过去两年中开发了它。 它可能在最新的稳定版本中可用......但需要检查。

我想在重新启动 .NET 移植之前添加此功能。 （还检测到一个用于网络路由的微小缺失 API ......但我现在跳过它）。

它是 .NET Core PAL 的一部分吗？

我现在不记得了，不检查代码 - 它是用于实现 .NET 的 API，名为强大的互斥锁（或者可能是信号量）。

你指的是哪个CI系统？

NetBSD。

为什么它与 .NET Core 端口工作相关联？

这是我上次看的可选功能。 我决定在内核接口和实用程序（如 LLDB）上获得功能奇偶校验。 只是我的工作风格，获得功能性积木，然后建造房屋。 总有一天我们会需要它，所以为什么不一次性开发它。 感谢您的理解 ：）

也许您可以在 GH 上标记 freebsd-dotnet 组？ 他是那里的会员（或者您可以查找他的帐户名称）。 他的电子邮件是[email protected]

[编辑] 删除@karelz 收到的电子邮件和之前的回复

如果您认为合适， @RussellHaley 可以随意标记更大的群体。 我无法通过他的姓名或电子邮件找到 Mathieu 的 GH 帐户，这就是我上面的意思（顺便说一句：我直接通过电子邮件向他发送了邮件）。

我会看看标记组。

这是马修的帐户。 也许是隐私设置？

https://github.com/mprevot

干杯，

拉斯

2017 年 9 月 18 日星期一下午 1:01，Karel Zikmund通知@github.com
写道：

@RussellHaley https://github.com/russellhaley随时标记
如果您认为合适，则更大的团体。 我找不到 Mathieu 的 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 我们不希望在一个问题上有无数的随机讨论，所以我们可能会将一些特定的设计讨论从这个问题中分离出来，如果它们超过合理的回复数量。

我终于能够在 FreeBSD 11.0 上运行 corefx 测试（没有外循环测试）
通过总数：144208
失败总数：2622
总跳过 207

我将使用说明更新https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD 。 我将提交特定问题并使用 os-freebsd 和 up-for-grab 标记它们。
正式的战斗可以开始了。 需要志愿者。

是的，我确实跳过了建议的第二步。 我也会回到它。

通过一些正在进行的更改，当前的统计数据如下所示：
通过总数：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 支持 in-tree 时添加 NetBSD 应该很简单。

@wfurt请分享电子邮件地址，我会删除几行。

最初的支持已合并到 master 分支。 构建应该按照 WIKI 页面上的描述工作。
我在 dotnet/corefx#24386 上进展缓慢，但这不会阻碍大多数用户。

我们可以在 FreeBSD 上引导 .NET 吗？

我已经有一段时间没有尝试了@krytarowski有人推动将工具更新到 2.0 版本，我正在等待努力稳定下来。 我会再试一次，我会发布更新。

嗨，所以我陷入了 clr 托管测试未运行的困境。 https://pastebin.com/B5KhtKX5

任何输入都会很棒，因为这已经有一段时间了。 我最近也遇到了在 Windows 上构建 corefx 的构建失败（master，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 :

如果您有修复损坏构建的补丁，我建议将其作为拉取请求发送，以便为每个人修复它:)

谢谢你我会的。 我仍在努力让测试运行，但我不确定是什么导致了昨晚的后续错误。

我想 Freebsd 11“pkg install”支持 netcore 2.1（一旦发布）不会发生，对吧？

TLDR； 很多工作已经完成，但需要有人开车回家。 编写端口 Makefile 是容易的部分。

@wfurt能够使用 Linux 构建 CLR 和 FX，但它在很大程度上未经测试。 我能够在 FreeBSD 上构建“本机”部分，但无法在 Windows 上构建托管部分（对于 FreeBSD）。 整个事情就是在操作系统之间传输文件一团糟。

另外，在[email protected]邮件列表中， @ dragonsa 使用 Linux 仿真从 MintOS 导入了二进制版本的 Dot Net 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。 主要就剩下这四个功能了https://github.com/dotnet/corefx/issues?q=is :open+ label:os-freebsd+label :up-for-grabs+is:issue 其中Filesystem watcher好像是最棘手/最费力的一个https://github.com/dotnet/corefx/issues/2046。

感谢@cschuber 的报价。 我们几乎到了可能的时候。
我们最近一直在与@mateusrodrigues 合作，让 .net 在 FreeBSD 上工作，他正在努力让 PowerShell 工作。 发送的列表@kasper3主要是缺少的功能。 我认为我们现在可以抛出 PNSP。 在我看来，最紧迫的问题是 dotnet/corefx#30698 和https://github.com/dotnet/coreclr/issues/18481。 如果社区中的任何人都可以深入研究它们，那就太好了。 我最近没有运行测试，但我担心失败的次数会增加。
我们应该为每个新的失败组打开问题。

我也开始修复源代码构建，但仍有一些挑战。
c#编译器是用c#编写的。 当前的 .net 构建使用以前版本的 .net 来生成托管程序集。 它还取决于 Nuget 的软件包。
现在，我们有足够好的引导程序 cli，我们可以在 FreeBSD 上构建 coreclr、corefx 和其他一些存储库。 我尚未更新构建说明以反映 2.1 更改和源代码构建。

+1 只是一个说明，我很高兴这仍然有一些动力。 这么多活动部件很难跟上，但似乎人们正在取得进展。 不久前我创建了https://github.com/dotnet/coreclr/issues/6115 ，但我正在处理的项目随后被搁置。 我真的希望有一天它像pkg install dotnet && dotnet build一样简单（没有 linux compat）。

也很期待这个

我们现在每天都在进行构建。 可以在此处获取运行时或 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 应用程序。

它仍然不完整且不受支持，但它应该使任何人都可以更轻松地做出贡献。
如果人们可以尝试一下，报告问题，那就太好了。
这也是最后推动缩小功能差距和修复错误的好时机。

抄送： @mateusrodrigues

干得好， @wfurt和@bartonjs。

大约 2-3 年前，当我提出我的第一个 FreeBSD 提交时，我实际上并不相信我们会到达这里，但我当然想尝试一下。

这绝对是一个重要的里程碑，希望能让新贡献者更轻松地帮助完成移植。

非常感谢所有帮助我们走到这一步的人👍

进步很大！ 我仍在与工具链（除了 LLDB 和 LLD 之外的大多数 LLVM 项目都已完成）和 NetBSD 的硬件辅助虚拟化（Linux/BSD 现在开始启动，直到 VTx 致命异常，像 FreeDOS 这样的更简单的操作系统已经工作）和硬件辅助虚拟化作斗争。所以我将继续我的 NetBSD 移植，希望早点。 更好的 FreeBSD 支持将有助于简化简历。

惊人的 ：）

我们庆祝醉酒为什么要炸锅？？

@krytarowski你能开

如果某些 FreeBSD 大师可以查看https://github.com/dotnet/coreclr/issues/22124 ，那就太好了，我希望为 11 构建的二进制文件可以在 12 上运行，但似乎并非如此；（
使用简单的应用程序很容易重现，12.0 版本似乎打破了 dotnet 所依赖的东西。

嗨，我不是专家，但我们在 Lua53 端口的 12-RELEASE 中遇到了线程回归。
请参阅此处了解原始错误： https :
此处是确定的基本系统错误： https : =235211 （注意基本系统错误标识了可用于重现问题以进行比较的代码）。

Lua 的修复是链接到 -pthread，即使 Lua 对 -pthread 的要求为零。

谢谢@RussellHaley。 这看起来很有希望。

很高兴我能帮助你。 我很想一起玩，但我几乎没有几个小时来维护 Lua 端口。 继续伟大的工作！

作为在 coreclr 中修复 FreeBSD 线程实现的人，我认为 pthreads 的使用非常一致，因为这是我必须修补以使构建运行的内容。

也就是说，可能存在使用“常规”线程的潜在但我从未接触过的东西......

也许其他对一般实现有更多了解的人可以插话？ @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。

是的，我想是这样。 我在等待@jooperator确认。
不确定我们是否也需要“dl”，但这可以在您提交 PR @josteink时解决

对。 我的错。 所以更像这样： https :

我已经为它创建了一个 PR。 让我知道它是否需要任何修改： https :

对。 我的错。 所以更像这样： josteink/ core-setup@a08f38e

我已经为它创建了一个 PR。 让我知道它是否需要任何修改： dotnet/core-setup#5072

仅供参考，这似乎已经在基本系统中打上了补丁： https :

看起来dotnet/coreclr#22124 中的主要问题已修复@wfurt。
我只在尝试在 FreeBSD 12.0 上发布独立应用程序时遇到问题。

freebsd-x64 官方 NuGet 包自 .NET Core 3.0 预览版 2 起已被删除，此后我们无法为 FreeBSD 发布应用程序。 有没有计划在 3.0 中重新启用它们？

可悲的是，我们不得不降低 FreeBSD 启动的优先级（由于各种原因和端到端 Azure 支持的困难），并且它不会在 .NET Core 3.0 中成为优先事项。
我们很想让它在现在的状态下保持半工作状态，但我们现在没有太多时间来投资:(。

@karelz感谢您的回复，我了解 .NET Core 3.0 的优先工作。 然后我将专注于使用 FreeBSD Linux 仿真来启动我的应用程序。 :)

@hjc4869或者您可以尝试单声道。 IIRC，它将支持.NET Standard 3.0

我打算再试一次，但正如@karelz提到的，它不是 3.0 的优先级

@newsash Mono 对我来说是一个可以接受的选择。 但是，我发现很难使用添加到现有 .NET Core csproj 文件的单声道目标来构建我的项目。

在 Linux 机器上，我尝试将 net472 添加到 TargetFrameworks 并设置 FrameworkPathOverride 变量，但效果不佳。 如果我使用在 mono 和 .NET Core 中实现的 API，而不是在 .NET Framework 中实现，它将无法使用 mono 构建。 此外，虽然mono支持.NET Standard 2.1，但我仍然无法在net472 csproj中添加对.NET Standard 2.1 dll的引用。

我应该添加一个单独的 csproj 并使用 mono msbuild 而不是使用 dotnet 工具，或者您对这个问题有什么建议吗？

只是一个简短的评论。

根据最近的公告 [1]，mono 即将被 .NET 5 吞并，为 FreeBSD 提供体面的支持已变得紧迫。

Mono 已被证明具有非常好的跨平台支持，并且可以毫无问题地从 FreeBSD 端口构建。 许多商店在 FreeBSD 上运行他们的 .net 负载，因为该操作系统具有许多独特的功能。 到目前为止，mono 一直在弥合这一差距，但随着 .NET 5 的出现，在不久的将来，mono 似乎很可能会被合并到 NET 5 中，而 FreeBSD 社区将完全脱离 .NET 生态系统。

在这种情况发生之前，Dotnet 应该有成熟的 FreeBSD 支持。

我认为此时微软应该正式支持 FreeBSD，并确保所有的 dotnet 工具都建立在这个平台上。

@jasonpugsley将说明放在一起https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD和@joperator正试图让源代码构建工作https://github。 com/dotnet/source-build/issues/1139

我们最近有大约 30 次测试未能通过 corefx。

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 ，https://github.com/dotnet/dotnet-buildtools-prereqs-docker/的 docker 映像，该映像已安装所有先决条件。 我们可以使用相同的 docker 容器在本地或远程机器上发布运行时包（基本上是 tar.gz）。 例如，我们可以在我们的 fork 分支之一中设置一个 GitHub 操作，例如： https : https://github.com/am11/runtime/releases/tag/6.0.0-dev.freebsd.1。 在这种情况下， dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz存档有足够的位来运行已发布的 dotnet 应用程序（来自具有 dotnet SDK 的不同 linux/mac 系统）。 我通过创建一个新的 12.2 VM (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在某个时候正在考虑创建一个合适的 FreeBSD Ports 包。

只是想知道是否有任何更新或是否已放弃？

你可能想看看https://github.com/dotnet/source-build/issues/1139
我最近在等待 dotNET5 final 时没有尝试过，但是几个月前，FreeBSD 运行时只能在 Linux 上构建为交叉编译。 ASPNet 和 SDK 也需要 Linux 交叉编译，但只有在星星对齐时才构建（街机更新或其他一些自动化机器人没有破坏依赖关系）

编辑： @am11在我打字时写了一篇更好的文章。 读那个而不是我的
编辑 2：忘记标点符号，看起来 final 是在 2 天前推出的。 我想我应该开始做那个或什么的

除了上述所有内容，我在https://github.com/dotnet/runtimelab/ 中创建了 FreeBSD 项目，并且我正在慢慢地构建和发布包。 目标是构建和发布足够的应用程序以在 FreeBSD 上运行，并为源代码构建提供种子。

我想我会写一个快速更新。 我终于让所有的行星都对齐以在 FreeBSD 上构建 5.0.0 RTM。 自 Preview3 以来，我一直没有跟上，花了一段时间（以及_许多_构建尝试）找到兼容构建的正确组合以获得成功的 5.0.0。
我已经能够以极少的 hack 构建 PowerShell 7.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 系统之外）完成这项工作的唯一问题是由于破坏更改而导致的麻烦，这些更改要求特定构建可用于下一个构建使用。 它并不经常发生，但需要大量的反复试验才能找到正确的提交。 在 CI 系统中使用 linux 交叉构建应该可以解决这个问题，但我还没有看过。 很高兴知道我可以构建一个完整的 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
如果我这个周末有更多时间，我会多研究一下，看看我是否至少可以在 linux 上为 freebsd 构建 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的二进制文件无法执行？
如果您尝试在 Ubuntu 18 或 20 上交叉编译 SDK 5x，您可能需要应用此补丁https://github.com/dotnet/sdk/commit/80e42f16422352f725d78be72071781d8365a238 （在主分支上）。

我真的需要在半睡半醒时停止发帖。
运行时和 sdk 的构建在 linux 上完成。
这些二进制文件在 freebsd 上运行（dotnet --info、新控制台和运行）
这些二进制文件无法从 freebsd 上的源创建运行时或 sdk

喔好吧。 我还没有尝试过混入 stage0 二进制文件以在 FreeBSD 上将运行时重建为 HostOS。

ld：错误：/root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim。 出口：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 的符号版本脚本，而不是 Darwin。 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吗？

恢复了补丁。 安装了gawk pkg。
懒得弄清楚 build.sh 脚本如何传递 cmake args，因为它没有立即意义，所以我只是符号链接 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 。

打开 #45663 以跟踪 ld 问题。 我也能够繁殖。

@Thefrank关于 ld 错误，试试这个：

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 的版本字符串包含(compatible with GNU linkers)以尝试沿着配置测试的 GNU ld 路径，但对于这种情况显然不够聪明:)

即使LD_GNU标志现在有点错误命名，在这里匹配 LLD 看起来也不错。

是的，它需要更多的工作。 标志名称现在令人困惑。 请不要有人试图按原样提交。

来自：Ed Maste [email protected]
发送时间：2020 年 12 月 7 日星期一上午 10:26:48
至：dotnet/runtime [email protected]
抄送：Jason Pugsley [email protected] ； 提及[email protected]
主题: Re: [dotnet/runtime] 支持 FreeBSD (#14537)

啊，链接器用户代理问题再次出现。 LLD 的版本字符串包括（与 GNU 链接器兼容）以尝试沿着 GNU ld 配置测试路径，但对于这种情况显然不够聪明:)

即使 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 --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):
我知道我前几天忘记做某事了！ 这应该很有趣

编辑：没有crossgen（也就是下半场）

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

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

Time Elapsed 00:12:05.56

编辑此帖子的最后一次编辑，我发誓：
我知道测试可能需要一段时间，它确实说长时间运行测试，但这对于一项测试来说已经失控了
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').