Runtime: Prise en charge de FreeBSD

Il semble y avoir un accord en ce qui concerne https://github.com/dotnet/corefx/issues/1576 .

Lorsque nous aurons également une décision sur https://github.com/dotnet/corefx/issues/1625, nous devrions pouvoir commencer à envoyer du code.

Un accord sur dotnet/runtime#14536 a été atteint par l'équipe de port, à moins que MSFT n'en décide autrement, ce sera FreeBSD . Le problème dotnet/corefx#1999 sera potentiellement le problème qui introduit la définition dans l'API publique.

Un accord sur dotnet/runtime#14536 a été atteint par l'équipe de portage, à moins que MSFT n'en décide autrement, ce sera FreeBSD

Si j'ai bien lu, cela signifie que lorsque https://github.com/dotnet/corefx/pull/1999 est fusionné, nous pouvons considérer cette approbation MSFT de la nouvelle API publique, et pouvons donc avancer sur les problèmes restants avec des pull-requests régulières sans besoin d'approbation MSFT.

Si c'est le cas, ça me semble bien.

Les prochaines étapes selon https://github.com/dotnet/corefx/pull/1999#issuecomment -111279577 sont :

1. L'"équipe de portage FreeBSD" poursuit son travail pour obtenir une version FreeBSD de CoreFX produite (suivie par dotnet/corefx#1626).
2. L'équipe de portage apporte suffisamment de pile CoreFX et CoreCLR sur FreeBSD pour que nous puissions commencer à exécuter les tests unitaires CoreFX sur FreeBSD.
3. Les tests atteignent un niveau de qualité minimal. Je ne sais pas encore exactement à quoi cela ressemble, mais je pense que cela signifie quelque chose comme la majorité des tests réussis. Idéalement, nous n'aurions pas un tas de tests spécifiques désactivés pour FreeBSD uniquement (par rapport à Linux et OSX, nous ne voudrions pas maintenir FreeBSD à un niveau plus élevé que les autres plates-formes *NIX que nous avons là-bas).
4. En collaboration avec l'équipe de portage FreeBSD, l'équipe CoreFX obtient les tests CoreFX ajoutés à notre système CI fonctionnant sur FreeBSD.
5. Discutez de la fusion d'un PR basé sur le problème dotnet/runtime#14536, qui ajoute la propriété.

Cela me semble un plan tout à fait raisonnable.

D'accord, alors commençons le travail pour faire fonctionner corefx.

Le premier obstacle à la construction de corefx sur FreeBSD semble être mono. Le script de construction insiste sur le fait que la version 4.1 est requise. @ajensenwaud a travaillé là-dessus sur l'hôte de Francfort, mais je ne sais pas à quel point il est complet.

Je vais mettre en file d'attente une version pour le moment et voir à quoi ressemble la sortie.

Edit : Le build (mono) plante avec le kicker suivant à la fin :

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.

Le premier obstacle à la construction de corefx sur FreeBSD semble être mono

FWIW, personnellement, je ne pense pas que ce soit le premier obstacle. Il y a deux problèmes liés à la construction :

1. Construire des assemblys qui fonctionnent correctement sur FreeBSD
2. Construire ces assemblys sur FreeBSD

(1) est critique, et je crois que ce problème est censé être. (2) est très agréable à avoir, mais son absence n'empêche pas la création d'un excellent système pour exécuter du code managé sur FreeBSD.

Vous êtes bien sûr libre de définir vos priorités comme bon vous semble, mais ma recommandation serait de vous concentrer sur (1) plutôt que sur (2).

Notez que nous avons toujours des problèmes pour construire corefx sur Linux et le construire sur OSX, de sorte que notre système CI construit les assemblys pour ces plates-formes sur Windows ; il transfère ensuite les assemblages résultants vers la plate-forme cible pour exécuter les tests.

C'est assez juste. J'ai juste supposé qu'il serait plus facile d'intégrer le support général de la plate-forme FreeBSD dans corefx si nous pouvions le construire nous-mêmes sur FreeBSD.

Je vais me contenter de la construction initiée par Windows pour le moment et essayer de ninja ensemble une configuration de construction.

@josteink d' ailleurs. corefx devrait maintenant s'appuyer sur Mono 4.0.1.44.

@akoeplinger Nice. Cela me laisse un peu d'espoir que nous pourrons également le faire fonctionner sur FreeBSD :)

Bons points. Cependant, si nous voulons vraiment que corefx fasse partie de l'environnement FreeBSD, nous avons vraiment besoin qu'il soit capable de compiler à partir des sources pour l'intégrer au système de ports.

J'ai entendu dire que Mono 4.0.1.44 résout beaucoup de ces problèmes, mais je n'ai pas encore eu le temps de jouer avec. Je sais que l'équipe des ports met à jour le Makefile du port et nous parlons d'un nouveau patch.

Le 12 juin 2015, à 20h21, Stephen Toub [email protected] a écrit :

Le premier obstacle à la construction de corefx sur FreeBSD semble être mono

FWIW, personnellement, je ne pense pas que ce soit le premier obstacle. Il y a deux problèmes liés à la construction :

Construire des assemblys qui fonctionnent correctement sur FreeBSD
Construire ces assemblys sur FreeBSD
(1) est critique, et je crois que ce problème est censé être. (2) est très agréable à avoir, mais son absence n'empêche pas la création d'un excellent système pour exécuter du code managé sur FreeBSD.

Vous êtes bien sûr libre de définir vos priorités comme bon vous semble, mais ma recommandation serait de vous concentrer sur (1) plutôt que sur (2).

Notez que nous avons à peine corefx build-on-Linux et build-on-OSX, de sorte que notre système CI construit les assemblys pour ces plates-formes sur Windows ; il transfère ensuite les assemblages résultants vers la plate-forme cible pour exécuter les tests.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Oui, je ne suis en aucun cas en désaccord... être capable de _build_ corefx sur Linux, OSX et FreeBSD est important. Je suggère simplement que d'un point de vue prioritaire, il est plus important de pouvoir réellement _exécuter_ corefx sur Linux, OSX et FreeBSD. :wink: Si les deux peuvent être travaillés en parallèle, tant mieux.

@ghuntley ,
ce serait super :cool: si nous avions une liste de contrôle des tâches de démarque décrivant ce qui reste :

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

rend comme :

• [ ] tache 1
• [ ] tâche 2
• [ ] tâche 3

Cela encouragera probablement les autres à réaliser ces exploits et le support de FreeBSD arrivera un peu plus tôt que prévu ! :des lunettes de soleil:

À ma connaissance, les travaux suivants dans CoreFX sont requis pour le support de FreeBSD :

• [x] Présentez la plate-forme FreeBSD aux outils de construction et aux scripts. (Fait par @josteink et moi, PRs dotnet/corefx#2021 fusionné, dotnet/corefx#2030 fusionné)

13 Les assemblys ne se compilent pas tout seuls et nécessitent des modifications spécifiques à FreeBSD. Principalement les éléments Interop qui existent déjà pour Linux/OS X (ordre par occurrence dans la sortie de build) :

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

Je vais essayer de mettre à jour cette liste en fonction des PR ouverts et fusionnés.

Pour info : PR dotnet/corefx#2039 fusionné

J'essaie juste d'avoir une longueur d'avance ici... Comment prévoyons-nous d'implémenter System.IO.FileSystem.Watcher ?

Iirc FreeBSD n'a pas de inotify comme Linux et Windows (c'est aussi pourquoi il n'y a pas de Dropbox la dernière fois que j'ai vérifié). Sera-ce une source potentielle de problèmes à venir? Ou quelqu'un a-t-il une idée de la façon de contourner cela?

