Runtime: Unterstützung für FreeBSD

Es scheint Einigkeit zu geben, was https://github.com/dotnet/corefx/issues/1576 betrifft.

Wenn wir auch eine Entscheidung über https://github.com/dotnet/corefx/issues/1625 haben, sollten wir in der Lage sein, Code zu versenden.

Eine Einigung über dotnet/runtime#14536 wurde vom Portteam erzielt, es sei denn, MSFT wählt etwas anderes, es ist FreeBSD . Problem dotnet/corefx#1999 wird möglicherweise das Problem sein, das die Definition in die öffentliche API einführt.

Eine Einigung über dotnet/runtime#14536 wurde vom Portteam erzielt, sofern MSFT nichts anderes wählt, wird es FreeBSD sein

Wenn ich das richtig gelesen habe, bedeutet dies, dass wir, wenn https://github.com/dotnet/corefx/pull/1999 zusammengeführt wird, diese MSFT-Genehmigung der neuen öffentlichen API betrachten können und daher die verbleibenden Probleme mit vorantreiben können regelmäßige Pull-Requests, ohne dass eine MSFT-Genehmigung erforderlich ist.

Wenn ja, klingt das gut für mich.

Die nächsten Schritte gemäß https://github.com/dotnet/corefx/pull/1999#issuecomment -111279577 sind:

1. Das "FreeBSD-Portierungsteam" setzt seine Arbeit fort, um eine FreeBSD-Version von CoreFX zu produzieren (getrackt von dotnet/corefx#1626).
2. Das Port-Team bringt genug vom CoreFX- und CoreCLR-Stack auf FreeBSD hoch, sodass wir mit der Ausführung der CoreFX-Komponententests auf FreeBSD beginnen können.
3. Die Tests erreichen ein minimales Qualitätsniveau. Ich weiß noch nicht genau, wie das aussieht, aber ich gehe davon aus, dass so etwas wie ein Großteil der Tests bestanden wird. Im Idealfall würden wir nicht nur für FreeBSD eine Reihe spezifischer Tests deaktivieren (im Vergleich zu Linux und OSX würden wir FreeBSD nicht auf einen höheren Standard als die anderen *NIX-Plattformen, die wir dort haben) halten wollen.
4. In Zusammenarbeit mit dem FreeBSD-Portierungsteam lässt das CoreFX-Team die CoreFX-Tests zu unserem CI-System hinzufügen, das auf FreeBSD läuft.
5. Besprechen Sie das Zusammenführen eines PR basierend auf dem Problem dotnet/runtime#14536, das die Eigenschaft hinzufügt.

Das klingt für mich nach einem völlig vernünftigen Plan.

Okay, dann fangen wir an, Corefx zum Laufen zu bringen.

Das erste Hindernis beim Erstellen von Corefx auf FreeBSD scheint Mono zu sein. Das Build-Skript besteht darauf, dass Version 4.1 erforderlich ist. @ajensenwaud hat am Frankfurt-Host etwas daran gearbeitet, aber ich bin mir nicht sicher, wie vollständig es ist.

Ich werde einen Build vorerst in die Warteschlange stellen und sehen, wie die Ausgabe aussieht.

Edit: Der (Mono-)Build stürzt mit folgendem Kicker am Ende ab:

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.

Das erste Hindernis beim Erstellen von Corefx auf FreeBSD scheint mono zu sein

FWIW, ich persönlich glaube nicht, dass dies das erste Hindernis ist. Es gibt zwei Build-bezogene Probleme:

1. Erstellen von Assemblys, die unter FreeBSD richtig funktionieren
2. Erstellen dieser Assemblys auf FreeBSD

(1) ist kritisch und ist meiner Meinung nach der Sinn dieses Themas. (2) ist sehr nett zu haben, aber das Fehlen davon verhindert nicht die Schaffung eines großartigen Systems zum Ausführen von verwaltetem Code auf FreeBSD.

Es steht Ihnen natürlich frei, Prioritäten zu setzen, wie Sie es für richtig halten, aber meine Empfehlung wäre, sich auf (1) statt auf (2) zu konzentrieren.

Beachten Sie, dass wir immer noch Probleme beim Erstellen von corefx unter Linux und beim Erstellen unter OSX haben, sodass unser CI-System die Assemblys für diese Plattformen unter Windows erstellt. Anschließend transportiert es die resultierenden Baugruppen zur Zielplattform, um die Tests auszuführen.

Das ist gerecht genug. Ich habe einfach angenommen, dass es einfacher wäre, allgemeine Unterstützung für die FreeBSD-Plattform in corefx zu integrieren, wenn wir sie tatsächlich selbst auf FreeBSD bauen könnten.

Ich werde mich vorerst mit Windows-initiierten Builds begnügen und versuchen, eine Build-Konfiguration zusammenzustellen.

@josteink übrigens. corefx sollte nun auf Mono 4.0.1.44 aufbauen.

@akoeplinger Schön. Das lässt mich hoffen, dass wir es auch auf FreeBSD zum Laufen bringen können :)

Gute Argumente. Wenn wir jedoch wirklich wollen, dass corefx Teil der FreeBSD-Umgebung ist, müssen wir es wirklich aus dem Quellcode kompilieren können, um es in das Ports-System zu bekommen.

Ich habe gehört, dass Mono 4.0.1.44 viele dieser Probleme behebt, hatte aber noch keine Zeit, damit zu spielen. Ich weiß, dass das Ports-Team das Port-Makefile aktualisiert, und wir sprechen mit einem neuen Patch.

Am 12. Juni 2015 um 20:21 Uhr schrieb Stephen Toub [email protected] :

Das erste Hindernis beim Erstellen von Corefx auf FreeBSD scheint mono zu sein

FWIW, ich persönlich glaube nicht, dass dies das erste Hindernis ist. Es gibt zwei Build-bezogene Probleme:

Erstellen von Assemblys, die unter FreeBSD richtig funktionieren
Erstellen dieser Assemblys auf FreeBSD
(1) ist kritisch und ist meiner Meinung nach der Sinn dieses Themas. (2) ist sehr nett zu haben, aber das Fehlen davon verhindert nicht die Schaffung eines großartigen Systems zum Ausführen von verwaltetem Code auf FreeBSD.

Es steht Ihnen natürlich frei, Prioritäten zu setzen, wie Sie es für richtig halten, aber meine Empfehlung wäre, sich auf (1) statt auf (2) zu konzentrieren.

Beachten Sie, dass wir Corefx-Building-on-Linux und Building-on-OSX kaum haben, so dass unser CI-System die Assemblys für diese Plattformen unter Windows erstellt; Anschließend transportiert es die resultierenden Baugruppen zur Zielplattform, um die Tests auszuführen.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Ja, da bin ich in keiner Weise anderer Meinung... es ist wichtig, corefx unter Linux, OSX und FreeBSD zu _builden_. Ich schlage lediglich vor, dass es aus einer vorrangigen Perspektive wichtiger ist, in der Lage zu sein, corefx unter Linux, OSX und FreeBSD tatsächlich _auszuführen_. :wink: Wenn beides parallel bearbeitet werden kann, umso besser.

@ghuntley ,
Wäre super :cool: wenn wir eine Checkliste für Markdown-Aufgaben hätten, die skizziert, was noch übrig ist:

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

rendert als:

• [ ] Aufgabe 1
• [ ] Aufgabe 2
• [ ] Aufgabe 3

Dies wird wahrscheinlich andere dazu ermutigen, diese Leistungen zu erzielen, und die FreeBSD-Unterstützung wird eher früher als erwartet eintreffen! :Sonnenbrille:

Meines Wissens sind folgende Arbeiten in CoreFX für die FreeBSD-Unterstützung erforderlich:

• [x] Einführung der FreeBSD-Plattform in die Build-Tools und Skripte. ( Erstellt von

13 Assemblies kompilieren nicht selbst und benötigen FreeBSD-spezifische Änderungen. Meist die Interop-Teile, die bereits für Linux/OS X existieren (Reihenfolge nach Vorkommen in der Build-Ausgabe):

• [x] System.Private.URI (fertig, PR dotnet/corefx#2032 zusammengeführt)
• [x] System.Console (fertig, PR dotnet/corefx#2031 zusammengeführt)
• [x] System.Diagnostics.Debug (fertig, PR dotnet/corefx#2039 zusammengeführt)
• [x] System.Diagnostics.Process (Diskussion dotnet/corefx#2070, PR dotnet/corefx#3257)
• [x] System.IO.Compression.ZipFile (fertig, PR dotnet/corefx#2041 zusammengeführt)
• [x] System.IO.FileSystem.DriveInfo (Diskussion dotnet/corefx#2526, PR dotnet/corefx#2606)
• [x] System.IO.FileSystem.Watcher (Diskussion dotnet/corefx#2046, PR dotnet/corefx#3257)
• [x] System.IO.FileSystem (fertig, PR dotnet/corefx#2049 zusammengeführt)
• [x] System.IO.MemoryMappedFiles (Diskussion dotnet/corefx#2527, PR dotnet/corefx#3143)
• [x] System.IO.Pipes (Diskussion dotnet/corefx#2528, PR dotnet/corefx#2974)
• [x] System.Net.NameResolution (Diskussion dotnet/corefx#2988, PR dotnet/corefx#3471)
• [x] System.Security.Cryptography.Hashing.Algorithms (fertig, PR dotnet/corefx#2040 zusammengeführt)
• [x] System.Security.SecureString (fertig, PR dotnet/corefx#2039 zusammengeführt)
• [x] System.Runtime.Environment (blockiert von dotnet/corefx#1999 )
• [x] System.Runtime.InteropServices.RuntimInformation (fertig, PR dotnet/corefx#2068 zusammengeführt)

Ich werde versuchen, diese Liste basierend auf geöffneten und zusammengeführten PRs zu aktualisieren.

Zu Ihrer Information: PR dotnet/corefx#2039 zusammengeführt

Ich versuche nur, hier der Zeit voraus zu sein... Wie wollen wir System.IO.FileSystem.Watcher implementieren?

Iirc FreeBSD hat kein inotify wie Linux und Windows (deshalb gibt es auch keine Dropbox, als ich das letzte Mal überprüft habe). Wird dies eine potenzielle Quelle von Problemen sein, die auf uns zukommen? Oder hat jemand eine Idee, wie man das umgehen kann?

Ich schlage vor, dass wir das für den Moment ausblenden und eine PlatformNotSupportedException auslösen, wie Stephen Toub im anderen Thema vorgeschlagen hat (https://github.com/dotnet/corefx/pull/2021#issuecomment-111602342). Dann haben wir zumindest einen vollständigen Satz von Baugruppen und können an diesem speziellen Thema weiterarbeiten, ohne weitere Schritte zu blockieren.

Würde es Ihnen etwas ausmachen, dafür ein eigenes Thema zu eröffnen?

Verschieben wir System.IO.FileSystem.Watcher Diskussionen nach dotnet/corefx#2046

Leute, gibt es einen solchen Blocker für System.Diagnostics.Process ?

@jasonwilliams200OK hat FreeBSD heute früh zu CheckPlatformTests mussten zurückgesetzt werden, bis dotnet/buildtools aktualisiert wurde.

• [ ] Build-Tools aktualisieren, um FreeBSD zu unterstützen - https://github.com/dotnet/buildtools/pull/180
• [ ] [Fact,PlatformSpecific(PlatformID.FreeBSD)] Tests erneut auf CheckPlatformTests anwenden – siehe https://github.com/dotnet/corefx/pull/2068#discussion_r32570244 und https://github.com/dotnet/corefx/pull/2068#discussion_r32570244
• [ ] public static OSPlatform FreeBSD zu https://github.com/dotnet/corefx/pull/2068 hinzufügen

@jasonwilliams200OK gestern Abend gab es einige Diskussionen über System.Diagnostics.Process in gitter, die in https://github.com/dotnet/corefx/issues/2070 formalisiert wurden

@ghuntley , danke. Ich habe diese Nachrichten tatsächlich gelesen. System.Diagnostics.Process ist eine knifflige Angelegenheit. AFAIK, das io.js-Team hatte ähnliche Herausforderungen beim FreeBSD-Prozessmanagement. Das Mono-Team hat es wahrscheinlich geschafft, also hoffen wir, wenn

System.IO.FileSystem.DriveInfo

Wie im Gitter besprochen, habe ich für dieses versucht, die grundlegende Verwendung von 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);
  }
}

Das Ausführen dieses Beispiels ergab diese Ausgabe:

$ ./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
$

Es scheint also zu tun, was wir brauchen. Die Frage ist, sollten wir die Ergebnisse irgendwie filtern?

Betrachtet man die "Absicht" des DriveInfo Objekts aus der Windows-Welt von .NET, so bestand es oft darin, die verfügbaren Speicherorte zum Speichern oder Abrufen von Dateien aufzuzählen ( C: , D: usw.). Aber wenn Sie hierarchische Unix-Dateisysteme verwenden, wäre die Rückgabe von / ausreichend, um diese Bedürfnisse zu decken.

Was sollen wir also zurückgeben? Was wäre nützlich? Sollte es überhaupt als nützlich angesehen werden oder nicht?

Die Linux-Version gibt einfach alles aus, außer Dinge, die ignoriert werden sollen:

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

Ich habe versucht, den folgenden Filter einzubauen, aber es hat sich in Bezug auf die Ausgabe nicht wirklich etwas geändert:

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

Irgendwelche Meinungen?

@josteink , tolle Ausgrabungen! Basierend auf https://github.com/dotnet/corefx/issues/815#issuecomment -113825960 und https://github.com/dotnet/corefx/issues/1729 denke ich, dass wir mit @sokket zusammenarbeiten sollten , um etwas zu entwickeln eine Lösung, die über verschiedene Unices hinweg funktioniert.

Ich habe eine Version unter OSX, die getmntinfo und statfs verwendet, um Informationen zu jedem Einhängepunkt zu erhalten, was die logischste Zuordnung des Windows-Laufwerkkonzepts zu sein scheint. Ich überprüfe, ob die Funktions- und Strukturdefinitionen unter OSX mit den FreeBSD-Definitionen übereinstimmen, und wenn ja, funktioniert mein Commit für OSX auch für BSD.

Ich werde dich sicher zu meiner PR @josteink hinzufügen

Hört sich gut an. Danke für den Hinweis und danke, dass du FreeBSD auch etwas Liebe geschenkt hast.

Ich habe mir einige grundlegende Pinvoke für diese Funktionen angesehen, und es scheint, als müssten wir das gesamte Marshalling und die Konvertierungen selbst durchführen. ;)

Kein Problem...scheint der Hauptunterschied in den struct-Deklarationen zu liegen; Da wir in Zukunft wahrscheinlich häufiger darauf stoßen werden, mache ich einige Refactorings, die es uns ermöglichen, viele der PInvoke-Signaturen zu teilen. Ich werde in meinem PR eine ausführlichere Beschreibung hinzufügen (heute oder morgen, basierend auf dem Testlauf), aber im Grunde habe ich die PInvoke-Signaturen und Struktursignaturen für FreeBSD hinzugefügt (basierend auf den Headern, die ich online gefunden habe) und es wird kompiliert. Ich habe es auf einem Mac getestet, also _sollte_ (theoretisch...) auf FreeBSD funktionieren, da es nur eine Änderung der Strukturdeklaration ist, aber Ihre Laufleistung kann variieren :). Wenn dies nicht der Fall ist, haben Sie die DriveInfo-Klasse und PInvokes 99% des Weges und benötigen nur einige Anpassungen basierend auf FreeBSD-Nuancen.

Ausgezeichnete Nachrichten @sokket. Ich habe Ihnen ein Konto auf dem Computer erstellt, den das Port-Team für die Entwicklung verwendet. Er basiert auf Europa, ist aber immer aktiv und verfügt über jede Menge Speicher und Rechenleistung. Hoffentlich hilft dies und beseitigt einige der Reibungen beim Arbeiten mit FreeBSD.

# ssh [email protected]

Die Kennwortauthentifizierung ist deaktiviert, verwenden Sie einen Ihrer Schlüssel .

@josteink siehe auch Ausgabe: https://github.com/dotnet/corefx/issues/815 (System.IO.FileSystem.DriveInfo für Mac/FreeBSD)

Gibt es Updates? Hat jemand die verbleibenden Assemblies auf FreeBSD implementiert?

Ich war damit beschäftigt, mein neues Baby zu betreuen, hatte nirgendwo Zeit zum Programmieren.

Ich habe vermutet, dass Probleme wie diese schlummern und ich denke, dies bestätigt es in gewissem Maße.

Für die noch nicht implementierten Assemblies habe ich das "How to implement"-Thema in der obigen Liste verlinkt. Ich hoffe, das hilft bei der Koordinierung der Bemühungen, diese verbleibenden Baugruppen zu implementieren.

Ich muss zugeben, dass ich Schwierigkeiten hatte, den Überblick zu behalten, was wir wo gemacht haben, also ist das definitiv ein guter Schritt. Gut gemacht :)

Wo finde ich das? Wäre dankbar die restlichen Baugruppen zu bekommen
umgesetzt.

Am 25.07.15 22:10 schrieb Jan Henke:

Für die noch nicht implementierten Baugruppen habe ich das "wie . verlinkt
zu implementieren"-Problem in der obigen Liste. Ich hoffe, das hilft bei der Koordination
die Bemühungen, diese verbleibenden Baugruppen zu implementieren.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/dotnet/corefx/issues/1626#issuecomment -124838781.

Dieser Kommentar hier: https://github.com/dotnet/corefx/issues/1626#issuecomment -111800540

Ich warte gerade darauf, dass die nativen Shims fertig sind, da diese den größten Teil der Arbeit übernehmen sollten, um diese Assemblys unter FreeBSD zum Laufen zu bringen.

@nguerrera wäre großartig, wenn Sie uns über den Fortschritt auf dem

Aktualisieren:
@janhenke hat bestätigt, dass System.IO.Pipes mit der Zusammenführung von https://github.com/dotnet/corefx/pull/2974 auf FreeBSD aufbaut! :Sonnenbrille:

Aktualisieren:
dotnet/corefx#2527 geschlossen, System.IO.MemoryMappedFiles baut auf FreeBSD auf.
Danke @janhenke für die Bestätigung!

Dank des Shims-Ansatzes kommt es nur darauf an, sicherzustellen, dass die Shims auf FreeBSD kompiliert werden. Das macht das Leben zum Glück viel einfacher. :)

dotnet/corefx#3257 sollte uns sowohl System.Diagnostic.Process als auch System.IO.FileSystem.Watcher und nur System.Net.NameResolution ungelöst lassen. (Ich werde die beiden erwähnten Assemblys überprüfen, sobald die PR zusammengeführt ist und auf FreeBSD funktioniert)

dotnet/corefx#3471 sollte uns System.Net.NameResolution und die obige Liste vervollständigen.

dotnet/corefx#3471 wurde gerade zusammengeführt :)

@sokket , danke für das Update. Ich habe den Master (f467911) auf FreeBSD mit dieser Anleitung erstellt: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24. Aktueller Blocker ist https://github.com/dotnet/buildtools/issues/292, der im Upstream behoben wurde, aber auf den nächsten Rollout von Buildtools wartet. :)

Update: Neue Buildtools mit Fix für dotnet/buildtools#292 sind im CoreFX-Master gelandet. Der nächste Stopper von buildtools ist https://github.com/dotnet/buildtools/issues/300 : fehlendes betriebssystemspezifisches Tool, um die Tests ausführen zu können.

@janhenke , du hast System.Diagnostics.Process (#2070) und System.IO.FileSystem.Watcher (#2046) als erledigt markiert; aber sie sind weder implementiert noch werden sie auf FreeBSD kompiliert. Haben Sie die Liste tatsächlich überprüft, indem Sie den verwalteten Code kompiliert haben?

Basierend auf meiner jüngsten Erfahrung mit dem Commit 60c78da3c918b0d256cc1f878de06d351dbe3342 (siehe msbuild.log ) werden die folgenden Assemblys nicht kompiliert:

• System.Diagnose.Prozess
• System.Diagnose.ProzessManager
• System.Diagnose.ThreadInfo
• System.IO.FileSystemWatcher
• System.Net.SocketAddress _(in Ordnung, dieser wurde vor kurzem hinzugefügt)_

Soweit ich mich erinnere, habe ich die zugehörigen Shims kompiliert. Da der verwaltete Code frei von FreeBSD-spezifischem Code sein sollte. Diese Shims, die Sie erwähnen, hätten mit den oben verlinkten PRs ausgeblendet werden sollen.
Zwischendurch habe ich aber auch eine komplette Kompilierung laufen lassen. Zumindest System.Diagnostics.ThreadInfo und System.IO.FileSystemWatcher haben kompiliert. Es muss sich also etwas zurückgebildet haben.

Diese Shims, die Sie erwähnen, hätten mit den oben verlinkten PRs ausgeblendet werden sollen.

Eigentlich hat PR https://github.com/dotnet/corefx/pull/3257 nichts mit Shim zu tun. Es gibt immer noch etwas PAL-Code in den verwalteten Projekten (der alte Ansatz), daher ist es erforderlich, verwaltete Assemblys zu erstellen, um absolut sicher zu sein.

Eigentlich hat PR dotnet/corefx#3257 nichts mit Shim zu tun.

Ich bin nicht einverstanden. Es refaktoriert den P/Invoke-Code in das System.Native-Shim. Auch wie ich oben bearbeitet habe, erinnere ich mich an zumindest einige der zwischenzeitlich kompilierten Assemblys.

ich bin nicht einverstanden

https://github.com/dotnet/corefx/pull/3257/files : Siehe die Instanzen von .Unix.cs und .Linux.cs für System.Diagnostics. . Beachten Sie, dass .OSX.cs unberührt ist.

Es refaktoriert den P/Invoke-Code in das System.Native-Shim

Ja, es refaktoriert einige gängige Helfer unter System.Native , aber nicht System.Diagnostics.* et al.

Selbst wenn diese Assemblys nur P/Invoking to System.* libs sind, kann für einige von ihnen noch FreeBSD-Arbeit erforderlich sein, zB System.Diagnostics.Process und System.IO.FileSystem.Watcher. Sie verwenden Funktionen, die für Linux und OS X spezifisch sind, und wir planen nicht, dies hinter nativen Shims zu abstrahieren. Das Ziel der Shims ist nicht, mit einer einzigen verwalteten Binärdatei für Unix zu enden, obwohl dies eine sehr schöne Eigenschaft ist, wenn sie von der Arbeit herrührt; Das primäre Ziel ist es, ABI-Unterschiede zu vermeiden, die Fragilität verursachen. Ich gehe davon aus, dass mindestens eine Handvoll Assemblys weiterhin Linux/OS X-spezifische Binärdateien enthalten werden, wo auch eine FreeBSD-Binärdatei benötigt würde.

Zu Ihrer Information, es gibt keine Corefx-Assemblys namens System.Diagnostics.ProcessManager,
System.Diagnose.ThreadInfo,
System.IO.FileSystemWatcher, oder
System.Net.Socket-Adresse. Das sind Typen in anderen Assemblys.

Ich gehe davon aus, dass mindestens eine Handvoll Assemblys weiterhin Linux/OS X-spezifische Binärdateien enthalten werden, wo auch eine FreeBSD-Binärdatei benötigt würde.

Bedeutet das, wann immer Solaris und non-glibc (musl und μlibc), die auf Linux abzielen, wie Alpine-Unterstützungen, ankommen, werden sie separate Binärdateien haben? Und dann würden unterschiedliche Architekturen ARM, MIPS, RISC, SPARC etc. eine andere Trennebene erfordern?

Wäre es nicht sinnvoll, sie so weit wie möglich auf POSIX-Schnittstellen / Systemaufrufe zu konvergieren und die Unterschiede mithilfe von Konfigurationen (über CMake) zu erkennen, die in derselben Binärdatei verwendet werden (es sei denn, dies beeinträchtigt die Größe / Leistung der Baugruppen erheblich)? Wie ich es verstanden habe, hat die Binärdatei System.Native.so einen gemeinsamen Helfer für andere spezifische System.*.Native.so was für die Einhaltung des Prinzips der Trennung von Belangen ausreicht. Aber wenn es in System.Net.Http.FreeBSD.ARM.Native.so oder System.Net.Http.Solaris.SPARC.so , dann wird es ziemlich unhandlich mit "zu vielen beweglichen Teilen" usw.

es sind keine Corefx-Assemblys benannt

Guter Punkt. Ich ging tatsächlich nach den Fehlerinstanzen in den msbuild-Protokollen und der Anzahl der .OSX.cs und .Linux.cs Dateien. :Lächeln:

Wäre es nicht sinnvoll, sie so weit wie möglich auf die POSIX-Schnittstelle / Systemaufrufe zu konvergieren?

Wir tun. Wie schlagen Sie eine gute Dateiüberwachung über POSIX vor? Wie schlagen Sie vor, dass wir die Enumeration über POSIX gut verarbeiten?

Aber wenn es in System.Net.Http.FreeBSD.ARM.Native.so oder System.Net.Http.Solaris.SPARC.so umgewandelt wird, dann wird es mit "zu vielen beweglichen Teilen" usw. ziemlich unhandlich sein

Ich verstehe das nicht. Der springende Punkt der nativen .so-Dateien ist, dass Sie für jede Zielplattform unterschiedliche native Binärdateien erhalten, aber sie heißen nicht System.Whatever.Platform.ext, sondern nur System.Whatever.ext; Dies ermöglicht es dem Compiler, dieselbe allgemeine Logik zu verwenden und sie mit den für diese Plattform spezifischen Definitionen zu verwenden. Dies funktioniert nur, wenn auf jeder Plattform dieselben Symbole vorhanden sind; der Compiler nimmt nicht auf magische Weise Code, der für die Verwendung von inotify geschrieben wurde, und lässt ihn mit der Dateiüberwachungsschnittstelle eines anderen Systems arbeiten. Im Allgemeinen haben wir uns bemüht, standardisierte APIs zu verwenden, wo es sinnvoll ist, aber für Orte, an denen solche APIs nicht existieren oder nicht gut standardisiert sind oder wo es bessere plattformspezifische Lösungen gibt, haben wir die bessere Plattform verwendet. spezifische Lösungen, z. B. die Verwendung von procfs für die Prozessaufzählung unter Linux, die Verwendung von inotify für die Dateisystemüberwachung unter Linux usw. Ob eine solche plattformspezifische Logik in verwaltetem oder nativem Code lebt, spielt aufgrund der einfachen Portierbarkeit keine Rolle. zusätzliche Plattformen-Perspektive, wenn diese neuen Plattformen auf den Markt kommen, wenn die vorhandenen APIs funktionieren, dann auch die vorhandene Lösung, und wenn dies nicht der Fall ist, müssen Sie eine neue Lösung für diese Plattform schreiben. Deshalb haben wir versucht, so viel wie möglich mit verwaltetem Code zu machen, indem wir native einfach für die 1:1-Shims verwendet haben, die diesen verwalteten Code viel portierbarer machen, wo die Ziel-APIs portabel sind. Wir haben #ifdefs im nativen Code verwendet, um kleine Details zu beschönigen, bei denen diese API auf welcher Plattform der API auf einer anderen Plattform nahe genug ist, aber das erstreckt sich nicht darauf, dass ganze Lösungen völlig anders sind. An diesem Punkt wird die Abstraktion zur verwalteten API und wir führen für jedes System eine andere verwaltete Implementierung durch.

Wenn FreeBSD inotify wie Linux oder EventStream wie OS X verfügbar macht, dann, wenn diese Betriebssystem-APIs hinter dem Shim sind, kann der Shim leicht mit FreeBSD zusammenarbeiten, und dieselbe verwaltete Binärdatei kann auf FreeBSD verwendet werden. Wenn FreeBSD solche APIs nicht verfügbar macht, müssen Sie eine benutzerdefinierte Implementierung von System.IO.FileSystem.Watcher mit einer Dateiüberwachungslösung schreiben, die auf FreeBSD verfügbar ist. Ähnliche Kommentare für System.Diagnostics.Process. Ob sich der Code für die Dateiüberwachung im Shim befindet oder nicht, hat darauf wenig Einfluss.

Der Plan sieht vor, dass all diese nativen APIs irgendwann hinter das Shim verschoben werden. Aber sie haben bei weitem keine Priorität, da sie nicht sehr portabel sind, und Sie haben gesehen, wie wir mit APIs von libc beginnen, die überall verfügbar sind (oder sein sollen).

Wie schlagen Sie eine gute Dateiüberwachung über POSIX vor?

Wir können nicht alles POSIX tun, da inotify Linux-spezifisch ist. FreeBSD/OSX bietet separate Implementierungen.

Vorschlag:

Aus Sicht der nativen Binärverteilung sollte jedes Betriebssystem den gleichen Satz von Binärdateien mit gleichen Namen, aber unterschiedlichen Funktionen erhalten.

Hier eine vorgeschlagene Struktur:

# 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

Das ist im Wesentlichen das, was wir haben, zB

• "common_function_for_posix_compliants" sind nativ geshimmte 1:1-Funktionen, die von der Logik in einer gemeinsam genutzten Unix-verwalteten Binärdatei verwendet werden
• "slightly_diverged_function" sind nativ geshimmte fast 1:1-Funktionen mit einigen nativen #ifdefs, die von der Logik in einer gemeinsam genutzten Unix-verwalteten Binärdatei verbraucht werden
• "painfully_diverged_watch_function" sind / werden nativ geshimmte 1:1-Funktionen, die von der Logik in plattformspezifischen verwalteten Binärdateien verwendet werden

Der wirkliche Unterschied besteht darin, ob der Code, der die "schmerzhaft abweichende" Logik implementiert, in C# oder C++ ausgeführt wird, und wir uns für C# entschieden haben und alles bereits in C# implementiert ist. Ich habe kein überzeugendes Argument dafür gesehen, warum es in solchen Fällen eine wesentlich überzeugendere Option wäre, alles in C++ umzuschreiben.

@jasonwilliams200OK Mit dem heutigen Update auf Mono baue ich corefx wieder auf FreeBSD selbst. Es gibt viele neue Fehlermeldungen seit ich es das letzte Mal gebaut habe.
Ich frage mich, ob Interop.Libc irgendwann verschwinden wird?

@stephentoub Auf die Verpackung kommt es an. Den gesamten plattformspezifischen Code im nativen Teil zu haben, hat den Vorteil, eine verwaltete Assembly für alle Unix-ähnlichen Plattformen zu haben.
Außerdem glaube ich stark, dass wir für diesen "plattformabhängigen verwalteten Code" eine generische Implementierung brauchen. Auch wenn es nur eine NotImplementedExcpetion wirft. Auf diese Weise können Sie viel einfacher auf neue Plattformen portieren, wenn es zumindest alles sofort kompiliert. Außerdem würde es geben die Chance, zumindest zu versuchen, auf einer nicht unterstützten Plattform zu laufen.
Im Allgemeinen ist es viel einfacher, wenn Sie zumindest auf Anhieb erfolgreich kompilieren können.

@stephentoub , Entschuldigung, ich habe C++ mit C# gemischt. Jetzt verstehe ich, dass die native Schicht nur diese Einstiegspunkte (native Libs-Funktionen oder Systemaufrufe) offenlegt und wir beim Bereinigen von IO und verwaltetem Code entscheiden, welche plattformspezifische umschlossene Dienstprogrammmethode / umhüllter Systemaufruf verwendet werden soll. Außerdem können beide (native und verwaltete) Tiers nicht betriebssystemagnostisch sein, wenn Nicht-POSIX-Funktionalität genutzt werden soll.

@janhenke , ich stimme zu. Ich bin auch Baumeister, während wir sprechen. Es gibt ein weiteres wiederkehrendes Problem beim Signieren von Assemblys, auf das ich treffe:

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]

wird in Kürze den vollständigen msbuild.log-Gist-Link veröffentlichen.

Außerdem glaube ich stark, dass wir eine generische Implementierung für diesen "plattformabhängigen verwalteten Code.

Ich stimme zu. Anstelle von partiellen Klassen können wir wahrscheinlich die Vererbung mit gemeinsamen und meist gängigen virtuellen Methoden in abstrakten Basisklassen verwenden und bei Bedarf für "meist häufig / teilweise unterschiedlich" überschreiben. Implementieren Sie dann abstrakte Methoden, die für jedes Betriebssystem völlig unterschiedlich sind. Mit diesem IMO-Ansatz können wir, wenn die Spezialisierung/Verallgemeinerung an DRY'ing verliert, mehrstufige Vererbungsvorfahren einstellen. Aber als ich das letzte Mal nachgesehen habe, wurden in CoreFX Teilklassen gegenüber der Eltern-Kind-Zuordnung bevorzugt (aus irgendeinem Grund, an den ich mich nicht erinnern kann). :)

Hier ist die msbuild.log für Commit 2d36889:

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

/cc: @akoeplinger

@jasonwilliams200OK Warum so kompliziert. Alles was es braucht ist eine "wenn nicht Windows,Linux,OS X" Bedingung in den Projektdateien. Fügen Sie also entweder einen plattformspezifischen Satz von Dateien in den Build ein oder die generischen.

Ich denke nicht, dass die Tatsache, dass einige Assemblys nicht für FreeBSD bauen/arbeiten können, ein Hauptblocker sein sollte, um den Rest von ihnen zu testen. Wir sollten es wahrscheinlich einfach so machen, dass diejenigen mit ausstehenden Arbeiten (FileSystemWatcher, Process, Networking) beim Build und Testlauf auf FreeBSD übersprungen werden. Dann können wir diese einzeln ansprechen, während wir einen Prozess haben, um einen Rückschritt in das zu verhindern, was bereits funktioniert.

Ich denke nicht, dass die Tatsache, dass einige Assemblys nicht für FreeBSD bauen/funktionieren können, ein Hauptblocker sein sollte, um den Rest zu testen

Einverstanden

Wir sollten es wahrscheinlich einfach so machen, dass diejenigen mit ausstehenden Arbeiten (FileSystemWatcher, Process, Networking) beim Build und Testlauf auf FreeBSD übersprungen werden

Oder ähnlich wie @janhenke vorgeschlagen, erlauben Sie ihnen einfach zu bauen, entweder indem Sie Dateien mit PlatformNotSupported auswerfen, oder indem Sie FreeBSD einfach einem der Fälle zuordnen, die funktionieren, z. es wird nicht funktionieren, aber es wird gebaut).

Mit den letzten Änderungen von

• Laden Sie nach https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 (insbesondere dem Schritt zum separaten Erstellen von nativen Shims _nach_ dem build.sh-Exit mit Status 1) die CoreCLR- Artefakte- Zip herunter: cd /root; curl -o bins.zip "http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/debug_freebsd/lastSuccessfulBuild/artifact/*zip*/archive.zip (nicht vergessen die Anführungszeichen um die URL) und dann unzip bins.zip; chmod -R 0777 archive/; rm bins.zip; cd corefx .

(nichts erforderlich von Windows-Rechner)

• Habe den Test durchgeführt:

./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

Es sagt:

40 Test(e) nicht bestanden

Ich denke nicht, dass die Tatsache, dass einige Assemblys nicht für FreeBSD bauen/arbeiten können, ein Hauptblocker sein sollte, um den Rest von ihnen zu testen.

Diesem muss ich zustimmen. Es ist besser, mit der Qualitätssicherung der von uns geleisteten Arbeit zu beginnen, anstatt zu warten, bis alles abgeschlossen ist, bevor Sie mit dem Testen beginnen.

Da steht: 40 Test(e) fehlgeschlagen

40 von wie vielen? In welchem ​​Stadion sind wir? :)

40 von wie vielen? In welchem ​​Stadion sind wir? :)

schlägt mich auch. Die Tests werden aus Testassemblys (verwalteten DLLs) hervorgebracht und die Gesamtzahl der Tests ist nicht sichtbar.

Die Zahl, die das Skript am Ende erzeugt, ist die Anzahl der fehlgeschlagenen Testassemblys. xUnit sollte die Anzahl der Tests, die pro Assembly fehlgeschlagen sind, als Teil der Ausführung in stdout schreiben. Die Nummern sollten auch in den XML-Dateien enthalten sein, die in jedem Testbaugruppenordner erstellt werden.

Es könnte auch sein, dass die Laufzeit gerade abstürzt und in diesem Fall möglicherweise keine Protokolle pro Testassembly erstellt werden.

@jasonwilliams200OK Wissen Sie, ob beim Signieren der Assembly Fortschritte

@naamunds , das auf CoreFX-Master als Teil von https://github.com/dotnet/corefx/issues/3739 behoben wurde

Update - Heute habe ich FreeBSD-Tests durchgeführt, Tausende von ihnen bestanden und einige scheiterten aufgrund des offensichtlichen Mangels an System.Diagnostics.Process und Freunden. Nach ~40 Minuten erfolgreicher Ausführung hing es bei System.IO.FileSystem-Tests (etwa 15 Minuten lang, bevor ich zum Beenden Strg+C drückte).

@jasonwilliams200OK wie hast du es geschafft, corefx unter freebsd zu kompilieren? Ich stecke bei Fehlern über gssapi . fest

@sec , zum Zeitpunkt der Erstellung dieser Notizen: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 wurde GSSAPI von CoreFX nicht benötigt. Es scheint jedoch, dass das pkg kürzlich auf FreeBSD portiert wurde: http://www.freshports.org/security/p5-GSSAPI. Vielleicht möchten Sie pkg upgrade pkg && pkg update && pkg install p5-GSSAPI ausprobieren.

@jasonwilliams200OK , das habe ich bereits bekommen (es ist übrigens Perl ext.) Problem fehlte gssapi_ext.h. Der Trick bestand darin, "pkg install krb5" auszuführen - jetzt nativ kompiliert.
Ich habe sie in die Coreclr-Laufzeit kopiert, kann aber die ASP.NET Core-App immer noch nicht ausführen :) Der Kampf geht dann weiter.

Wie ist der aktuelle Status dieser Aufgabe? Ist die Liste von @janhenke vollständig und korrekt? Ist alle Arbeit, die getan werden muss, erledigt? Dann sollte es geschlossen sein, oder?

Wenn ja, warum haben wir diese Aufgabe noch? https://github.com/dotnet/corefx/issues/2070

Wenn noch Arbeit zu tun ist, soll nach aktuellem Stand eine neue Emission registriert werden?

Ich denke, das wird auch benötigt - dotnet/corefx#2046

soll nach aktuellem Stand eine neue Emission registriert werden?

Ja :+1:

Wir diskutierten mit @RussellHaley (von der FreeBSD-Community) und @wfurt (vom .NET Core-Team) über die Community-gesteuerte Portierung für FreeBSD, die beide Interesse an der Arbeit bekundeten.
Hier ist ein Planvorschlag, den wir zusammengestellt haben (Feedback / Vorschläge sind willkommen):

1. Produzieren Sie Binärdateien in CoreCLR- und CoreFX-Repo, die auf FreeBSD abzielen - Hacks zu verwenden ist in Ordnung
   
   
   
   • Schwer zu parallelisieren, @wfurt wird daran arbeiten
   
   
   • Der Build kann eine Mischung aus Builds von anderen Plattformen (Mac, Linux) sein, die auf FreeBSD abzielen
   
   
   • Wir benötigen dokumentierte Schritte (im FreeBSD-Wiki), um den Build mit FreeBSD-spezifischen Fehlerkorrekturen zu reproduzieren
   
   
2. Ausführen und Stabilisieren von CoreCLR-Tests (mit corerun)
   
   
   
   • Tests können auf einer anderen Plattform erstellt werden
   
   
   • Ziel: Liefert grundlegende Laufzeitqualität
   
   
3. Ausführen und Stabilisieren von CoreFX-Tests (mit corerun)
   
   
   
   • Tests können auf einer anderen Plattform erstellt werden
   
   
   • Beachten Sie, dass dies xunit erfordert. Aufgrund unserer bisherigen Portierungserfahrungen glauben wir, dass xunit, sobald [2] fertig ist, einfach funktionieren wird.
   
   
   • Dies kann theoretisch mit [2] parallelisiert werden - es kann eine Verknüpfung von xunit erfordern (z. B. ein statisches Ausführungsrezept auf einer anderen Plattform generieren).
   
   
4. Full-Stack-Build auf FreeBSD (mit Corerun als Bootstrapper von [1]-[3])
   
   
   
   • Wir benötigen alle Tools (nuget, msbuild, roslyn), um am Boostrapping von .NET Core zu arbeiten
   
   
5. Installer (FreeBSD-Ports)
   
   
   
   • Erste Phase: Verwenden von Produktbinärdateien aus Nuget-Feeds
   
   
   • Zweite Stufe: Produkt aus der Quelle erstellen (blockiert bei Erstellung aus der Quelle)
   
   
   • Erfordert FreeBSD-Community-Expertise und Anleitung zum Design
   
   
   • Hinweis: Wir können FreeBSD-Pakete auch von offiziellen .NET Core-Downloadseiten als Community-Support-Pakete verlinken
   
   
6. Regelmäßige Build- und Testläufe auf FreeBSD
   
   
   
   • Ziel: Stellen Sie sicher, dass Änderungen in .NET Core-Repositorys, die FreeBSD beeinträchtigen, frühzeitig bekannt sind
   
   
   • Design benötigt
   
   
   • Erfordert FreeBSD-Community-Expertise und Anleitung zum Design
   
   

Funktionsprinzipien:

• Änderungen in [2]-[4] sollten hauptsächlich in CoreCLR/CoreFX-Repositorys vorgenommen werden (aufgrund von CLA-Signaturanforderungen, Codeüberprüfungen von .NET Core-Teamexperten/-mitgliedern usw.)
• Wir werden die hochrangige Arbeit zu diesem Thema verfolgen. Spezifische Fehler werden als separate Probleme eingereicht.

Falls jemand Interesse hat zu helfen, bitte hier melden. Wir können Workitems aus den obigen [2] & [3] leicht verteilen, wenn wir mit [1] weit genug sind.

Die neueste Version des Vorschlags befindet sich im Top-Post dieser Ausgabe.

Weitere Leute markieren , die Interesse an der freebsd-mono-Liste bekundet haben ( dieser Thread ): @smortex @radovanovic @Echo-8-ERA

Übrigens: Ich kann Mathieu Prevot GitHub-Konto nicht finden -- [UPDATE] Gefunden in https://github.com/dotnet/corefx/issues/1626#issuecomment -330348424: @mprevot

Für NetBSD vermissen wir robuste Posix-Mutexe, dies ist das einzige Feature, das noch fehlt, um benannte Robus-Mutexe zu erzeugen. Wir können jetzt verwaltete Codefehler mit LLDB/NetBSD debuggen. Es funktioniert gut mit Core-Dateien. Bei meinen vorherigen Versuchen sind wir am Fehlen dieser Funktion in LLDB gestorben (ich habe begonnen, diesen Debugger für .NET zu portieren).

Eine bessere FreeBSD-Unterstützung wird erheblich helfen.

In der Vergangenheit gab es auch Probleme mit fehlender Hyperv-Gastunterstützung, um einen NetBSD-Buildbot an CI-Maschinen anzuschließen und Patches zu überprüfen ... dafür brauche ich möglicherweise Hilfe von MS. Ich gehe davon aus, dass für die Ausführung proprietäre Software erforderlich ist, die ich nicht besitze ... Ich könnte einen Entwickler finden, der den Job übernimmt, wenn es ein gemeinsames Interesse (Investitionen) zwischen der NetBSD Foundation und Microsoft gäbe.

Wo vermissen wir "robuste Posix-Mutexe"? Ist es Teil von .NET Core PAL?

Welches CI-System meinst du? Warum ist es an den Aufwand für den .NET Core-Port gebunden?

Wo vermissen wir "robuste Posix-Mutexe"?

Im NetBSD-Kernel (und libc/libpthread) ist dies ein Teil von CoreCLR. FreeBSD hat es in den letzten zwei Jahren entwickelt. Es könnte in der neuesten stabilen Version verfügbar sein.. aber es muss überprüft werden.

Ich möchte diese Funktion vor meinem Neustart der .NET-Portierung hinzufügen. (Es wurde auch eine winzige fehlende API für das Netzwerkrouting festgestellt.. aber ich überspringe es jetzt).

Ist es Teil von .NET Core PAL?

Ich erinnere mich jetzt nicht, ohne den Code zu überprüfen - es ist die API, die verwendet wird, um von .NET benannte robuste Mutexe (oder vielleicht Semathore) zu implementieren.

Welches CI-System meinst du?

NetBSD.

Warum ist es an den Aufwand für den .NET Core-Port gebunden?

Es war eine optionale Funktion, als ich das letzte Mal nachgesehen habe. Ich beschloss, Feature-Parität auf den Kernel-Schnittstellen und Dienstprogrammen (wie LLDB) zu erhalten. Genau mein Arbeitsstil, um einen funktionalen Baustein zu bekommen und später ein Haus zu bauen. Irgendwann werden wir es sowieso brauchen, warum also nicht in einem Rutsch entwickeln. Danke für Ihr Verständnis :)

Vielleicht können Sie einfach die freebsd-dotnet-Gruppe auf GH taggen? Er ist dort Mitglied (oder Sie können seinen Kontonamen nachschlagen). ‎Seine E-Mail ist [email protected]

[BEARBEITEN] E-Mail-Anhörungen und vorherige Antwort von @karelz löschen

@RussellHaley können Sie gerne die größere Gruppe markieren, wenn Sie dies für angemessen halten. Ich konnte Mathieus GH-Konto weder über seinen Namen noch über seine E-Mail finden, das meinte ich oben (Übrigens: Ich habe ihn direkt per E-Mail angepingt).

Ich werde mir das Taggen der Gruppe ansehen.

Hier ist Mathieus Konto. Vielleicht eine Datenschutzeinstellung?

https://github.com/mprevot

Danke schön,

Russ

Am Montag, 18. September 2017 um 13:01 Uhr, Karel Zikmund [email protected]
schrieb:

@RussellHaley https://github.com/russellhaley Fühlen Sie sich frei, die zu markieren
größere Gruppe, wenn Sie es für angemessen halten. Ich konnte Mathieus GH nicht finden
Account über seinen Namen oder E-Mail, das meinte ich oben.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/corefx/issues/1626#issuecomment-330338996 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ACENF_N6mtOo3fptvku-LUMioNpZG7coks5sjswWgaJpZM4EPG-N
.

Ich kann hier nirgendwo sehen, was erwähnt wird, aber welche niedrigste Version von FreeBSD wir hier anstreben (ich nehme an, mindestens 10 und höher, aber vielleicht auch 9)?
(Ich bin auch etwas verwirrt, welche Diskussion auf der mono @freebsd- Mailingliste stattfinden soll und was hier?)

Nun, wenn man von Fedora ausgehen sollte, wird MS nur die derzeit unterstützten Versionen unterstützen, dh 10.3 (10.4 demnächst) und 11.1.

@radovanovic FreeBSD 9 wird nicht mehr unterstützt, 10 wird EoL im April 2018, 11 im Jahr 2021. Aus meiner Erfahrung sollte es keine Probleme mit dem Kompilieren auf 11 vs 10 geben (und sogar 9 wenn du willst). FreeBSD wurde unter Berücksichtigung der Abwärtskompatibilität entwickelt.

@radovanovic Ich bin auch etwas verwirrt, welche Diskussion auf der mono@freebsd- Mailingliste stattfinden soll und was hier?

Ich habe die technischen Diskussionen, die Koordination der Arbeit und den Status hier erwartet, da dies ein breiteres Publikum ist als die mono@freebsd- Mailingliste. OTOH, wir möchten keine Unmengen von zufälligen Diskussionen zu einem Thema führen, daher könnten wir einige spezifische Designdiskussionen in separate Themen von diesem einteilen, wenn sie über eine angemessene Anzahl von Antworten hinausgehen.

Ich konnte endlich Corefx-Tests auf FreeBSD 11.0 ausführen (ohne Outerloop-Tests)
Insgesamt bestanden: 144208
Insgesamt fehlgeschlagen: 2622
Gesamt übersprungen 207

Ich werde https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD mit Anweisungen aktualisieren. Ich werde spezifische Probleme melden und sie mit os-freebsd und up-for-grab markieren.
Der Kampf in vollem Umfang kann beginnen. Freiwillige gesucht.

Und ja, ich habe den vorgeschlagenen zweiten Schritt übersprungen. Ich komme auch darauf zurück.

Mit einigen in Arbeit befindlichen Änderungen sehen die aktuellen Statistiken wie folgt aus:
Insgesamt bestanden: 238892
Insgesamt fehlgeschlagen: 58
Gesamt übersprungen 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 wurde geöffnet, um die Unterstützung für kaputte Tassen zu verfolgen.

Großer Fortschritt! NetBSD hinzuzufügen, wenn FreeBSD-Unterstützung im Baum vorhanden ist, sollte einfach sein.

@wfurt bitte E-Mail-Adresse teilen, ich werde ein paar Zeilen

Der anfängliche Support wurde zum Master-Zweig zusammengeführt. Der Build sollte wie auf der WIKI-Seite beschrieben funktionieren.
Ich mache langsam Fortschritte bei dotnet/corefx#24386, aber das sollte die meisten Benutzer nicht aufhalten.

Können wir .NET bereits auf FreeBSD booten?

Ich habe es eine Weile nicht versucht @krytarowski Es gab einen Druck, die Tools auf die Version 2.0 zu aktualisieren, und ich habe darauf gewartet, dass sich diese Bemühungen stabilisieren. Ich versuche es noch einmal und poste ein Update.

Hallo, ich bin also festgefahren, weil die von clr verwalteten Tests nicht ausgeführt werden. https://pastebin.com/B5KhtKX5

Jeder Input wäre großartig, da dies seit einiger Zeit ein Problem ist. Ich habe auch kürzlich einen Build-Fehler beim Corefx-Building unter Windows (Master, Git-Revision 749194e) festgestellt. https://pastebin.com/JXUySLTY

Ich nehme an, das ist ein zeitweiliges Problem, aber es hat mich heute Abend verlangsamt.

Wenn Sie sich den Fehler ansehen:

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

Und die beleidigende Codezeile :

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

Mein Bauchgefühl wäre, dass $maxProcesses nicht definiert ist, was zu einem unvollständigen booleschen Ausdruck führt:

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

Dies sollte einigermaßen testbar sein. Und wenn das der Fall ist, müssen Sie nur rückwärts suchen, um herauszufinden, wie Sie so gelandet sind.

Danke für Ihre Hilfe! @josteink :) Du hast https://pastebin.com/d5y9k1tw

Dadurch können die Tests ausgeführt werden, aber ich habe bei ~1000 Fehlern derselben Art aufgegeben:

FAILED - JIT/Methodical/casts/iface/_il_dbgiface2/_il_dbgiface2.sh
AUSFÜHRUNG BEGINNEN
/usr/home/russellh/Git/coreclr/bin/tests/Windows_NT.x64.Debug/Tests/coreoverlay/corerun _il_dbgiface2.exe
coreclr_initialize fehlgeschlagen - Status: 0x80004005
Erwartet: 100
Tatsächlich: 255
AUSFÜHRUNG BEENDEN - FEHLGESCHLAGEN

Okay, gemäß den sehr guten Informationen von @janvorli habe ich einen Teil meines Builds im Debug ausgeführt. Ein peinlicher Fehler beim Kopieren/Einfügen. Ich baue jetzt um.

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

Patch ist hier: https://pastebin.com/d5y9k1tw

Wenn Sie einen Patch haben, der einen defekten Build behebt, würde ich empfehlen, ihn als Pull-Request zu senden, damit er für alle behoben wird :)

Danke ich werde. Ich arbeite immer noch daran, Tests zum Laufen zu bringen, und ich war mir nicht sicher, was den nachfolgenden Fehler letzte Nacht verursacht hat.

Ich nehme an, Freebsd 11 "pkg install"-Unterstützung für Netcore 2.1 (nach der Veröffentlichung) wird nicht passieren, oder?

TLDR; Es wurde viel Arbeit geleistet, aber es muss jemand da sein, der es nach Hause fährt. Das Schreiben des Port-Makefiles ist der einfache Teil.

@wfurt konnte CLR und FX mit Linux erstellen, aber es war weitgehend ungetestet. Ich war in der Lage, die "nativen" Teile auf FreeBSD aufzubauen, aber ich habe es nicht geschafft, die verwalteten Teile auf Windows (für FreeBSD) aufzubauen. Das Ganze war ein Durcheinander beim Übertragen von Dateien zwischen den Betriebssystemen.

Separat auf der [email protected] Mailingliste hat @dragonsa eine binäre Version von Dot Net Core - 1 eingeführt und alle toolschain (msbuild, nuget usw.) von Mintos Linux - Emulation. Ich konnte seine Patches verwenden und einige der Tools ausführen, bin aber nie dazu gekommen, etwas zu bauen. Ich bin mir nicht sicher, ob diese Patches bereits festgeschrieben wurden; Ich war gerade dabei, sie zu überprüfen und wechselte den Job. Ich habe in meiner aktuellen Rolle kein DotNet und arbeite gerade an anderen Dingen.

Was bedeutet das alles? Wenn jemand die Patches von @dragonsa überprüfen kann, kann er ihnen den Ports-Tree pushen, dann ist es technisch möglich, Core 2 nativ auf FreeBSD zu bauen. Wie Sie jedoch sehen, gibt es viele kleine Teile, die zusammengebracht und organisiert werden müssen. Ich habe den Ball darauf fallen lassen, also muss ihn jemand aufheben. Ich schlage vor, auf die Mailingliste [email protected] zu springen. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html

@russellhadley Danke für die Beschreibung Russell.

Hi,

Wenn ich dies hier mit einem .NET-Entwickler bespreche, bin ich bereit, bei der Entwicklung eines FreeBSD-Ports/Pakets zu helfen.

Vollständige Offenlegung: Ich bin kein .NET-Entwickler, aber ich bin bereit, mit wem auch immer zusammenzuarbeiten, um dies in den Baum zu bringen.

~cy

@cschuber Ich war zu beschäftigt, um den aktuellen Stand der Dinge im Auge zu behalten, aber als jemand, der viele FreeBSD-Patches eingereicht und es vor etwa 3 Jahren geschafft hat, Hello World zum Laufen zu bringen, wäre es großartig, wenn wir es endlich könnten Sehen Sie, wie dieses Ding richtig gelandet wird. Du hast meine volle Unterstützung :)

@cschuber , die derzeit aktiven Ausgaben sind https://github.com/dotnet/coreclr/issues/18067. Hauptsächlich werden diese vier Funktionen links https://github.com/dotnet/corefx/issues?q=is : open + label: os-freebsd + Label : up-for-Zupacken + ist: Ausgabe, unter denen Filesystem - Beobachter scheint zu sein , die kniffligste/mühsamste https://github.com/dotnet/corefx/issues/2046.

Danke für das Angebot @cschuber. Wir sind fast an dem Punkt, an dem es möglich sein könnte.
Wir haben kürzlich mit @mateusrodrigues daran gearbeitet, .net auf FreeBSD zum Laufen zu bringen. Liste @kasper3 gesendet werden in erster Linie fehlende Funktionen. Ich denke, wir können vorerst PNSP werfen. Aus meiner Sicht sind die dringendsten Probleme dotnet/corefx#30698 und https://github.com/dotnet/coreclr/issues/18481. Es wäre toll, wenn sich jemand aus der Community damit auseinandersetzen könnte. Ich habe in letzter Zeit keine Tests durchgeführt, aber ich befürchte, dass die Zahl der Fehler gestiegen ist.
Wir sollten eine Ausgabe für jede neue versagende Gruppe eröffnen.

Ich fange auch an, den Source-Build zu reparieren, aber es liegen noch einige Herausforderungen vor uns.
c#-Compiler ist in c# geschrieben. Der aktuelle .net-Build verwendet frühere .net-Versionen, um verwaltete Assemblys zu erstellen. Es hängt auch von Paketen von Nuget ab.
Im Moment haben wir eine ausreichend gute Bootstrap-Cli, um coreclr, corefx und einige andere Repos auf FreeBSD erstellen zu können. Ich habe die Bauanleitung noch nicht aktualisiert, um 2.1-Änderungen und Source-Build widerzuspiegeln.

+1 Nur eine Anmerkung, ich bin froh, dass dies noch etwas Schwung hat. Es ist schwer, bei so vielen beweglichen Teilen zu folgen, aber es scheint, als würden die Leute Fortschritte machen. Ich habe vor einiger Zeit pkg install dotnet && dotnet build (ohne Linux-Kompatibilität).

Freue mich auch darauf

Wir haben jetzt tägliche Builds. Runtime oder SDK kann man hier bekommen: https://dotnetcli.blob.core.windows.net/dotnet/Runtime/master/dotnet-runtime-latest-freebsd-x64.tar.gz and
https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-freebsd-x64.tar.gz

Es ist auch möglich, Cross-Targeting durchzuführen, zB unter Linux oder Windows kann man dotnet publish -r freebsd-x64 und das würde eine in sich geschlossene FreeBSD-Anwendung erstellen.

Es ist noch unvollständig und wird nicht unterstützt, aber es sollte es jedem erleichtern, Beiträge zu leisten.
Es wäre toll, wenn die Leute es ausprobieren und Probleme melden könnten.
Dies wäre auch ein guter Zeitpunkt für einen letzten Vorstoß, um die Funktionslücke zu schließen und Fehler zu beheben.

cc: @mateusrodrigues

Schöne Arbeit, @wfurt und @bartonjs.

Als ich vor 2-3 Jahren meine ersten FreeBSD-Commits vorschlug, glaubte ich nicht wirklich, dass wir hier ankommen würden, aber ich wollte es auf jeden Fall versuchen.

Dies ist definitiv ein großer Meilenstein und wird es hoffentlich neuen Mitwirkenden erleichtern, die Portierung abzuschließen.

Vielen Dank an alle, die uns geholfen haben, so weit zu kommen 👍

Großer Fortschritt! Ich kämpfe immer noch mit Toolchain (die meisten LLVM-Projekte außer LLDB und LLD sind fertig) und hardwareunterstützter Virtualisierung für NetBSD (Linux/BSD startet jetzt bis zu einer fatalen VTx-Ausnahme, einfachere Betriebssysteme wie FreeDOS funktionieren bereits).. also werde ich fortfahren meine NetBSD-Portierung, hoffentlich früher als später. Bessere FreeBSD-Unterstützung hilft bei einem einfacheren Lebenslauf.

Fantastisch :)

Wir feiern Trunkenheit, warum die Silbenbomben??

@krytarowski Können Sie entwickeln, wie die 'FreeBSD-Unterstützung' besser sein kann?

Es wäre großartig, wenn ein FreeBSD-Guru einen Blick auf https://github.com/dotnet/coreclr/issues/22124 werfen könnte. Ich würde erwarten, dass Binärdateien für 11 auf 12 laufen, aber es scheint nicht der Fall zu sein ;(
Es ist leicht mit einer einfachen App zu reproduzieren und die Version 12.0 scheint etwas zu brechen, von dem Dotnet abhängt.

Hallo, ich bin kein Guru, aber wir sind in 12-RELEASE in der Lua53-Portierung auf eine Threading-Regression gestoßen.
Siehe hier für den ursprünglichen Fehler: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235158
und hier für den identifizierten Basissystemfehler :

Der Fix für Lua besteht darin, gegen -pthread zu verlinken, obwohl für -pthread von Lua NULL Anforderungen gestellt werden.

danke @RussellHaley. Das sieht nach einer vielversprechenden Spur aus.

Froh, dass ich helfen konnte. Ich würde gerne mitspielen, aber ich habe kaum die wenigen Stunden, die ich brauche, um den Hafen von Lua zu warten. Mach weiter so mit der tollen Arbeit!

Als derjenige, der die FreeBSD-Threading-Implementierung in coreclr korrigiert hat , denke ich, dass pthreads überall ziemlich konstant verwendet werden, denn das war es, was ich patchen musste, um den Build zum Laufen zu bringen.

Das heißt, es könnte darunterliegende Aber und Teile geben, die ich nie berühren musste und die "normale" Fäden verwenden ...

Vielleicht kann sich noch jemand melden, der mehr über die allgemeine Umsetzung weiß? @janvorli ?

Das behebt das Problem für mich:

[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

Ich habe keine umfangreichen Tests gemacht, aber immerhin kann ich dotnet wieder ausführen.

Ok, ich kann sehen, dass die ausführbare Dotnet-Datei nicht mit Pthreads für andere Systeme als Linux verknüpft ist.
https://github.com/dotnet/core-setup/blob/2ef0b64810530961f492c33d37fc7509128e0a9b/src/corehost/cli/exe.cmake#L59 -L61

Bedeutet das, dass die Antwort auf die Behebung dieses Problems so einfach ist, wie es sich anhört? Dh so einfach? https://github.com/josteink/core-setup/commit/25657ba2e181cce401acd7f4bf9d27a08a668470

Wenn ja, mache ich es gerne zu einer PR.

Ja, ich denke schon. Ich habe auf die Bestätigung von
Ich bin mir nicht sicher, ob wir auch "dl" brauchen, aber das kann gelöst werden, wenn Sie PR

Rechts. Mein Fehler. Also eher so: https://github.com/josteink/core-setup/commit/a08f38e25a98c25f59c8ed8c8567a0cb08b1c1c6

Ich habe dazu eine PR erstellt. Lassen Sie es mich wissen, wenn eine Änderung erforderlich ist: https://github.com/dotnet/core-setup/pull/5072

Rechts. Mein Fehler. Also eher so: josteink/ core-setup@a08f38e

Ich habe dazu eine PR erstellt. Lassen Sie es mich wissen, wenn eine Änderung erforderlich ist: dotnet/core-setup#5072

Nur zur Info, anscheinend ist dies bereits im Basissystem gepatcht: https://reviews.freebsd.org/D18988

Anscheinend ist das Hauptproblem in
Ich habe nur ein Problem, wenn ich versuche, eine eigenständige App auf FreeBSD 12.0 zu veröffentlichen.

Die offiziellen NuGet-Pakete von freebsd-x64 wurden seit .NET Core 3.0 Preview 2 entfernt und wir konnten seitdem keine Apps für FreeBSD veröffentlichen. Gibt es Pläne, sie in 3.0 wieder zu aktivieren?

Leider mussten wir die Priorität von FreeBSD aufheben (aufgrund verschiedener Gründe und Schwierigkeiten bei der End-to-End-Azure-Unterstützung) und es wird in .NET Core 3.0 keine Priorität haben.
Wir würden es gerne in dem Zustand behalten, in dem es jetzt ist, aber wir haben jetzt nicht viel Zeit, um zu investieren :(.

@karelz Vielen Dank für Ihre Antwort und ich verstehe die priorisierte Arbeit von .NET Core 3.0. Ich werde mich dann darauf konzentrieren, meine Apps mit der FreeBSD-Linux-Emulation zu starten. :)

@ hjc4869 Oder Sie können Mono versuchen. IIRC unterstützt .NET Standard 3.0

Ich habe vor, es noch einmal zu versuchen, aber wie @karelz erwähnt hat, hat es keine Priorität für 3.0

@newsash Mono ist für mich eine akzeptable Option. Ich fand es jedoch schwierig, mein Projekt mit den Monozielen zu erstellen, die zu vorhandenen .NET Core-csproj-Dateien hinzugefügt wurden.

Auf einem Linux-Computer habe ich versucht, net472 zu TargetFrameworks hinzuzufügen und die Variable FrameworkPathOverride festzulegen, aber das hat nicht gut funktioniert. Wenn ich eine API verwende, die sowohl in Mono als auch in .NET Core implementiert ist, aber nicht in .NET Framework, kann sie nicht mit Mono erstellt werden. Außerdem konnte ich, obwohl Mono .NET Standard 2.1 unterstützt, immer noch keinen Verweis auf .NET Standard 2.1-DLLs in einem net472-csproj hinzufügen.

Sollte ich ein separates csproj hinzufügen und mono msbuild verwenden, anstatt Dotnet-Tools zu verwenden, oder haben Sie Vorschläge zu dem Problem?

Nur eine kurze Bemerkung.

Da Mono bald von .NET 5 geschluckt wird, wie in der jüngsten Ankündigung [1] beschrieben, ist es dringend geboten, eine angemessene Unterstützung für FreeBSD bereitzustellen.

Mono hat sich als wirklich gute plattformübergreifende Unterstützung erwiesen und kann problemlos aus FreeBSD-Ports erstellt werden. Viele Shops führen ihre .net-Ladungen auf FreeBSD aus, da dieses Betriebssystem viele einzigartige Funktionen hat. Bisher hat mono die Lücke geschlossen, aber mit .NET 5 scheint es wahrscheinlich, dass mono in naher Zukunft mit NET 5 zusammengeführt wird und die FreeBSD-Community vollständig vom .NET-Ökosystem abgeschnitten wird.

Dotnet sollte eine ausgereifte FreeBSD-Unterstützung haben, lange bevor dies geschieht.

Ich denke, Microsoft sollte FreeBSD zu diesem Zeitpunkt offiziell unterstützen und sicherstellen, dass alle Dotnet-Tools auf dieser Plattform aufbauen.

@jasonpugsley hat Anweisungen zusammengestellt https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD und @joperator versucht, den Source-Build https://github zum Laufen zu bringen. com/dotnet/source-build/issues/1139

Wir haben die letzten ~30 Tests für Corefx fehlgeschlagen.

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 schaut sich System.Diagnostics.Tests.ProcessTests an, so dass fehlgeschlagene

Fragt sich nur, ob es dazu irgendwelche Updates gibt oder ob es aufgegeben wurde?

@elfalem , heutzutage https://github.com/dotnet/dotnet-buildtools-prereqs-docker/ , auf dem alle Prereqs installiert sind. Wir können denselben Docker-Container verwenden, um das Laufzeitpaket (im Wesentlichen ein tar.gz) lokal oder auf einem Remote-Computer zu veröffentlichen. zB können wir eine GitHub-Aktion in einem unserer Fork-Zweigs einrichten, etwa: https://github.com/am11/runtime/blob/feature/freebsd/ci/.github/workflows/main.yml , die Artefakte hochlädt zu GitHub-Releases auf Tag-Push https://github.com/am11/runtime/releases/tag/6.0.0-dev.freebsd.1. Das Archiv dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz in diesem Fall genug Bits, um einfach eine veröffentlichte Dotnet-Anwendung auszuführen (von einem anderen Linux/Mac-System, das über das Dotnet-SDK verfügt). Ich habe es getestet, indem ich eine neue 12.2 VM (Vagrant) erstellt, eine veröffentlichte App von Mac auf VM extrahiert und kopiert habe, es hat funktioniert:

#!/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!

Ich glaube, @Thefrank hat irgendwann versucht , ein richtiges FreeBSD-Ports-Paket zu erstellen.

Fragt sich nur, ob es dazu irgendwelche Updates gibt oder ob es aufgegeben wurde?

Vielleicht möchten Sie sich https://github.com/dotnet/source-build/issues/1139 ansehen
Ich habe es in letzter Zeit nicht versucht, da ich auf dotNET5 final warte, aber seit ein paar Monaten konnte die FreeBSD-Laufzeit nur als Cross-Compilierung unter Linux erstellt werden. ASPNet und SDK erforderten auch eine Linux-Cross-Compilierung, die jedoch nur erstellt wurde, wenn die Sterne ausgerichtet waren (Arcade-Updates oder ein anderer automatisierter Bot haben keine Abhängigkeit gebrochen).

edit: und @am11 hat einen besseren Spaziergang tippte. lese das und nicht meins
edit2: Satzzeichen vergessen und es sieht so aus, als ob final vor 2 Tagen veröffentlicht wurde. Ich denke, ich sollte daran arbeiten oder so

Abgesehen von all dem habe ich das FreeBSD-Projekt in https://github.com/dotnet/runtimelab/ erstellt und mache langsam Fortschritte beim Erstellen und Veröffentlichen von Paketen. Das Ziel ist es, genug zu erstellen und zu veröffentlichen, damit die App auf FreeBSD läuft und über einen Seed für den Source-Build verfügt.

Ich dachte, ich schreibe ein kurzes Update. Ich habe endlich alle Planeten ausgerichtet, um 5.0.0 RTM auf FreeBSD zu bauen. Ich hatte seit Preview3 nicht mitgehalten und es dauerte eine Weile (und _viele_ Build-Versuche), um die richtige Kombination kompatibler Builds zu finden, um ein erfolgreiches 5.0 zu erhalten.
Ich konnte PowerShell 7.1.0 mit überraschend wenigen Hacks erstellen, es funktioniert, obwohl ich es nicht gründlich getestet habe, aber es scheint ein guter Test des SDK zu sein.
Ich habe AspNetCore gerade erst gebaut, aber ich habe es noch nicht getestet.

$ 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>

Das einzige Problem beim manuellen Ausführen dieser Arbeit (dh außerhalb des CI-Systems) sind die Probleme, die durch Breaking Changes verursacht werden, die erfordern, dass ein bestimmter Build für den nächsten Build verfügbar ist. Es kommt nicht oft vor, aber es erfordert viel Ausprobieren, um den richtigen Commit zu finden. Der Linux-Cross-Build im CI-System sollte das beheben, aber ich habe mir das noch nicht angesehen. Trotzdem ist es gut zu wissen, dass ich ein komplettes SDK erstellen und dieses SDK dann verwenden kann, um etwas anderes zu erstellen.

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

Das ist ein guter Fortschritt @jasonpugsley. Ich versuche, eine bessere Antwort für den Build zu finden, aber ich konnte in den letzten Monaten keinen anständigen Teil der Zeit investieren ;(
Hat Ihnen PowerShell wegen Termininfo Ärger bereitet oder haben Sie die Terminaldefinition von woanders kopiert?

Ich habe mir die Terminaldefinition von meinem Mac geholt, von dem aus ich ssh'd wurde.

@jasonpugsley du bist mir weit voraus. core und sdk bauen von linux cross freebsd. laufen gut von den begrenzten Tests, die ich getan habe. Weder Runtime- noch SDK-Crossbuilds können selbst auf Freebsd bauen (Linux und Freebsd verwenden llvm9 und clang9).
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0
Ich werde mich ein bisschen mehr damit beschäftigen, wenn ich dieses Wochenende mehr Zeit habe und auch sehen, ob ich zumindest aspnetcore auf Linux für Freebsd bauen kann

@Thefrank , meinst du:

$ 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

schlägt fehl oder die Binärdateien in artifacts/packages/Release/Shipping/dotnet-runtime-5.0.0-dev-freebsd-x64.tar.gz nicht ausgeführt werden?
Wenn Sie versuchen, SDK 5x unter Ubuntu 18 oder 20 zu kompilieren, sollten Sie diesen Patch https://github.com/dotnet/sdk/commit/80e42f16422352f725d78be72071781d8365a238 (er befindet sich im Master-Zweig) anwenden.

Ich muss wirklich aufhören, im Halbschlaf zu posten.
Die Erstellung der Laufzeit und des SDK ist unter Linux abgeschlossen.
Diese Binärdateien laufen auf freebsd (dotnet --info, new console und run)
Diese Binärdateien können keine Laufzeit oder SDK aus dem Quellcode auf freebsd erstellen

Ah okay. Ich habe nicht versucht, die Stage0-Binärdateien zu füttern, um die Laufzeit auf FreeBSD als HostOS neu zu erstellen.

ld: Fehler: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim. exports:1 : unbekannte Direktive: V1.0

Es könnte sich lohnen, dieses Problem separat zu melden. Wahrscheinlich gibt es mehrere Möglichkeiten, das Problem zu beheben, aber macht dieser Patch einen Unterschied:

--- 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)

macht dieser Patch einen Unterschied?

Ich würde erwarten, dass FreeBSD Linux in Bezug auf Symbolversionsskripte folgt, nicht Darwin. IMO ist es wahrscheinlicher, dass das Problem darin besteht, dass in generateversionscript.awk etwas GNU-awk-spezifisch ist

Patch hat den Fehler geändert:
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: _CreateProcessForLaunch
wenn awk-Versionsproblem:

awk --version
awk version 20121220 (FreeBSD)

Wenn es einfach zu experimentieren ist, können Sie versuchen, das gawk-Paket zu installieren und den Aufruf in den CMake-Dateien in gawk zu ändern?

hat den Patch zurückgesetzt. installiert gawk pkg.
zu faul, um herauszufinden, wie das build.sh-Skript cmake-Args übergibt, da es nicht sofort Sinn macht, also habe ich einfach gawk->awk symbolisiert.
gleicher ursprünglicher Fehler
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0

späte Bearbeitung: Es sieht so aus, als ob die Binärdateien unter Linux nicht richtig erstellt wurden:

# ./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

hauptsächlich die RID: osx-x64 könnten einige Probleme verursachen

hauptsächlich die RID: osx-x64 könnten einige Probleme verursachen

Diese RID wird vom SDK nach einigen Auflösungen von unterstützten und nicht unterstützten Plattformen angezeigt. Sie hat grundsätzlich keine Auswirkung auf die Ausführung der Anwendung. Die von der Laufzeit erkannte echte RID ist korrekt, andernfalls werden Anwendungen (wie dotnet(1) ) nicht ordnungsgemäß ausgeführt.
c# using System; using System.Runtime.InteropServices; class Program { static void Main() => Console.WriteLine("Real RID: {0}", RuntimeInformation.RuntimeIdentifier); }
druckt Real RID: freebsd.12-x64 auf meine Box.

Geöffnet #45663, um das ld-Problem zu verfolgen. konnte ich auch reproduzieren.

@Thefrank bezüglich des ld-Fehlers, versuchen Sie

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)

Dadurch wird die else Klausel in eng/native/functions.cmake hier aktiviert:

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()

Um ganz ehrlich zu sein, ich bin kein Linker-Experte, also habe ich, während dies funktioniert, nicht genauer nachgesehen, was für Clang auf FreeBSD tatsächlich erforderlich/kanonisch ist.

Ahh, das Linker-User-Agent-Problem schlägt wieder zu. Die Versionszeichenfolge von LLD enthält (compatible with GNU linkers) in einem Versuch, den GNU ld-Pfad der Konfigurationstests zu durchlaufen, aber für diesen Fall eindeutig nicht schlau genug :)