Je suggère que nous supprimions cela pour le moment et lancions une exception PlatformNotSupportedException comme Stephen Toub l'a suggéré dans l'autre sujet (https://github.com/dotnet/corefx/pull/2021#issuecomment-111602342). Ensuite, nous avons au moins un ensemble complet d'assemblages et nous pouvons continuer à travailler sur ce problème particulier sans bloquer d'autres étapes.

Est-ce que ça vous dérangerait d'ouvrir un sujet séparé pour ça ?

Déplaçons les discussions System.IO.FileSystem.Watcher vers dotnet/corefx#2046

Les gars, existe-t-il un tel bloqueur pour System.Diagnostics.Process ?

@jasonwilliams200OK a ajouté FreeBSD à S.RT.I.RI tôt ce matin, qui a été fusionné, mais les tests FreeBSD dans CheckPlatformTests ont dû être annulés jusqu'à ce que dotnet/buildtools soit mis à jour.

• [ ] Mettre à jour les outils de construction pour prendre en charge FreeBSD - https://github.com/dotnet/buildtools/pull/180
• [ ] Réappliquez les tests [Fact,PlatformSpecific(PlatformID.FreeBSD)] à CheckPlatformTests - voir https://github.com/dotnet/corefx/pull/2068#discussion_r32570244 et https://github.com/dotnet/corefx/pull/2068#discussion_r32570244
• [ ] Ajoutez public static OSPlatform FreeBSD à https://github.com/dotnet/corefx/pull/2068

@jasonwilliams200OK, il y a eu des discussions hier soir sur System.Diagnostics.Process en gitter qui ont été formalisées en https://github.com/dotnet/corefx/issues/2070

@ghuntley , merci. En fait, j'ai lu ces messages. System.Diagnostics.Process est délicat. AFAIK, l'équipe io.js a rencontré des défis similaires avec la gestion des processus FreeBSD. L'équipe Mono a probablement réussi , alors espérons que

System.IO.FileSystem.DriveInfo

Comme discuté dans le gitter, pour celui-ci, j'ai essayé d'examiner l'utilisation de base de 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);
  }
}

L'exécution de cet exemple a donné cette sortie :

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

Il semble donc qu'il fasse ce dont nous avons besoin. La question est, devons-nous faire n'importe quel type de filtrage sur les résultats ?

En regardant "l'intention" de l'objet DriveInfo , venant du monde Windows de .NET, il a souvent été d'énumérer les emplacements disponibles pour stocker ou récupérer des fichiers ( C: , D: , etc.). Mais lors de l'utilisation de systèmes de fichiers hiérarchiques Unix, le retour de / serait suffisant pour couvrir ces besoins.

Alors que devons-nous retourner? Qu'est-ce qui serait utile ? Faut-il même considérer que c'est utile ou non ?

La version Linux ne fait que tout vider, sauf les éléments à ignorer :

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

J'ai essayé de mettre le filtre suivant, mais cela n'a vraiment rien changé en termes de sortie :

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

Des avis ?

@josteink , bonnes fouilles ! Sur la base de https://github.com/dotnet/corefx/issues/815#issuecomment -113825960 et https://github.com/dotnet/corefx/issues/1729 , je pense que nous devrions collaborer avec @sokket pour trouver une solution qui fonctionne sur différents Unices.

J'ai une version fonctionnant sur OSX qui utilise getmntinfo et statfs pour obtenir des informations sur chaque point de montage, ce qui semble être le mappage le plus logique du concept Windows Drive. Je vais vérifier que les définitions de fonction et de structure sur OSX correspondent aux définitions de FreeBSD et, si c'est le cas, mon commit pour OSX fonctionnera également pour BSD.

Je ne manquerai pas de vous ajouter à mon PR @josteink

Ça a l'air bien. Merci pour l'avertissement et merci d'avoir donné de l'amour à FreeBSD aussi.

J'ai examiné quelques pinvoke de base pour ces fonctions, et il semble que nous devions faire tout le triage et les conversions nous-mêmes, donc si quelqu'un d'autre a déjà fait l'effort, qui suis-je pour dire non ? ;)

Pas de problème... il semble que la principale différence concerne les déclarations de structure ; puisque nous allons probablement toucher cela plus à l'avenir, je fais une refactorisation qui nous permettra de partager beaucoup de signatures PInvoke. J'ajouterai une description plus détaillée dans mon PR (aujourd'hui ou demain, en fonction du déroulement du test), mais j'ai essentiellement ajouté les signatures PInvoke et les signatures struct pour FreeBSD (basées sur les en-têtes que j'ai trouvés en ligne) et cela se compile. Je l'ai testé sur Mac donc il _devrait_ (en théorie...) fonctionner sur FreeBSD car il ne s'agit que d'un changement de déclaration de structure, mais votre kilométrage peut varier :). Si ce n'est pas le cas, vous aurez la classe DriveInfo et PInvokes à 99% du chemin et vous aurez juste besoin de quelques ajustements basés sur les nuances de FreeBSD.

Excellente nouvelle @sokket. Je vous ai créé un compte sur la machine que l'équipe de portage utilise pour le développement, elle est basée en Europe mais elle est toujours allumée et a beaucoup de mémoire et de puissance de traitement. Espérons que cela aidera et éliminera une partie des frictions lorsque vous travaillez avec FreeBSD.

# ssh [email protected]

L'authentification par mot de passe est désactivée, utilisez l' une de vos clés .

@josteink voir aussi le problème : https://github.com/dotnet/corefx/issues/815 (System.IO.FileSystem.DriveInfo pour Mac/FreeBSD)

Y a-t-il des mises à jour ? Est-ce que quelqu'un a implémenté les assemblys restants sur FreeBSD ?

J'ai été occupé à m'occuper de mon nouveau bébé, je n'ai eu le temps de coder nulle part.

J'ai soupçonné que des problèmes comme ceux-ci étaient en sommeil et je suppose que cela le confirme dans une certaine mesure.

Pour les assemblys qui ne sont toujours pas implémentés, j'ai lié le problème "comment implémenter" dans la liste ci-dessus. J'espère que cela aide à coordonner les efforts pour mettre en œuvre ces assemblages restants.

Je dois admettre que j'avais des difficultés à garder une trace de ce que nous avons fait et où, donc c'est certainement une bonne chose. Bon travail :)

Où puis-je trouver ça ? Serait grat d'obtenir les assemblages restants
mis en œuvre.

Le 25/07/15 22h10, Jan Henke a écrit :

Pour les assemblages qui ne sont toujours pas implémentés, j'ai lié le "comment
à mettre en œuvre"-problème dans la liste ci-dessus. J'espère que cela aide à coordonner
l'effort pour obtenir ces assemblages restants mis en œuvre.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment-124838781 .

Ce commentaire ici : https://github.com/dotnet/corefx/issues/1626#issuecomment -111800540

J'attends maintenant que les cales natives soient terminées, car elles devraient prendre en charge la plupart du travail pour faire fonctionner ces assemblages sur FreeBSD.

@nguerrera serait super si vous pouviez nous tenir au courant des progrès. :)

Mettre à jour:
@janhenke a confirmé qu'avec https://github.com/dotnet/corefx/pull/2974 fusionné, System.IO.Pipes s'appuie sur FreeBSD ! :des lunettes de soleil:

Mettre à jour:
dotnet/corefx#2527 fermé, System.IO.MemoryMappedFiles construit sur FreeBSD.
Merci @janhenke pour la confirmation !

Grâce à l'approche des shims, il suffit de s'assurer que les shims se compilent sur FreeBSD. Heureusement, cela rend la vie beaucoup plus facile. :)

dotnet/corefx#3257 devrait nous apporter à la fois System.Diagnostic.Process et System.IO.FileSystem.Watcher laissant juste System.Net.NameResolution non résolus. (Je vérifierai les deux assemblages mentionnés une fois que le PR sera fusionné et fonctionnera sur FreeBSD)

dotnet/corefx#3471 devrait nous rapporter System.Net.NameResolution et compléter la liste ci-dessus.

dotnet/corefx#3471 vient d'être fusionné :)

@sokket , merci pour la mise à jour. J'ai construit master (f467911) sur FreeBSD en utilisant ce guide : https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24. Le bloqueur actuel est https://github.com/dotnet/buildtools/issues/292, qui est corrigé en amont mais en attente du prochain déploiement des outils de construction. :)

Mise à jour : de nouveaux outils de construction avec correctif pour dotnet/buildtools#292 ont atterri dans CoreFX master. Le prochain bouchon de buildtools est https://github.com/dotnet/buildtools/issues/300 : outil spécifique au système d'exploitation manquant pour pouvoir exécuter les tests.

@janhenke , vous avez marqué System.Diagnostics.Process (#2070) et System.IO.FileSystem.Watcher (#2046) comme terminé ; mais ils ne sont ni implémentés ni compilés sur FreeBSD. Avez-vous réellement vérifié la liste en compilant le code managé ?

D'après mon expérience récente avec commit 60c78da3c918b0d256cc1f878de06d351dbe3342 (voir msbuild.log ), les assemblys suivants ne se compilent pas :

• Processus.de.diagnostic.système
• System.Diagnostics.ProcessManager
• System.Diagnostics.ThreadInfo
• System.IO.FileSystemWatcher
• System.Net.SocketAddress _(d'accord, celui-ci a été ajouté récemment)_

Pour autant que je me souvienne, j'ai vérifié la compilation des cales associées. Étant donné que le code managé doit être exempt de code spécifique à FreeBSD. Ces cales que vous mentionnez auraient dû être calées avec les PR liés ci-dessus.
Mais j'ai également exécuté une compilation complète entre les deux. Au moins System.Diagnostics.ThreadInfo et System.IO.FileSystemWatcher ont été compilés. Donc quelque chose a dû régresser.

Ces cales que vous mentionnez auraient dû être calées avec les PR liés ci-dessus.

En fait, PR https://github.com/dotnet/corefx/pull/3257 n'est pas lié à la cale. Il y a encore du code PAL dans les projets managés (l'ancienne approche), il est donc nécessaire de construire des assemblys managés pour être absolument sûr.

En fait, PR dotnet/corefx#3257 n'est pas lié à shim.

Je ne suis pas d'accord. Il refactorise le code P/Invoke vers le shim System.Native. De plus, comme je l'ai édité ci-dessus, je rappelle au moins certains des assemblages compilés entre les deux.

je ne suis pas d'accord

https://github.com/dotnet/corefx/pull/3257/files : voir les instances de .Unix.cs et .Linux.cs pour System.Diagnostics. . Notez que .OSX.cs n'est pas modifié.

Il refactorise le code P/Invoke vers le shim System.Native

Oui, il refactorise certaines aides courantes sous System.Native , mais pas System.Diagnostics.* et al.

Même lorsque ces assemblys ne sont que des P/Invoking vers les bibliothèques System.*, il peut encore y avoir du travail FreeBSD requis pour certains d'entre eux, par exemple System.Diagnostics.Process et System.IO.FileSystem.Watcher. Ils utilisent des fonctionnalités spécifiques à Linux et OS X, et nous ne prévoyons pas d'essayer d'abstraire cela derrière des shims natifs. Le but des shims n'est pas de se retrouver avec un seul binaire géré pour Unix, bien que ce soit une très belle propriété quand elle vient du travail ; l'objectif principal est d'éviter les différences d'ABI qui causent la fragilité. Je m'attends à ce qu'au moins une poignée d'assemblys continueront à avoir des binaires spécifiques à Linux/OS X, où un binaire FreeBSD serait également nécessaire.

Pour info, il n'y a pas d'assembly corefx nommé System.Diagnostics.ProcessManager,
System.Diagnostics.ThreadInfo,
System.IO.FileSystemWatcher, ou
System.Net.SocketAddress. Ce sont des types dans d'autres assemblages.

Je m'attends à ce qu'au moins une poignée d'assemblys continueront à avoir des binaires spécifiques à Linux/OS X, où un binaire FreeBSD serait également nécessaire.

Cela signifie-t-il que chaque fois que Solaris et non-glibc (musl et μlibc) ciblant Linux comme les supports Alpine arriveront, ils auront des binaires séparés ? Et puis des architectures différentes ARM, MIPS, RISC, SPARC etc. nécessiteraient un autre niveau de séparation ?

Ne serait-il pas logique de les faire converger vers l'interface POSIX / les appels système autant que possible et de détecter les différences à l'aide de configurations (via CMake) à utiliser dans le même binaire (à moins que cela n'affecte la taille / les performances du assemblées de manière significative) ? Si j'ai bien compris, le binaire System.Native.so a une aide commune pour d'autres System.*.Native.so spécifiques, ce qui semble suffisant pour le respect du principe de séparation des préoccupations. Mais s'il est transformé en System.Net.Http.FreeBSD.ARM.Native.so ou System.Net.Http.Solaris.SPARC.so , alors il sera assez ingérable avec "trop ​​de pièces mobiles", etc.

il n'y a pas d'assembly corefx nommé

Bon point. En fait, je parcourais les instances d'échec dans les journaux msbuild et le nombre de fichiers .OSX.cs et .Linux.cs . :le sourire:

Ne serait-il pas logique de les faire converger vers l'interface POSIX / les appels système autant que possible

Nous faisons. Comment proposez-vous de bien regarder les fichiers via POSIX ? Comment proposez-vous de bien traiter le dénombrement via POSIX ?

Mais s'il est transformé en System.Net.Http.FreeBSD.ARM.Native.so ou System.Net.Http.Solaris.SPARC.so, alors il sera assez ingérable avec "trop ​​de pièces mobiles", etc.

Je ne comprends pas cela. L'intérêt des fichiers .so natifs est que vous obtenez des binaires natifs différents pour chaque plate-forme cible, mais ils ne s'appellent pas System.Whatever.Platform.ext, juste System.Whatever.ext ; qui permet au compilateur de prendre la même logique générale et de l'utiliser avec les définitions spécifiques à cette plate-forme. Cela ne fonctionne que lorsque les mêmes symboles existent sur chaque plate-forme ; le compilateur ne prend pas comme par magie le code écrit pour utiliser inotify et lui permet de fonctionner avec l'interface de surveillance de fichiers d'un autre système. En général, nous nous sommes efforcés d'utiliser des API standardisées là où cela a du sens, mais pour les endroits où de telles API n'existent pas ou ne sont pas bien standardisées ou où il existe de meilleures solutions spécifiques à la plate-forme, nous avons utilisé la meilleure plate-forme. des solutions spécifiques, par exemple l'utilisation de procfs pour l'énumération des processus sur Linux, l'utilisation d'inotify pour la surveillance du système de fichiers sur Linux, etc. Qu'une telle logique spécifique à la plate-forme vive dans du code managé ou natif n'a pas vraiment d'importance d'une facilité de portage vers perspective des plates-formes supplémentaires, comme lorsque ces nouvelles plates-formes arrivent, si les API existantes fonctionnent, la solution existante fonctionne également, et si ce n'est pas le cas, vous devez écrire une nouvelle solution pour cette plate-forme. Et donc nous avons essayé de faire autant que possible dans le code managé, en utilisant natif simplement pour les cales 1:1 qui rendent ce code managé beaucoup plus portable là où les API cibles sont portables. Nous avons utilisé #ifdefs dans le code natif pour dissimuler de petits détails, où cette API sur quelle plate-forme est assez proche de cette API sur une autre plate-forme, mais cela ne s'étend pas à des solutions entières qui sont complètement différentes ; à ce stade, l'abstraction devient l'API gérée et nous effectuons une implémentation gérée différente pour chaque système.

Si FreeBSD expose inotify comme le fait Linux ou s'il expose EventStream comme le fait OS X, alors lorsque ces API OS sont derrière le shim, le shim peut facilement fonctionner avec FreeBSD, et le même binaire géré peut être utilisé sur FreeBSD. Si FreeBSD n'expose pas de telles API, vous devrez alors écrire une implémentation personnalisée de System.IO.FileSystem.Watcher avec une solution de surveillance de fichiers disponible sur FreeBSD. Commentaires similaires pour System.Diagnostics.Process. Que le code pour la surveillance du fichier soit dans la cale ou non a peu d'impact sur cela.

Le plan est que toutes ces API natives soient éventuellement déplacées derrière la cale. Mais ils sont loin d'être une priorité, car ils ne sont pas très portables, et vous nous avez donc vu commencer avec des API de libc qui sont (ou sont censées être) exposées partout.

Comment proposez-vous de bien regarder les fichiers via POSIX ?

Nous ne pouvons pas tout faire POSIX, car inotify est spécifique à Linux. FreeBSD/OSX propose des implémentations séparées.

Proposition:

Du point de vue de la distribution des binaires natifs, chaque système d'exploitation doit recevoir un ensemble égal de binaires avec les mêmes noms, mais des fonctionnalités différentes.

Voici une proposition de structure :

# 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

C'est essentiellement ce que nous avons, par exemple

• "common_function_for_posix_compliances" sont des fonctions 1:1 nativement calées consommées à partir de la logique dans un binaire géré Unix partagé
• "slightly_diverged_function" sont des fonctions nativement calées presque 1:1 avec quelques #ifdefs natifs consommés à partir de la logique dans un binaire géré Unix partagé
• "painfully_diverged_watch_function" sont / seront des fonctions 1:1 nativement calées consommées à partir de la logique dans les binaires gérés spécifiques à la plate-forme

La vraie différence est de savoir si le code implémentant la logique "douloureusement divergente" est fait en C# ou C++, et nous avons choisi C# et tout est déjà implémenté en C#. Je n'ai vu aucun argument convaincant expliquant pourquoi, dans de tels cas, réécrire tout en C++ serait une option beaucoup plus convaincante.

@ jasonwilliams200OK Avec la mise à jour d'aujourd'hui en mono, je reconstruis corefx sur FreeBSD lui-même. Il y a beaucoup de nouveaux messages d'erreur depuis la dernière fois que je l'ai construit.
Je me demande si Interop.Libc finira par disparaître ?

@stephentoub Tout se résume à l'emballage. Avoir tout le code spécifique à la plate-forme dans la partie native a l'avantage d'avoir un assembly géré pour toutes les plates-formes de type Unix.
En outre, je pense fortement que nous avons besoin d'une implémentation générique pour ces "codes managés dépendant de la plate-forme. Même s'il ne fait que lancer une NotImplementedExcpetion. De cette façon, vous pouvez beaucoup plus facilement porter sur de nouvelles plates-formes, s'il compile au moins tout immédiatement. Cela donnerait également la chance d'essayer au moins de fonctionner sur une plate-forme non prise en charge.
En général, c'est beaucoup plus facile si vous pouvez au moins compiler avec succès tout de suite.

@stephentoub , désolé je mélangeais C++ avec C#. Maintenant, je comprends que la couche native expose simplement ces points d'entrée (fonctions de bibliothèques natives ou appels système) et que la désinfection des E/S et du code managé est l'endroit où nous décidons de la méthode utilitaire enveloppée spécifique à la plate-forme / de l'appel système enveloppé à utiliser. En outre, les deux niveaux (natifs et gérés) ne peuvent pas être indépendants du système d'exploitation où des fonctionnalités non POSIX doivent être consommées.

@janhenke , je suis d'accord. Je suis aussi maître du bâtiment au moment où nous parlons. Il y a un autre problème récurrent de signature d'assembly, je frappe:

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]

publiera sous peu le lien complet msbuild.log.

En outre, je pense fortement que nous avons besoin d'une implémentation générique pour ces "code managé dépendant de la plate-forme.

Je suis d'accord. Au lieu de classes partielles, nous pouvons probablement utiliser l'héritage avec des méthodes virtuelles communes et pour la plupart communes dans une classe de base abstraite et surcharger pour "principalement commun / partiellement différent" si nécessaire. Implémentez ensuite des méthodes abstraites totalement différentes pour chaque système d'exploitation. Avec cette approche IMO, si là où la spécialisation/généralisation perd DRY'ing, nous pouvons employer l'ascendance d'héritage multi-degrés. Mais la dernière fois que j'ai vérifié, les classes partielles étaient préférées à l'association parent-enfant dans CoreFX (pour une raison dont je ne me souviens pas). :)

Voici le msbuild.log pour le commit 2d36889 :

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

/cc: @akoeplinger

@ jasonwilliams200OK Pourquoi si compliqué. Tout ce dont il a besoin est une condition "sinon Windows,Linux,OS X" dans les fichiers du projet. Donc, incluez soit un ensemble de fichiers spécifiques à la plate-forme dans la construction, soit des fichiers génériques.

Je ne pense pas que le fait que certains assemblys ne puissent pas encore compiler/fonctionner pour FreeBSD devrait être un obstacle majeur pour tester le reste d'entre eux. Nous devrions probablement faire en sorte que ceux dont le travail est en attente (FileSystemWatcher, Process, Networking) soient ignorés dans la construction et le test sur FreeBSD. Ensuite, nous pouvons les aborder individuellement tout en ayant un processus pour empêcher la régression de ce qui fonctionne déjà.

Je ne pense pas que le fait que certains assemblys ne puissent pas encore compiler/fonctionner pour FreeBSD devrait être un obstacle majeur pour tester le reste d'entre eux

D'accord

Nous devrions probablement faire en sorte que ceux avec un travail en attente (FileSystemWatcher, Process, Networking) soient ignorés dans la construction et le test sur FreeBSD

Ou similaire à ce que @janhenke a suggéré, permettez-leur simplement de construire, soit en supprimant avec des fichiers qui lancent PlatformNotSupported, soit simplement en mappant FreeBSD à l'un des cas qui fonctionnent, par exemple si FreeBSD est choisi, construisez simplement celui de Linux ( ça ne fonctionnera pas, mais ça va construire).

Avec les modifications récentes de @ellismg (#3684), je suis capable d'exécuter des tests en simplifiant la méthode précédente (https://github.com/dotnet/coreclr/issues/1633#issuecomment-143669303) :

• Après https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 (en particulier l'étape pour construire les cales natives séparément _après_ la sortie build.sh avec le statut 1), téléchargez le zip des artefacts CoreCLR : cd /root; curl -o bins.zip "http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/debug_freebsd/lastSuccessfulBuild/artifact/*zip*/archive.zip (n'oubliez pas les guillemets autour de l'URL) puis unzip bins.zip; chmod -R 0777 archive/; rm bins.zip; cd corefx .

(rien requis de la machine Windows)

• J'ai fait le test :

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

Ça dit:

40 test(s) échoué(s)

Je ne pense pas que le fait que certains assemblys ne puissent pas encore compiler/fonctionner pour FreeBSD devrait être un obstacle majeur pour tester le reste d'entre eux.

Je suis d'accord avec celui-ci. Il est préférable de commencer le contrôle qualité du travail que nous avons effectué, au lieu d'attendre que tout soit terminé avant de commencer les tests.

C'est écrit : 40 tests ont échoué

40 sur combien ? Dans quel stade sommes-nous ? :)

40 sur combien ? Dans quel stade sommes-nous ? :)

me bat aussi. Les tests sont générés à partir d'assemblys de test (dll gérés) et le nombre total de tests n'est pas visible.

Le nombre que le script produit à la fin est le nombre d'assemblages de test qui ont échoué. xUnit doit écrire le nombre de tests qui ont échoué par assembly sur stdout dans le cadre de son exécution. Les numéros doivent également figurer dans les fichiers XML qu'il produit dans chaque dossier d'assemblage de test.

Il se peut que l'environnement d'exécution se bloque également et dans ce cas, il se peut qu'il n'y ait pas de journaux produits par assemblage de test.

@ jasonwilliams200OK Savez-vous si des progrès ont été réalisés sur le problème de la signature de l'assembly ? Je frappe la même chose sur Ubuntu. Si personne ne travaille dessus, peut-être devrions-nous ouvrir un sujet séparé pour cela.

@naamunds , qui a été corrigé sur le maître CoreFX dans le cadre de https://github.com/dotnet/corefx/issues/3739.

Mise à jour - Aujourd'hui, j'ai effectué des tests sur FreeBSD, des milliers d'entre eux réussissaient et certains échouaient en raison d'un manque évident de System.Diagnostics.Process et d'amis snafu. Après environ 40 minutes d'exécution réussie, il s'est bloqué sur les tests System.IO.FileSystem (pendant environ environ 15 minutes avant d'appuyer sur Ctrl + C pour terminer).