Matching auf LLD sieht hier gut aus, auch wenn das LD_GNU Flag jetzt etwas falsch benannt ist.

Ja, es braucht mehr Arbeit. Der Flaggenname ist jetzt verwirrend. Bitte versuchen Sie nicht, dies so zu begehen, wie es ist.

Von: Ed Maste [email protected]
Gesendet: Montag, 7. Dezember 2020 10:26:48
An: dotnet/runtime [email protected]
CC : Jason Pugsley Sie Erwä[email protected]
Betreff: Re: [dotnet/runtime] Unterstützung für FreeBSD (#14537)

Ahh, das Linker-User-Agent-Problem schlägt wieder zu. Die Versionszeichenfolge von LLD enthält (kompatibel mit GNU-Linkern) in dem Versuch, den GNU ld-Pfad der Konfigurationstests zu durchlaufen, aber für diesen Fall eindeutig nicht schlau genug :)

Das Abgleichen auf LLD sieht hier gut aus, auch wenn das LD_GNU-Flag jetzt etwas falsch benannt ist.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/dotnet/runtime/issues/14537#issuecomment-739583816 an oder melden Sie sich ab https://github.com/notifications/unsubscribe-auth/AECFDEXKTDFRAX4ZEE6VXZTSTQHLRANCNFSM4TS3XPPA .

Ich habe mich für https://github.com/dotnet/runtime/pull/45664 entschieden
Clr baut auf Clr.Tools-Teilmenge auf und schlägt dann fehl mit

/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]

Teilmenge "mono" und Teilmenge "libs" komplett ohne Fehler

@Thefrank Es ist der zweite Teil dieses

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>

Es könnte besser als ODER in der Bedingung in die LINUX-Zeile eingefügt werden.

@jasonpugsley , das hat es geschafft!
/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):
Ich wusste, dass ich vor ein paar Tagen etwas vergessen habe! Das sollte interessant sein

Edit: ohne Crossgen (auch bekannt als nur zweite Hälfte)

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

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

Time Elapsed 00:12:05.56

Letzte Änderung dieses Beitrags bearbeiten Ich schwöre:
Ich weiß, dass Tests eine Weile dauern können und es heißt ein langer Test, aber das gerät für einen Test außer Kontrolle
System.Net.HttpListener.Tests: [Long Running Test] 'System.Net.Tests.HttpListenerResponseTests.AddLongHeader_DoesNotThrow', Elapsed: 00:36:20

beendete den Test, nachdem er 2 Stunden gewartet hatte, andere Tests hatten immer noch Fehler

/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').