@jasonwilliams200OK comment avez-vous réussi à compiler corefx sous freebsd ? Je suis bloqué sur des erreurs sur gssapi

@sec , au moment de la https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 , GSSAPI n'était pas requis par CoreFX. Cependant, il semble que le pkg soit récemment porté sur FreeBSD : http://www.freshports.org/security/p5-GSSAPI. Vous pouvez essayer pkg upgrade pkg && pkg update && pkg install p5-GSSAPI .

@ jasonwilliams200OK , j'ai déjà eu ceci (c'est perl ext. btw.) Le problème manquait gssapi_ext.h. L'astuce consistait à faire "pkg install krb5" - maintenant compilé en natif.
Je les ai copiés dans le runtime coreclr, mais je ne peux toujours pas exécuter l'application ASP.NET Core :) le combat continue alors.

Quel est l'état actuel de cette tâche ? La liste de elle complète et exacte ? Est-ce que tout le travail qui doit être fait est fait ? Ensuite, il devrait être fermé, non?

Si oui, pourquoi avons-nous encore cette tâche ? https://github.com/dotnet/corefx/issues/2070

S'il y a encore du travail à faire, faut-il enregistrer une nouvelle émission en fonction de l'état actuel des choses ?

Il y a aussi ce besoin je pense - dotnet/corefx#2046

faut-il enregistrer une nouvelle émission sur la base de l'état actuel des choses ?

Oui :+1:

Nous avons discuté du portage communautaire pour FreeBSD avec @RussellHaley (de la communauté FreeBSD) et @wfurt (de l'équipe .NET Core) qui ont tous deux exprimé leur intérêt pour le travail.
Voici une proposition de plan que nous élaborons (les commentaires / suggestions sont les bienvenus):

1. Produire des binaires dans le référentiel CoreCLR et CoreFX ciblant FreeBSD - l'utilisation de hacks est très bien
   
   
   
   • Difficile à paralléliser, @wfurt travaillera là-dessus
   
   
   • Le build peut être un mélange de builds d'autres plateformes (Mac, Linux) ciblant FreeBSD
   
   
   • Nous aurons besoin d'étapes documentées (sur le wiki FreeBSD) pour reproduire la construction avec des corrections de bogues spécifiques à FreeBSD
   
   
2. Exécuter et stabiliser les tests CoreCLR (à l'aide de corerun)
   
   
   
   • Les tests peuvent être construits sur une autre plate-forme
   
   
   • Objectif : Fournit une qualité d'exécution de base
   
   
3. Exécuter et stabiliser les tests CoreFX (en utilisant corerun)
   
   
   
   • Les tests peuvent être construits sur une autre plate-forme
   
   
   • Notez que cela nécessite xunit. Nous pensons, sur la base de notre expérience de portage passée, qu'une fois [2] terminé, xunit fonctionnera.
   
   
   • Cela peut être en théorie parallélisé avec [2] - cela peut nécessiter un raccourci sur xunit (par exemple, générer une recette d'exécution statique sur une autre plate-forme)
   
   
4. Compilation complète de la pile sur FreeBSD (en utilisant corerun comme programme d'amorçage de [1]-[3])
   
   
   
   • Nous aurons besoin de tous les outils (nuget, msbuild, roslyn) pour travailler sur le boostrapping .NET Core
   
   
5. Installateurs (ports FreeBSD)
   
   
   
   • Première étape : Utiliser les binaires de produits à partir des flux nuget
   
   
   • Deuxième étape : créer un produit à partir de la source (bloqué lors de la création à partir de la source)
   
   
   • Nécessite l'expertise de la communauté FreeBSD et des conseils sur la conception
   
   
   • Remarque : nous pouvons également lier les packages FreeBSD à partir des pages de téléchargement officielles de .NET Core en tant que packages de support communautaire.
   
   
6. Des builds et des tests réguliers sur FreeBSD
   
   
   
   • Objectif : s'assurer que les changements dans les dépôts .NET Core cassant FreeBSD sont connus tôt
   
   
   • Conception nécessaire
   
   
   • Nécessite l'expertise de la communauté FreeBSD et des conseils sur la conception
   
   

Principes de fonctionnement :

• Les modifications dans [2]-[4] doivent être effectuées principalement dans les dépôts CoreCLR/CoreFX (en raison des exigences de signature CLA, des révisions de code des experts/membres de l'équipe .NET Core, etc.)
• Nous suivrons les travaux de haut niveau sur cette question. Les bogues spécifiques seront classés en tant que problèmes distincts.

Si quelqu'un est intéressé à aider, veuillez nous le faire savoir ici. Nous pouvons facilement distribuer les éléments de travail de [2] & [3] ci-dessus une fois que nous sommes assez loin avec [1].

La dernière version de la proposition est en haut de la page de ce numéro.

Marquer plus de personnes qui ont exprimé leur intérêt sur la liste freebsd-mono ( ce fil ) : @smortex @radovanovic @Echo-8-ERA

BTW: Je ne trouve pas le compte Mathieu Prevot GitHub -- [UPDATE] Trouvé dans https://github.com/dotnet/corefx/issues/1626#issuecomment -330348424: @mprevot

Pour NetBSD, nous manquons de mutex posix robustes, c'est la seule fonctionnalité qui manque encore pour produire des mutex robustes nommés. Nous pouvons maintenant déboguer les échecs de code managé avec LLDB/NetBSD. Cela fonctionne très bien avec les fichiers core. Lors de mes tentatives précédentes, nous sommes morts du manque de cette fonctionnalité dans LLDB (j'ai commencé à porter ce débogueur pour .NET).

Avoir un meilleur support FreeBSD aidera considérablement.

Il y avait aussi des problèmes dans le passé avec le manque de support d'invité hyperv pour attacher un buildbot NetBSD aux machines CI et vérifier les correctifs... pour cela, j'aurais peut-être besoin de l'aide de MS. Je m'attends à ce qu'il y ait un logiciel propriétaire requis pour l'exécuter, que je ne possède pas... Je pourrais trouver un développeur pour faire le travail s'il y avait un intérêt commun (investissement) entre la Fondation NetBSD et Microsoft.

Où manque-t-on les « mutex posix robustes » ? Fait-il partie de .NET Core PAL ?

De quel système CI parlez-vous ? Pourquoi est-il lié à l'effort de port .NET Core ?

Où manque-t-on les « mutex posix robustes » ?

Dans le noyau NetBSD (et libc/libpthread), cela fait partie de CoreCLR. FreeBSD l'a développé au cours des deux dernières années. Il est peut-être disponible dans la dernière version stable, mais il est nécessaire de vérifier.

Je souhaite ajouter cette fonctionnalité avant mon redémarrage du portage .NET. (Il a également été détecté une minuscule API manquante pour le routage réseau .. mais je l'ignore maintenant).

Fait-il partie de .NET Core PAL ?

Je ne me souviens plus maintenant, sans vérifier le code - c'est l'API utilisée pour implémenter des mutex robustes nommés .NET (ou peut-être des sémapthores).

De quel système CI parlez-vous ?

NetBSD.

Pourquoi est-il lié à l'effort de port .NET Core ?

C'était une fonctionnalité optionnelle la dernière fois que j'ai regardé. J'ai décidé d'obtenir la parité des fonctionnalités sur les interfaces du noyau et les utilitaires (comme LLDB). Juste mon style de travail, pour obtenir un bloc de construction fonctionnel et plus tard construire une maison. À un moment donné nous en aurons besoin de toute façon alors pourquoi ne pas le développer en une seule fois. Merci de votre compréhension :)

Peut-être pouvez-vous simplement taguer le groupe freebsd-dotnet sur GH ? Il y est membre (ou vous pouvez rechercher son nom de compte). ‎Son email est [email protected]

[EDIT] Supprimer les e-mails entendus et la réponse précédente de @karelz

@RussellHaley n'hésitez pas à taguer le plus grand groupe si vous le jugez approprié. Je n'ai pas pu trouver le compte GH de Mathieu via son nom ni son e-mail, c'est ce que je voulais dire ci-dessus (BTW : je l'ai contacté directement par e-mail).

Je vais chercher à taguer le groupe.

Voici le compte de Mathieu. Peut-être un paramètre de confidentialité ?

https://github.com/mprevot

À votre santé,

Russ

Le lun 18 sept. 2017 à 13:01, Karel Zikmund [email protected]
a écrit:

@RussellHaley https://github.com/russellhaley n'hésitez pas à taguer le
plus grand groupe si vous le jugez approprié. Je n'ai pas trouvé le GH de Mathieu
compte via son nom ni email, c'est ce que je voulais dire ci-dessus.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment-330338996 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ACENF_N6mtOo3fptvku-LUMioNpZG7coks5sjswWgaJpZM4EPG-N
.

Je ne vois nulle part mentionné ici, mais quelle version la plus basse de FreeBSD nous visons ici (je suppose au moins 10 et plus tard, mais peut-être 9 aussi) ?
(Je suis également un peu confus quant à la discussion qui devrait avoir lieu sur la liste de diffusion mono @freebsd , et quoi ici ?)

Eh bien, si Fedora veut dire quelque chose, MS ne prendra en charge que les versions actuellement prises en charge, c'est-à-dire 10.3 (10.4 bientôt) et 11.1.

@radovanovic FreeBSD 9 n'est plus supporté, 10 le seront en avril 2018, 11 en 2021. D'après mon expérience, il ne devrait pas y avoir de problèmes de compilation sur 11 vs 10 (et même 9 si vous voulez). FreeBSD est développé avec une compatibilité descendante à l'esprit.

@radovanovic Je suis également un peu confus quant à la discussion qui devrait avoir lieu sur la liste de diffusion mono@freebsd , et quoi ici ?

Je m'attendais aux discussions techniques, à la coordination du travail et au statut ici car c'est un public plus large que la liste de diffusion mono@freebsd . OTOH, nous ne voulons pas avoir des milliards de discussions aléatoires sur un problème, nous pourrions donc prendre certaines discussions de conception spécifiques dans des problèmes distincts de celui-ci si elles dépassent un nombre raisonnable de réponses.

J'ai enfin pu exécuter des tests corefx sur FreeBSD 11.0 (sans tests de boucle externe)
Total réussi : 144208
Total des échecs : 2622
Total ignoré 207

Je mettrai à jour
La bataille à grande échelle peut commencer. Volontaires recherché.

Et oui, j'ai sauté la deuxième étape proposée. Je vais m'y remettre aussi.

Avec quelques changements en cours, les statistiques actuelles ressemblent à :
Total passé : 238892
Total des échecs : 58
Total ignoré 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.Globalisation.Tests.dll, 2
System.Drawing.Common.Tests.dll, 31
System.Console.Tests.dll, 2

dotnet/corefx#24538 ouvert pour suivre la prise en charge des gobelets cassés.

Grand progrès! L'ajout de NetBSD lors de la prise en charge de FreeBSD dans l'arborescence devrait être simple.

@wfurt s'il vous plaît partagez l'adresse e-mail, je vais laisser tomber quelques lignes.

Le support initial a été fusionné avec la branche master. La construction devrait fonctionner comme décrit sur la page WIKI.
Je progresse lentement sur dotnet/corefx#24386 mais cela ne devrait pas freiner la plupart des utilisateurs.

Pouvons-nous déjà amorcer .NET sur FreeBSD ?

Je n'ai pas essayé depuis un moment @krytarowski Il y a eu des

Salut, donc je suis embourbé avec les tests gérés par clr qui ne s'exécutent pas. https://pastebin.com/B5KhtKX5

Toute contribution serait formidable car c'est un problème depuis un certain temps. J'ai également récemment rencontré un échec de construction sur la construction corefx sous Windows (master, révision Git 749194e). https://pastebin.com/JXUySLTY

Je suppose que c'est un problème intermittent mais cela m'a ralenti ce soir.

Si vous regardez l'erreur :

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

Et la ligne de code incriminée :

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

Mon intuition serait que $maxProcesses n'est pas défini, ce qui conduit à une expression booléenne incomplète :

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

Cela devrait être assez testable. Et si c'est le cas, il suffit d'aller chercher en arrière pour essayer de savoir comment vous vous êtes retrouvé comme ça.

Merci pour ton aide! @josteink :) Vous avez raison. Le correctif est ici : https://pastebin.com/d5y9k1tw

Cela permet aux tests de s'exécuter, mais j'ai abandonné environ 1000 erreurs toutes de même nature :

ÉCHEC - JIT/Méthodique/casts/iface/_il_dbgiface2/_il_dbgiface2.sh
COMMENCER L'EXÉCUTION
/usr/home/russellh/Git/coreclr/bin/tests/Windows_NT.x64.Debug/Tests/coreoverlay/corerun _il_dbgiface2.exe
coreclr_initialize a échoué - état : 0x80004005
Attendu : 100
Réel : 255
FIN DE L'EXÉCUTION - ÉCHEC

D'accord, selon les très bonnes informations de j'exécutais une partie de ma version de build et une partie de mon build in debug. Une erreur de copier/coller embarrassante. Je reconstruis maintenant.

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

Le correctif est ici : https://pastebin.com/d5y9k1tw

Si vous avez un correctif qui corrige une version cassée, je vous recommande de l'envoyer sous forme de pull-request afin qu'il soit corrigé pour tout le monde :)

Merci, je le ferai. Je travaille toujours sur l'exécution des tests et je n'étais pas sûr de la cause de l'erreur ultérieure la nuit dernière.

Je suppose que le support Freebsd 11 "pkg install" pour netcore 2.1 (une fois publié) ne se produira pas, non?

TLDR ; Beaucoup de travail a été fait, mais il doit y avoir quelqu'un pour le conduire à la maison. L'écriture du Makefile du port est la partie la plus simple.

@wfurt a réussi à

Séparément sur la liste de diffusion [email protected] , @dragonsa a importé une version binaire de Dot Net Core 1 et toute la chaîne d'outils (msbuild, nuget, etc.) de MintOS en utilisant l'émulation Linux. J'ai pu utiliser ses correctifs et exécuter certains des outils, mais je n'ai jamais réussi à construire quoi que ce soit. Je ne sais pas si ces correctifs ont encore été validés ; J'étais en train de les réviser et j'ai changé de travail. Je n'ai pas de DotNet dans mon rôle actuel et je m'attaque à d'autres choses en ce moment.

Qu'est-ce que tout cela signifie? Si quelqu'un peut vérifier les correctifs de [email protected] . https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html

@russellhadley Merci pour la rédaction Russell.

Salut,

En discutant de cela avec un développeur .NET ici, je suis prêt à aider au développement d'un port/package FreeBSD.

Divulgation complète : je ne suis pas un développeur .NET, mais je suis prêt à travailler avec qui que ce soit pour intégrer cela dans l'arborescence.

~cy

@cschuber J'ai été trop occupé pour garder un œil sur l'état actuel des choses, mais en tant que personne qui a soumis beaucoup de correctifs FreeBSD et a réussi à faire fonctionner Hello World il y a environ 3 ans, ce serait génial si nous pouvions enfin voir cette chose se poser correctement. Tu as tout mon soutien :)

@cschuber , les problèmes actuellement actifs sont https://github.com/dotnet/coreclr/issues/18067. Ces quatre fonctionnalités sont principalement laissées à https://github.com/dotnet/corefx/issues?q=is :open+ label:os-freebsd+label :up-for-grabs+is:issue, parmi lesquelles Filesystem watcher semble être le plus délicat/laborieux https://github.com/dotnet/corefx/issues/2046.

Merci pour l'offre @cschuber. Nous sommes presque au point où cela peut être possible.
Nous avons récemment travaillé avec @mateusrodrigues pour faire fonctionner .net sur FreeBSD et il essaie de faire fonctionner PowerShell. Les listes @kasper3 envoyées sont principalement des fonctionnalités manquantes. Je pense que nous pouvons lancer PNSP pour le moment. De mes futurs problèmes les plus urgents sont dotnet/corefx#30698 et https://github.com/dotnet/coreclr/issues/18481. Ce serait formidable si quelqu'un de la communauté pouvait y puiser. Je n'ai pas fait de tests récemment, mais je crains que le nombre d'échecs n'augmente.
Nous devrions ouvrir un problème pour chaque nouveau groupe défaillant.

Je commence également à réparer la compilation des sources, mais il reste encore des défis à relever.
Le compilateur c# est écrit en c#. La version actuelle de .net utilise la version précédente de .net pour produire des assemblys managés. Cela dépend aussi des packages de Nuget.
À l'heure actuelle, nous avons un cli d'amorçage suffisamment bon pour que nous puissions compiler coreclr, corefx et quelques autres dépôts sur FreeBSD. Je n'ai pas encore mis à jour les instructions de construction pour refléter les modifications 2.1 et la compilation des sources.

+1 Juste une note pour dire que je suis content que cela ait encore un peu d'élan. C'est difficile à suivre avec autant de pièces mobiles, mais il semble que les gens progressent. J'ai créé https://github.com/dotnet/coreclr/issues/6115 il y a quelque temps, mais le projet sur lequel je travaillais a ensuite été suspendu. J'espère vraiment que ce sera aussi simple que pkg install dotnet && dotnet build un jour (sans compatibilité Linux).

J'attends aussi ça avec impatience

Nous avons des builds quotidiens en cours maintenant. On peut obtenir runtime ou sdk ici : https://dotnetcli.blob.core.windows.net/dotnet/Runtime/master/dotnet-runtime-latest-freebsd-x64.tar.gz et
https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-freebsd-x64.tar.gz

Il est également possible de faire du cross-target, par exemple sur Linux ou Windows, on peut faire dotnet publish -r freebsd-x64 et cela créerait une application FreeBSD autonome.

Il est encore incomplet et non pris en charge, mais il devrait permettre à quiconque de contribuer plus facilement.
Ce serait formidable si les gens pouvaient essayer, signaler les problèmes.
Ce serait également le bon moment pour l'effort final pour combler l'écart de fonctionnalités et corriger les bogues.

cc : @mateusrodrigues

Beau travail, @wfurt et @bartonjs.

Quand j'ai proposé mes premiers commits FreeBSD il y a environ 2-3 ans, je ne pensais pas vraiment que nous y arriverions, mais je voulais certainement essayer.

C'est certainement une étape importante et, espérons-le, il sera plus facile pour les nouveaux contributeurs d'aider à terminer le port.

Un grand merci à tous ceux qui nous ont aidés à aller aussi loin

Grand progrès! Je me bats toujours avec la chaîne d'outils (la plupart des projets LLVM en plus de LLDB et LLD sont terminés) et la virtualisation assistée par matériel pour NetBSD (Linux/BSD commence maintenant à démarrer jusqu'à une exception fatale VTx, des systèmes d'exploitation plus simples comme FreeDOS fonctionnent déjà) .. donc je vais reprendre mon portage NetBSD, j'espère le plus tôt possible. Un meilleur support FreeBSD vous aidera avec un CV plus facile.

Impressionnant :)

On célèbre l'ivresse pourquoi l'ensilage à la bombe ??

@krytarowski Pouvez-vous développer de quelle manière le 'support FreeBSD' peut être meilleur ?

Ce serait formidable si un gourou de FreeBSD pouvait jeter un œil à https://github.com/dotnet/coreclr/issues/22124 .
Il est facile à reproduire avec une application simple et la version 12.0 semble casser quelque chose dont dotnet dépend.

Salut, je ne suis pas un gourou mais nous avons rencontré une régression de threading dans 12-RELEASE dans le port Lua53.
Voir ici pour le bogue d'origine : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235158
et ici pour le bogue du système de base qui a été identifié : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235211 (notez que le bogue du système de base identifie le code qui peut être utilisé pour reproduire le problème à des fins de comparaison).

Le correctif pour Lua consiste à établir un lien avec -pthread, même s'il n'y a aucune exigence de Lua pour -pthread.

merci @RussellHaley. Cela ressemble à une piste prometteuse.

Heureux d'avoir pu aider. J'adorerais jouer le jeu mais j'ai à peine les quelques heures nécessaires pour entretenir le port Lua. Continuez ce bon travail!

En tant que personne qui a corrigé l'implémentation des threads FreeBSD dans coreclr , je pense que les pthreads sont utilisés de manière assez constante, car c'est ce que j'ai dû corriger pour que la construction s'exécute.

Cela dit, il pourrait y avoir des mais et des morceaux sous-jacents que je n'ai jamais eu à toucher et qui utilisent des fils "normaux" ...

Peut-être que quelqu'un d'autre qui en sait plus sur la mise en œuvre générale peut intervenir ? @janvorli ?

Cela résout le problème pour moi:

[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

Je n'ai pas fait de tests approfondis mais au moins je peux réexécuter dotnet .

Ok, je peux voir que l'exécutable dotnet n'est pas lié à des pthreads pour d'autres systèmes que Linux.
https://github.com/dotnet/core-setup/blob/2ef0b64810530961f492c33d37fc7509128e0a9b/src/corehost/cli/exe.cmake#L59 -L61

Cela signifie-t-il que la réponse pour résoudre ce problème est aussi simple qu'il y paraît ? C'est-à-dire aussi simple que cela? https://github.com/josteink/core-setup/commit/25657ba2e181cce401acd7f4bf9d27a08a668470

Si c'est le cas, je serai heureux d'en faire un PR.

Oui je pense que oui. J'attendais la confirmation de
Je ne sais pas si nous avons également besoin de "dl", mais cela peut être résolu lorsque vous soumettez PR @josteink

Droit. Ma faute. Donc plus comme ça alors : https://github.com/josteink/core-setup/commit/a08f38e25a98c25f59c8ed8c8567a0cb08b1c1c6

J'ai créé un PR pour cela. Faites-moi savoir s'il a besoin d'être modifié : https://github.com/dotnet/core-setup/pull/5072

Droit. Ma faute. Donc plus comme ça alors: josteink/ core-setup@a08f38e

J'ai créé un PR pour cela. Faites-moi savoir s'il a besoin d'être modifié : dotnet/core-setup#5072

Juste pour info, il semble que cela soit déjà corrigé dans le système de base : https://reviews.freebsd.org/D18988

On dirait que le problème principal dans dotnet/coreclr#22124 est corrigé @wfurt.
J'ai seulement un problème lorsque j'essaie de publier une application autonome sur FreeBSD 12.0.

Les packages NuGet officiels de freebsd-x64 ont été supprimés depuis l'aperçu 2 de .NET Core 3.0 et nous n'avons pas pu publier d'applications pour FreeBSD depuis lors. Est-il prévu de les réactiver dans la 3.0 ?

Malheureusement, nous avons dû supprimer la priorité de FreeBSD (pour diverses raisons et difficultés dans le support Azure de bout en bout) et cela ne sera pas prioritaire dans .NET Core 3.0.
Nous aimerions le garder semi-fonctionnel dans l'état où il est maintenant, mais nous n'avons pas beaucoup de temps pour investir maintenant :(.

@karelz Merci pour votre réponse et je comprends le travail prioritaire de .NET Core 3.0. Je vais alors me concentrer sur la mise en place de mes applications avec l'émulation FreeBSD Linux. :)

@ hjc4869 Ou vous pouvez essayer mono. IIRC, il prendra en charge .NET Standard 3.0

Je prévois de réessayer mais comme @karelz l'a mentionné, ce n'est pas la priorité pour 3.0

@newsash Mono est une option acceptable pour moi. Cependant, j'ai eu du mal à créer mon projet avec les cibles mono ajoutées aux fichiers csproj .NET Core existants.

Sur une machine Linux, j'ai essayé d'ajouter net472 à TargetFrameworks et de définir la variable FrameworkPathOverride mais cela n'a pas bien fonctionné. Si je consomme une API qui est implémentée à la fois dans mono et .NET Core, mais pas dans .NET Framework, la génération avec mono échouera. En outre, bien que mono prenne en charge .NET Standard 2.1, je ne pouvais toujours pas ajouter de référence aux dll .NET Standard 2.1 dans un csproj net472.

Dois-je ajouter un csproj séparé et utiliser mono msbuild au lieu d'utiliser des outils dotnet, ou avez-vous des suggestions sur le problème ?

Juste une petite remarque.

Avec le mono sur le point d'être avalé par .NET 5 selon l'annonce récente [1], fournir un support décent pour FreeBSD est devenu urgent.

Mono s'est avéré avoir un très bon support multiplateforme et peut être construit sans problème à partir des ports FreeBSD. De nombreux magasins exécutent leurs charges .net sur FreeBSD car ce système d'exploitation a de nombreuses fonctionnalités uniques. Jusqu'à présent, mono a comblé le fossé, mais avec .NET 5, il semble probable que dans un avenir proche, mono sera fusionné dans NET 5 et la communauté FreeBSD sera totalement coupée de l'écosystème .NET.

Dotnet devrait avoir un support mature de FreeBSD bien avant que cela ne se produise.

Je pense que Microsoft devrait officiellement prendre en charge FreeBSD à ce stade et s'assurer que tous les outils dotnet sont construits sur cette plate-forme.

@jasonpugsley a rassemblé les instructions https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD et @joperator essaie de faire fonctionner la construction de source https://github. com/dotnet/source-build/issues/1139

Nous avons les 30 derniers tests qui ont échoué pour 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 examine System.Diagnostics.Tests.ProcessTests, donc l'échec des tests de verrouillage semble le plus grand écart restant. Ce serait formidable si quelqu'un pouvait jeter un œil à dotnet/corefx#30899.

Je me demande juste s'il y a des mises à jour à ce sujet ou s'il est abandonné ?

@elfalem , ces jours-ci, la jambe de FreeBSD CI (qui effectue une compilation croisée à partir d'Ubuntu) s'exécute sur les PR dotnet/runtime. Il utilise une image docker de https://github.com/dotnet/dotnet-buildtools-prereqs-docker/ , qui a toutes les prérequis installées. Nous pouvons utiliser le même conteneur Docker pour publier un package d'exécution (essentiellement un tar.gz), localement ou sur une machine distante. Par exemple, nous pouvons configurer une action GitHub dans l'une de nos branches fork, quelque chose comme : https://github.com/am11/runtime/blob/feature/freebsd/ci/.github/workflows/main.yml , qui télécharge des artefacts aux versions GitHub sur push de balise https://github.com/am11/runtime/releases/tag/6.0.0-dev.freebsd.1. L'archive dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz dans ce cas a suffisamment de bits pour exécuter simplement une application dotnet publiée (à partir d'un autre système linux/mac, doté du SDK dotnet). Je l'ai testé en créant une nouvelle VM 12.2 (vagabond), extrait et copié une application publiée de mac vers VM, cela a fonctionné :

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

Je pense que @Thefrank cherchait à créer un package de ports FreeBSD approprié à un moment donné.

Je me demande juste s'il y a des mises à jour à ce sujet ou s'il est abandonné ?

vous voudrez peut-être regarder https://github.com/dotnet/source-build/issues/1139
Je n'ai pas essayé récemment car j'attends la version finale de dotNET5 mais, il y a quelques mois, le runtime FreeBSD ne pouvait être construit que sous forme de compilation croisée sur Linux. ASPNet et SDK nécessitaient également une compilation croisée Linux, mais ne sont construits que si les étoiles s'alignent (les mises à jour d'arcade ou un autre bot automatisé n'ont pas rompu une dépendance)

edit: et @ am11 a publié une meilleure rédaction pendant que je randonnée de fin de soirée. lis ça et pas le mien
edit2: ponctuation oubliée et il semble que la version finale ait été publiée il y a 2 jours. Je suppose que je devrais travailler sur ça ou quelque chose

En dehors de tout ce qui précède, j'ai créé un projet FreeBSD sur https://github.com/dotnet/runtimelab/ et je progresse lentement dans la création et la publication de packages. L'objectif est de créer et de publier suffisamment pour que l'application s'exécute sur FreeBSD et ait des graines pour la génération de sources.

J'ai pensé écrire une mise à jour rapide. J'ai finalement aligné toutes les planètes pour construire 5.0.0 RTM sur FreeBSD. Je n'avais pas suivi depuis Preview3 et il a fallu un certain temps (et de nombreuses tentatives de build) pour trouver la bonne combinaison de builds compatibles pour obtenir un 5.0 réussi.
J'ai pu construire PowerShell 7.1.0 avec étonnamment peu de hacks, cela fonctionne même si je ne l'ai pas testé à fond, mais cela semble être un bon test du SDK.
Je viens juste de construire AspNetCore mais je ne l'ai pas encore testé du tout.

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

Le seul problème lié à l'exécution de ce travail manuellement (c'est-à-dire en dehors du système CI) est le problème causé par des modifications de rupture nécessitant qu'une version particulière soit disponible pour la prochaine version à utiliser. Cela n'arrive pas souvent, mais il faut beaucoup d'essais et d'erreurs pour trouver le bon commit. Avoir la cross-build Linux dans le système CI devrait résoudre ce problème, mais je ne l'ai pas encore examiné. Néanmoins, il est bon de savoir que je peux créer un SDK complet, puis utiliser ce SDK pour créer autre chose.

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

C'est un bon progrès @jasonpugsley. J'essaie de trouver une meilleure réponse pour la construction, mais je n'ai pas pu y consacrer un laps de temps décent au cours des derniers mois ;(
PowerShell vous a-t-il causé un problème à cause de terminfo ou avez-vous copié la définition du terminal d'ailleurs?

J'ai récupéré la définition du terminal sur mon Mac d'où j'étais ssh.

@jasonpugsley tu es bien en avance sur moi. core et sdk construits à partir de linux cross freebsd. fonctionne bien à partir des tests limités que j'ai effectués. ni le runtime ni les crossbuilts sdk ne sont capables de s'appuyer sur freebsd eux-mêmes (linux et freebsd utilisent llvm9 et clang9).
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0
Je vais y toucher un peu plus si j'ai plus de temps ce week-end et voir aussi si je peux au moins faire construire aspnetcore sur linux pour freebsd

@Thefrank , tu veux dire :

$ 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

échoue ou les binaires de artifacts/packages/Release/Shipping/dotnet-runtime-5.0.0-dev-freebsd-x64.tar.gz n'ont pas réussi à s'exécuter ?
Si vous essayez de compiler le SDK 5x sur Ubuntu 18 ou 20, vous voudrez peut-être appliquer ce correctif https://github.com/dotnet/sdk/commit/80e42f16422352f725d78be72071781d8365a238 (c'est sur la branche principale).

J'ai vraiment besoin d'arrêter de faire des messages quand je suis à moitié endormi.
La construction du runtime et du sdk se termine sur linux.
Ces binaires s'exécutent sur freebsd (dotnet --info, new console et run)
Ces binaires ne peuvent pas créer un runtime ou un sdk à partir de la source sur freebsd

Ah ok. Je n'ai pas essayé de dogfodder les binaires stage0 pour reconstruire le runtime sur FreeBSD en tant qu'HostOS.

ld : erreur : /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim. exports:1 : directive inconnue : V1.0

Cela pourrait valoir la peine de signaler ce problème séparément. Il existe probablement plusieurs façons de le réparer, mais ce correctif fait-il une différence :

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

ce patch fait-il une différence

Je m'attendrais à ce que FreeBSD suive Linux en ce qui concerne les scripts de version de symboles, pas Darwin. OMI, il est plus probable que le problème soit qu'il y ait quelque chose de spécifique à GNU-awk dans generateversionscript.awk

patch a changé l'erreur :
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: _CreateProcessForLaunch
si problème de version awk :

awk --version
awk version 20121220 (FreeBSD)

Si c'est facile à expérimenter, pouvez-vous essayer d'installer le paquet gawk et changer l'appel dans les fichiers CMake en gawk ?

a rétabli le patch. pkg gawk installé.
trop paresseux pour comprendre comment le script build.sh transmet les arguments cmake car cela n'a pas de sens immédiatement, alors j'ai juste lié gawk->awk.
même erreur d'origine
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0

modification tardive : il semble que les binaires sur Linux ne se soient pas construits correctement :

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

principalement le RID: osx-x64 pourrait causer des problèmes

principalement le RID: osx-x64 pourrait causer des problèmes

Ce RID est affiché par le SDK après certaines résolutions des plates-formes prises en charge et non prises en charge. Il n'a fondamentalement aucun effet sur l'exécution de l'application. Le vrai RID détecté par le runtime est correct, sinon les applications (telles que dotnet(1) ) ne s'exécuteront pas correctement.
c# using System; using System.Runtime.InteropServices; class Program { static void Main() => Console.WriteLine("Real RID: {0}", RuntimeInformation.RuntimeIdentifier); }
imprime Real RID: freebsd.12-x64 sur ma boîte.

Ouvert #45663 pour le suivi du problème de ld. J'ai pu reproduire aussi.

@Thefrank concernant l'erreur ld, essayez ceci:

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)

Cela activera la clause else dans eng/native/functions.cmake ici :

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

Pour être tout à fait honnête, je ne suis pas un expert en éditeur de liens, donc même si cela fonctionne, je n'ai pas cherché plus en profondeur pour voir ce qui était réellement requis/canonique pour clang sur FreeBSD.

Ahh, le problème de l'agent utilisateur de l'éditeur de liens frappe à nouveau. La chaîne de version de LLD inclut (compatible with GNU linkers) dans une tentative de descendre le chemin GNU ld des tests de configuration mais clairement pas assez intelligent pour ce cas :)

La correspondance sur LLD semble bonne ici même si le drapeau LD_GNU est maintenant quelque peu mal nommé.

Oui, il a besoin de plus de travail. Le nom du drapeau prête maintenant à confusion. S'il vous plaît, n'essayez pas de commettre cela tel quel.

De : Ed Maste [email protected]
Envoyé : lundi 7 décembre 2020 10:26:48
À : dotnet/runtime [email protected]
Cc : Jason Pugsley [email protected] ; Mentionnez [email protected]
Objet : Re : [dotnet/runtime] Prise en charge de FreeBSD (#14537)

Ahh, le problème de l'agent utilisateur de l'éditeur de liens frappe à nouveau. La chaîne de version de LLD inclut (compatible avec les éditeurs de liens GNU) dans une tentative de suivre le chemin GNU ld des tests de configuration mais clairement pas assez intelligent pour ce cas :)

La correspondance sur LLD semble bonne ici même si le drapeau LD_GNU est maintenant quelque peu mal nommé.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/dotnet/runtime/issues/14537#issuecomment-739583816 , ou désabonnez-vous https://github.com/notifications/unsubscribe-auth/AECFDEXKTDFRAX4ZEE6VXZTSTQHLRANCNFSM4TS3XPPA .

J'ai choisi d'utiliser https://github.com/dotnet/runtime/pull/45664
Clr construit jusqu'au sous-ensemble Clr.Tools puis échoue avec

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

sous-ensemble "mono" et sous-ensemble "libs" complets sans erreurs

@Thefrank C'est la deuxième partie de cette différence dont vous avez besoin pour résoudre ce problème :

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>

Il serait peut-être préférable de l'ajouter à la ligne LINUX en tant que OU dans la condition.

@jasonpugsley qui a fait l'affaire !
/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):
Je savais que j'avais oublié de faire quelque chose il y a quelques jours ! ça doit être intéressant

edit: sans crossgen (aka juste la seconde moitié)

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

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

Time Elapsed 00:12:05.56

edit dernier edit sur ce post je jure:
Je sais que les tests peuvent prendre un certain temps et cela dit un test de longue durée, mais cela devient incontrôlable pour un test
System.Net.HttpListener.Tests: [Long Running Test] 'System.Net.Tests.HttpListenerResponseTests.AddLongHeader_DoesNotThrow', Elapsed: 00:36:20

a tué le test après avoir attendu 2h d'autres tests avaient encore des échecs

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