Runtime: Soporte para FreeBSD

Parece haber acuerdo en lo que respecta a https://github.com/dotnet/corefx/issues/1576 .

Cuando también tengamos una decisión sobre https://github.com/dotnet/corefx/issues/1625 , deberíamos poder comenzar a enviar algún código.

Portteam ha llegado a un acuerdo sobre dotnet / runtime # 14536, a menos que MSFT elija lo contrario, será FreeBSD . El problema dotnet / corefx # 1999 será potencialmente el problema que introduzca la definición en la API pública.

El portteam ha llegado a un acuerdo sobre dotnet / runtime # 14536, a menos que MSFT elija lo contrario, será FreeBSD

Si leí bien, esto significa que cuando se fusiona https://github.com/dotnet/corefx/pull/1999 , podemos considerar que MSFT aprueba la nueva API pública y, por lo tanto, podemos seguir adelante con los problemas restantes con solicitudes de extracción regulares sin necesidad de la aprobación de MSFT.

Si es así, me suena bien.

Los siguientes pasos según https://github.com/dotnet/corefx/pull/1999#issuecomment -111279577 son:

1. El "equipo de puertos de FreeBSD" continúa su trabajo para producir una versión FreeBSD de CoreFX (rastreada por dotnet / corefx # 1626).
2. El equipo de puertos muestra lo suficiente de la pila CoreFX y CoreCLR en FreeBSD para que podamos comenzar a ejecutar las pruebas de la unidad CoreFX en FreeBSD.
3. Las pruebas alcanzan un nivel mínimo de calidad. Todavía no sé exactamente cómo se ve esto, pero espero que signifique algo como que la mayoría de las pruebas pasan. Idealmente, no tendríamos un montón de pruebas específicas deshabilitadas solo para FreeBSD (en comparación con Linux y OSX, no querríamos mantener FreeBSD en un estándar más alto que las otras plataformas * NIX que tenemos allí).
4. Trabajando con el equipo de puertos de FreeBSD, el equipo de CoreFX obtiene las pruebas de CoreFX agregadas a nuestro sistema CI que se ejecuta en FreeBSD.
5. Discuta la fusión de un PR basado en el problema dotnet / runtime # 14536, que agrega la propiedad.

Me parece un plan completamente razonable.

Bien, entonces comencemos a trabajar para hacer que corefx funcione.

El primer obstáculo en la construcción de corefx en FreeBSD parece ser mono. El script de compilación insiste en que se requiere la versión 4.1. @ajensenwaud hizo un trabajo en esto en el host de Frankfurt, pero no estoy seguro de qué tan completo es.

Pondré en cola una compilación por ahora y veré cómo se ve el resultado.

Editar: La compilación (mono) se bloquea con el siguiente truco al final:

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.

El primer obstáculo en la construcción de corefx en FreeBSD parece ser mono

FWIW, personalmente no creo que este sea el primer obstáculo. Hay dos problemas relacionados con la construcción:

1. Construyendo ensamblajes que funcionen correctamente en FreeBSD
2. Construyendo esos ensamblajes en FreeBSD

(1) es fundamental, y creo que de qué se trata este tema. (2) es muy bueno tenerlo, pero la falta de él no impide la creación de un gran sistema para ejecutar código administrado en FreeBSD.

Por supuesto, puede priorizar como mejor le parezca, pero mi recomendación sería centrarse en (1) en lugar de (2).

Tenga en cuenta que todavía tenemos problemas para construir corefx en Linux y hacerlo en OSX, de modo que nuestro sistema CI construye los ensamblados para esas plataformas en Windows; luego transporta los ensamblados resultantes a la plataforma de destino para ejecutar las pruebas.

Eso es lo suficientemente justo. Simplemente asumí que sería más fácil obtener el soporte general de la plataforma FreeBSD integrado en corefx si realmente pudiéramos construirlo nosotros mismos en FreeBSD.

Me conformaré con la construcción iniciada por Windows por ahora e intentaré crear juntos una configuración de construcción ninja.

@josteink por cierto. corefx ahora debería basarse en Mono 4.0.1.44.

@akoeplinger Niza. Eso me deja algo de esperanza de que podamos ejecutarlo también en FreeBSD :)

Buenos puntos. Sin embargo, si realmente queremos que corefx sea parte del entorno FreeBSD, realmente lo necesitamos para poder compilar desde el código fuente para ingresarlo al sistema Ports.

Escuché que Mono 4.0.1.44 soluciona muchos de estos problemas, pero aún no he tenido tiempo de jugar con él. Sé que el equipo de ports está actualizando el port Makefile y hablamos con un nuevo parche.

El 12 de junio de 2015, a las 20:21, Stephen Toub [email protected] escribió:

El primer obstáculo en la construcción de corefx en FreeBSD parece ser mono

FWIW, personalmente no creo que este sea el primer obstáculo. Hay dos problemas relacionados con la construcción:

Construyendo ensamblajes que funcionen correctamente en FreeBSD
Construyendo esos ensamblajes en FreeBSD
(1) es fundamental, y creo que de qué se trata este tema. (2) es muy bueno tenerlo, pero la falta de él no impide la creación de un gran sistema para ejecutar código administrado en FreeBSD.

Por supuesto, puede priorizar como mejor le parezca, pero mi recomendación sería centrarse en (1) en lugar de (2).

Tenga en cuenta que apenas tenemos corefx compilado en Linux y compilado en OSX, de modo que nuestro sistema CI construye los ensamblados para esas plataformas en Windows; luego transporta los ensamblados resultantes a la plataforma de destino para ejecutar las pruebas.

-
Responda a este correo electrónico directamente o véalo en GitHub.

Sí, de ninguna manera estoy en desacuerdo ... poder _build_ corefx en Linux, OSX y FreeBSD es importante. Simplemente sugiero que desde una perspectiva de prioridad es más importante poder ejecutar realmente corefx en Linux, OSX y FreeBSD. : wink: Si se pueden trabajar ambos en paralelo, mucho mejor.

@ghuntley ,
sería super: genial: si tenemos una lista de verificación de tareas de rebajas que describa lo que queda:

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

se presenta como:

• [ ] tarea 1
• [ ] tarea 2
• [] tarea 3

¡Esto probablemente animará a otros a anotar esas hazañas y el soporte de FreeBSD aterrizará antes de lo previsto! :Gafas de sol:

Que yo sepa, los siguientes trabajos en CoreFX son necesarios para el soporte de FreeBSD:

• [x] Introducir la plataforma FreeBSD a las herramientas de compilación y los scripts. (Hecho por @josteink y yo, relaciones públicas dotnet / corefx # 2021 fusionadas, dotnet / corefx # 2030 fusionadas)

13 Los ensamblados no se compilan por sí mismos y necesitan cambios específicos de FreeBSD. En su mayoría, las piezas de interoperabilidad que ya existen para Linux / OS X (ordenar por aparición en el resultado de la compilación):

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

Intentaré actualizar esa lista en función de los RP abiertos y fusionados.

FYI: PR dotnet / corefx # 2039 fusionado

Solo estoy tratando de estar por delante de la curva aquí ... ¿Cómo planeamos implementar System.IO.FileSystem.Watcher ?

Iirc FreeBSD no tiene inotify como Linux y Windows (que también es la razón por la que no hay Dropbox la última vez que lo comprobé). ¿Será esta una fuente potencial de problemas en nuestro camino? ¿O alguien tiene una idea de cómo solucionar esto?

Sugiero que lo eliminemos por el momento y lancemos una PlatformNotSupportedException como sugirió Stephen Toub en el otro tema (https://github.com/dotnet/corefx/pull/2021#issuecomment-111602342). Entonces, tenemos al menos un conjunto completo de ensamblajes y podemos continuar trabajando en ese problema en particular sin bloquear pasos adicionales.

¿Le importaría abrir un número aparte para eso?

Pasemos las discusiones de System.IO.FileSystem.Watcher a dotnet / corefx # 2046

Chicos, ¿hay algún bloqueador de este tipo para System.Diagnostics.Process ?

@ jasonwilliams200OK agregó FreeBSD a S.RT.I.RI temprano esta mañana, que se fusionó, pero las pruebas de FreeBSD dentro de CheckPlatformTests tuvieron que ser retiradas hasta que se actualice dotnet/buildtools .

• [] Actualice las herramientas de compilación para admitir FreeBSD: https://github.com/dotnet/buildtools/pull/180
• [] Vuelva a aplicar [Fact,PlatformSpecific(PlatformID.FreeBSD)] pruebas a CheckPlatformTests; consulte https://github.com/dotnet/corefx/pull/2068#discussion_r32570244 y https://github.com/dotnet/corefx/pull/2068#discussion_r32570244
• [] Agrega public static OSPlatform FreeBSD a https://github.com/dotnet/corefx/pull/2068

@ jasonwilliams200OK hubo algunas discusiones anoche sobre System.Diagnostics.Process en gitter que se han formalizado en https://github.com/dotnet/corefx/issues/2070

@ghuntley , gracias. De hecho, leo esos mensajes. System.Diagnostics.Process es complicado. AFAIK, el equipo de io.js tuvo desafíos similares con la gestión de procesos de FreeBSD. El equipo Mono probablemente lo haya logrado , así que esperemos que

System.IO.FileSystem.DriveInfo

Como se discutió en el gitter, para este traté de investigar el uso básico 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);
  }
}

Ejecutar esa muestra produjo este resultado:

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

Entonces parece que hace lo que necesitamos. La pregunta es, ¿deberíamos hacer algún tipo de filtrado sobre los resultados?

Al observar la "intención" del objeto DriveInfo , proveniente del mundo de Windows de .NET, a menudo se ha enumerado las ubicaciones disponibles para almacenar o recuperar archivos ( C: , D: , etc.). Pero cuando se utilizan sistemas de archivos jerárquicos de Unix, devolver / sería adecuado para cubrir esas necesidades.

Entonces, ¿qué debemos devolver? ¿Qué sería útil? ¿Debería siquiera considerarlo útil o no?

La versión de Linux simplemente lo vuelca todo, excepto las cosas que están configuradas para ser ignoradas:

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

Intenté poner el siguiente filtro, pero realmente no cambió nada en términos de salida:

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

¿Alguna opinión?

@josteink , ¡grandes excavaciones! Basado en https://github.com/dotnet/corefx/issues/815#issuecomment -113825960 y https://github.com/dotnet/corefx/issues/1729 , creo que deberíamos colaborar con @sokket para llegar a una solución que funciona en diferentes Unices.

Tengo una versión que se ejecuta en OSX que usa getmntinfo y statfs para obtener información sobre cada punto de montaje, que parece el mapeo más lógico del concepto de Windows Drive. Verificaré dos veces que las definiciones de función y estructura en OSX coincidan con las definiciones de FreeBSD y, si es así, mi confirmación para OSX también funcionará para BSD.

Me aseguraré de agregarte a mi PR

Suena bien. Gracias por avisarnos y gracias por darle también un poco de amor a FreeBSD.

Investigué algunos detalles básicos para estas funciones, y parece que tenemos que hacer todas las clasificaciones y conversiones nosotros mismos, así que si alguien más ya se ha esforzado, ¿quién soy yo para decir que no? ;)

No hay problema ... parece que la principal diferencia fue con las declaraciones de estructura; ya que probablemente lo haremos más en el futuro, estoy haciendo una refactorización que nos permitirá compartir muchas de las firmas de PInvoke. Agregaré una descripción más grande en mi PR (hoy o mañana, según cómo se ejecute la prueba) pero básicamente agregué las firmas PInvoke y las firmas de estructura para FreeBSD (según los encabezados que encontré en línea) y se compila. Lo probé en Mac, por lo que _debería_ (en teoría ...) funcionar en FreeBSD ya que es solo un cambio de declaración de estructura, pero su kilometraje puede variar :). Si no es así, tendrá la clase DriveInfo y PInvokes el 99% del camino y solo necesitará algunos ajustes basados ​​en los matices de FreeBSD.

Excelente noticia @sokket. Te he creado una cuenta en la máquina que el equipo de puertos usa para el desarrollo, tiene base europea pero siempre está encendida y tiene un montón de memoria y potencia de procesamiento. Con suerte, esto ayudará y eliminará algo de la fricción al trabajar con FreeBSD.

# ssh [email protected]

La autenticación de contraseña está deshabilitada, use una de sus claves .

@josteink ver también el problema: https://github.com/dotnet/corefx/issues/815 (System.IO.FileSystem.DriveInfo para Mac / FreeBSD)

¿Hay alguna actualización? ¿Alguien implementó los ensamblajes restantes en FreeBSD?

He estado ocupada atendiendo a mi nuevo bebé, no he tenido tiempo para codificar en ningún lado.

Sospeché que problemas como estos han estado inactivos y creo que esto lo confirma hasta cierto punto.

Para los ensamblados que aún no están implementados, vinculé el tema "cómo implementar" en la lista anterior. Espero que eso ayude a coordinar el esfuerzo para implementar estas asambleas restantes.

Debo admitir que estaba teniendo dificultades para hacer un seguimiento de lo que hemos hecho y dónde, así que definitivamente es una buena jugada. Buen trabajo :)

¿Dónde encuentro eso? Sería gratificante recibir las asambleas restantes
implementado.

El 25/07/15 22:10, Jan Henke escribió:

Para los ensamblados que aún no están implementados, vinculé el "cómo
para implementar el problema "-en la lista anterior. Espero que ayude a coordinar
el esfuerzo para implementar estos ensamblajes restantes.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment -124838781.

Este comentario aquí: https://github.com/dotnet/corefx/issues/1626#issuecomment -111800540

En este momento estoy esperando que se terminen las correcciones nativas, ya que estas deberían hacerse cargo de la mayor parte del trabajo para hacer que estos ensamblados funcionen en FreeBSD.

@nguerrera sería genial si nos mantuviera informados sobre el progreso. :)

Actualizar:
@janhenke confirmó que con https://github.com/dotnet/corefx/pull/2974 fusionado, System.IO.Pipes basa en FreeBSD. :Gafas de sol:

Actualizar:
dotnet / corefx # 2527 cerrado, System.IO.MemoryMappedFiles basa en FreeBSD.
¡Gracias @janhenke por la confirmación!

Gracias al enfoque de las correcciones, solo se trata de asegurarse de que las correcciones se compilen en FreeBSD. Afortunadamente, eso hace la vida mucho más fácil. :)

dotnet / corefx # 3257 debería traernos System.Diagnostic.Process y System.IO.FileSystem.Watcher dejando solo System.Net.NameResolution sin resolver. (Verificaré los dos ensamblados mencionados una vez que el PR se haya fusionado y funcione en FreeBSD)

dotnet / corefx # 3471 debería traernos System.Net.NameResolution y completar la lista anterior.

dotnet / corefx # 3471 se acaba de fusionar :)

@sokket , gracias por la actualización. Construí master (f467911) en FreeBSD usando esta guía: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24. El bloqueador actual es https://github.com/dotnet/buildtools/issues/292, que se corrigió en sentido ascendente pero a la espera de la próxima implementación de herramientas de compilación. :)

Actualización: nuevas herramientas de compilación con corrección para dotnet / buildtools # 292 han aterrizado en CoreFX master. El siguiente paso de buildtools es https://github.com/dotnet/buildtools/issues/300 : falta la herramienta específica del sistema operativo para poder ejecutar las pruebas.

@janhenke , ha marcado System.Diagnostics.Process (# 2070) y System.IO.FileSystem.Watcher (# 2046) como hechos; pero no se implementan ni se compilan en FreeBSD. ¿Realmente ha verificado la lista compilando el código administrado?

Según mi experiencia reciente con commit 60c78da3c918b0d256cc1f878de06d351dbe3342 (consulte msbuild.log ), los siguientes ensamblados no se compilan:

• Sistema.Diagnóstico.Proceso
• System.Diagnostics.ProcessManager
• System.Diagnostics.ThreadInfo
• System.IO.FileSystemWatcher
• System.Net.SocketAddress _ (bien, este se agregó recientemente) _

Por lo que recuerdo, verifiqué la compilación de calzas asociadas. Dado que el código administrado debería estar libre de código específico de FreeBSD. Esas calzas que menciona deberían haberse eliminado con los PR vinculados anteriormente.
Pero también he ejecutado una compilación completa en el medio. Por lo menos System.Diagnostics.ThreadInfo y System.IO.FileSystemWatcher compilaron. Entonces algo debe haber retrocedido.

Esas calzas que menciona deberían haberse eliminado con los PR vinculados anteriormente.

En realidad, PR https://github.com/dotnet/corefx/pull/3257 no está relacionado con shim. Todavía hay algo de código PAL dentro de los proyectos administrados (el enfoque anterior), por lo tanto, es necesario crear ensamblados administrados para estar absolutamente seguro.

En realidad, PR dotnet / corefx # 3257 no está relacionado con shim.

Estoy en desacuerdo. Está refactorizando el código P / Invoke en el shim System.Native. Además, como edité anteriormente, estoy recordando al menos algunos de los ensamblajes compilados en el medio.

Estoy en desacuerdo

https://github.com/dotnet/corefx/pull/3257/files : vea las instancias de .Unix.cs y .Linux.cs por System.Diagnostics. . Tenga en cuenta que .OSX.cs está intacto.

Está refactorizando el código P / Invoke en el sistema.

Sí, refactoriza algunos ayudantes comunes bajo System.Native , pero no System.Diagnostics.* et al.

Incluso cuando estos ensamblados son sólo P / Invocando a System. * Libs, puede que todavía se requiera trabajo de FreeBSD para algunos de ellos, por ejemplo, System.Diagnostics.Process y System.IO.FileSystem.Watcher. Están usando funcionalidades específicas para Linux y OS X, y no planeamos intentar abstraer eso detrás de las correcciones nativas. El objetivo de los shims no es terminar con un solo binario administrado para Unix, aunque esa es una propiedad muy buena cuando se trata del trabajo; el objetivo principal es evitar las diferencias de ABI que causan fragilidad. Espero que al menos un puñado de ensamblados continúe teniendo binarios específicos de Linux / OS X, donde también se necesitaría un binario FreeBSD.

Para su información, no hay ensamblados corefx llamados System.Diagnostics.ProcessManager,
System.Diagnostics.ThreadInfo,
System.IO.FileSystemWatcher, o
System.Net.SocketAddress. Esos son tipos en otros ensamblajes.

Espero que al menos un puñado de ensamblados continúe teniendo binarios específicos de Linux / OS X, donde también se necesitaría un binario FreeBSD.

¿Significa eso que siempre que Solaris y no glibc (musl y μlibc) que tengan como objetivo Linux, como los soportes de Alpine, lleguen, tendrán binarios separados? ¿Y luego las diferentes arquitecturas ARM, MIPS, RISC, SPARC, etc. requerirían otro nivel de separación?

¿No tendría sentido convergerlos a la interfaz POSIX / llamadas al sistema tanto como sea posible y detectar las diferencias usando configuraciones (a través de CMake) para usarlas en el mismo binario (a menos que esté afectando el tamaño / rendimiento del asambleas significativamente)? Según tengo entendido, System.Native.so binary tiene un ayudante común para otros System.*.Native.so específicos que parecen suficientes para el cumplimiento del principio de separación de preocupaciones. Pero si se transforma en System.Net.Http.FreeBSD.ARM.Native.so o System.Net.Http.Solaris.SPARC.so , entonces será bastante inmanejable con "demasiadas partes móviles", etc.

no hay ensamblados corefx nombrados

Buen punto. De hecho, estaba siguiendo las instancias de fallas en los registros de msbuild y el número de archivos .OSX.cs y .Linux.cs . :sonrisa:

¿No tendría sentido convergerlos a la interfaz POSIX / llamadas al sistema tanto como sea posible?

Hacemos. ¿Cómo propones hacer bien la visualización de archivos a través de POSIX? ¿Cómo proponen que procesemos bien la enumeración a través de POSIX?

Pero si se transforma a System.Net.Http.FreeBSD.ARM.Native.so o System.Net.Http.Solaris.SPARC.so, entonces será bastante inmanejable con "demasiadas partes móviles", etc.

No entiendo esto. El objetivo de los archivos .so nativos es que obtienes diferentes binarios nativos para cada plataforma de destino, pero no se denominan System.Whatever.Platform.ext, solo System.Whatever.ext; que permite al compilador tomar la misma lógica general y usarla con las definiciones específicas de esa plataforma. Esto solo funciona cuando existen los mismos símbolos en cada plataforma; el compilador no toma mágicamente el código escrito para usar inotify y le permite trabajar con la interfaz de observación de archivos de algún otro sistema. En general, nos hemos esforzado por usar API estandarizadas donde tiene sentido, pero para lugares donde tales API no existen o no están bien estandarizadas o donde hay mejores soluciones específicas de plataforma, hemos usado la mejor plataforma. soluciones específicas, por ejemplo, usar procfs para la enumeración de procesos en Linux, usar inotify para la observación del sistema de archivos en Linux, etc. perspectiva de plataformas adicionales, como cuando aparecen esas nuevas plataformas, si las API existentes funcionan, también lo hace la solución existente, y si no lo hace, entonces necesita escribir una nueva solución para esa plataforma. Por eso, hemos intentado hacer todo lo posible en código administrado, utilizando nativo simplemente para las correcciones 1: 1 que hacen que el código administrado sea mucho más portátil donde las API de destino son portátiles. Hemos usado #ifdefs en el código nativo para pasar por alto pequeños detalles, donde esta API en qué plataforma está lo suficientemente cerca de esa API en otra plataforma, pero eso no se extiende a soluciones completas que son completamente diferentes; en ese momento, la abstracción se convierte en la API administrada y hacemos una implementación administrada diferente para cada sistema.

Si FreeBSD expone inotify como lo hace Linux o si expone EventStream como lo hace OS X, entonces cuando esas API de OS están detrás del shim, el shim se puede hacer que funcione fácilmente con FreeBSD, y el mismo binario administrado se puede usar en FreeBSD. Si FreeBSD no expone tales API, entonces deberá escribir una implementación personalizada de System.IO.FileSystem.Watcher con alguna solución de observación de archivos que esté disponible en FreeBSD. Comentarios similares para System.Diagnostics.Process. Si el código para la visualización de archivos está en la cuña o no tiene poco impacto en eso.

El plan es que todas estas API nativas eventualmente se trasladen detrás de la cuña. Pero están lejos de ser una prioridad, ya que no son muy portátiles, por lo que nos ha visto comenzando con API de libc que están (o se supone que están) expuestas en todas partes.

¿Cómo propones hacer bien la visualización de archivos a través de POSIX?

No podemos hacer todo POSIX, ya que inotify es específico de Linux. FreeBSD / OSX ofrece implementaciones separadas.

Propuesta:

Desde el punto de vista de la distribución de binarios nativos, todos los sistemas operativos deberían recibir el mismo conjunto de binarios con los mismos nombres, pero con diferentes funciones.

Aquí hay una estructura propuesta:

# 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

Esto es esencialmente lo que tenemos, p. Ej.

• "common_function_for_posix_compliants" son funciones 1: 1 modificadas de forma nativa consumidas desde la lógica en un binario compartido administrado por Unix
• "funciones_ligeramente_divergentes" se modifican de forma nativa casi en funciones 1: 1 con algunos #ifdefs nativos consumidos de la lógica en un binario compartido administrado por Unix
• "painfully_diverged_watch_function" son / serán funciones 1: 1 modificadas de forma nativa consumidas desde la lógica en binarios administrados específicos de la plataforma

La verdadera diferencia es si el código que implementa la lógica "dolorosamente divergente" se hace en C # o C ++, y hemos elegido C # y ya está todo implementado en C #. No he visto ningún argumento convincente de por qué, en tales casos, reescribir todo para que esté en C ++ sería una opción significativamente más convincente.

@ jasonwilliams200OK Con la actualización de hoy a mono, vuelvo a construir corefx en FreeBSD. Hay muchos mensajes de error nuevos desde la última vez que lo construí.
Me pregunto si Interop.Libc desaparecerá eventualmente.

@stephentoub Todo se reduce al empaque. Tener todo el código específico de la plataforma en la parte nativa tiene la ventaja de tener un ensamblado administrado para todas las plataformas similares a Unix.
Además, creo firmemente que necesitamos una implementación genérica para este "código administrado dependiente de la plataforma. Incluso si solo arroja una excepción NotImplementedExcpetion. De esa manera, puede realizar una migración mucho más fácil a nuevas plataformas, si al menos compila todo de inmediato. También daría la oportunidad de al menos intentar ejecutar en una plataforma no compatible.
En general, es mucho más fácil si al menos puede compilar correctamente de inmediato.

@stephentoub , lo siento, estaba mezclando C ++ con C #. Ahora entiendo que la capa nativa es solo exponer esos puntos de entrada (funciones de libs nativas o syscalls) y desinfectar IO y código administrado es donde decidimos qué método de utilidad empaquetado específico de la plataforma / syscall empaquetado se consumirá. Además, ambos niveles (nativos y administrados) no pueden ser independientes del sistema operativo donde se consumirá la funcionalidad que no es POSIX.

@janhenke , estoy de acuerdo. También estoy construyendo maestro mientras hablamos. Hay otro problema recurrente de firma de ensamblaje, estoy golpeando:

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]

publicará el enlace completo msbuild.log gist en breve.

Además, creo firmemente que necesitamos una implementación genérica para este "código administrado dependiente de la plataforma".

Estoy de acuerdo. En lugar de clases parciales, probablemente podamos usar la herencia con métodos virtuales comunes y en su mayoría comunes en la clase base abstracta y anular "en su mayoría comunes / parcialmente diferentes" cuando sea necesario. Luego, implemente métodos abstractos que sean totalmente diferentes para cada sistema operativo. Con este enfoque, en mi opinión, si donde la especialización / generalización está perdiendo DRY'ing, podemos emplear ascendencia de herencia de varios grados. Pero la última vez que verifiqué, se preferían las clases parciales a la asociación entre padres e hijos en CoreFX (por alguna razón que no recuerdo). :)

Aquí está el msbuild.log para confirmar 2d36889:

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

/ cc: @akoeplinger

@ jasonwilliams200OK Por qué es tan complicado. Todo lo que necesita es una condición "si no Windows, Linux, OS X" en los archivos del proyecto. Por lo tanto, incluya un conjunto de archivos específico de la plataforma en la compilación o los genéricos.

No creo que el hecho de que algunos ensamblados no puedan compilarse / funcionar para FreeBSD todavía deba ser un gran obstáculo para probar el resto de ellos. Probablemente deberíamos hacer que los que tienen trabajo pendiente (FileSystemWatcher, Process, Networking) se omitan en la compilación y la ejecución de prueba en FreeBSD. Luego, podemos mencionarlos individualmente mientras tenemos un proceso para evitar la regresión en lo que ya funciona.

No creo que el hecho de que algunos ensamblados no puedan compilarse / funcionar para FreeBSD todavía deba ser un gran obstáculo para probar el resto de ellos.

Acordado

Probablemente deberíamos hacer que los que tienen trabajo pendiente (FileSystemWatcher, Process, Networking) se omitan en la compilación y la ejecución de prueba en FreeBSD

O similar a lo que sugirió @janhenke , simplemente permítales compilar, ya sea eliminando archivos que arrojan PlatformNotSupported, o simplemente mapeando FreeBSD a uno de los casos que funciona, por ejemplo, si se elige FreeBSD, simplemente compile el de Linux ( no funcionará, pero se construirá).

Con los cambios recientes de @ellismg (# 3684), puedo ejecutar pruebas simplificando el método anterior (https://github.com/dotnet/coreclr/issues/1633#issuecomment-143669303):

• Después de https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 (especialmente el paso para construir calzas nativas por separado _después_ de la salida build.sh con estado 1), descargue los artefactos CoreCLR zip: cd /root; curl -o bins.zip "http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/debug_freebsd/lastSuccessfulBuild/artifact/*zip*/archive.zip (no olvide las comillas alrededor de la URL) y luego unzip bins.zip; chmod -R 0777 archive/; rm bins.zip; cd corefx .

(no se requiere nada de la máquina de Windows)

• Hizo la prueba:

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

Dice:

40 pruebas fallaron

No creo que el hecho de que algunos ensamblados no puedan compilarse / funcionar para FreeBSD todavía deba ser un gran obstáculo para probar el resto de ellos.

Tengo que estar de acuerdo con esto. Es mejor comenzar a evaluar el trabajo que hemos realizado, en lugar de esperar a que todo se complete antes de comenzar a probar.

Dice: 40 pruebas fallaron

40 de cuantos? ¿En qué estadio estamos? :)

40 de cuantos? ¿En qué estadio estamos? :)

también me gana. Las pruebas se generan a partir de ensamblajes de prueba (dlls administrados) y el número total de pruebas no es visible.

El número que produce el script al final es el número de ensamblajes de prueba que fallaron. xUnit debe escribir la cantidad de pruebas que fallaron por ensamblado en la salida estándar como parte de su ejecución. Los números también deben estar en los archivos XML que produce en cada carpeta de ensamblaje de prueba.

Podría ser que el tiempo de ejecución también se bloquee y, en ese caso, es posible que no se produzcan registros por ensamblaje de prueba.

@ jasonwilliams200OK ¿Sabe si se ha avanzado en el tema de la firma de la asamblea? Estoy golpeando lo mismo en Ubuntu. Si nadie está trabajando en ello, quizás deberíamos abrir un tema aparte.

@naamunds , que se ha corregido en CoreFX master como parte de https://github.com/dotnet/corefx/issues/3739.

Actualización: hoy ejecuté pruebas en FreeBSD, miles de ellas estaban aprobadas y luego algunas fallaban debido a la obvia falta de System.Diagnostics.Process y problemas de amigos. Después de ~ 40 minutos de ejecución exitosa, se colgó en las pruebas de System.IO.FileSystem (durante aproximadamente ~ 15 minutos antes de presionar Ctrl + C para terminar).

@ jasonwilliams200OK ¿cómo se las arregló para compilar corefx en freebsd? Estoy atascado en errores sobre gssapi

@sec , en el momento de tomar estas notas: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 , CoreFX no requería GSSAPI. Sin embargo, parece que el paquete se ha portado recientemente a FreeBSD: http://www.freshports.org/security/p5-GSSAPI. Es posible que desee probar pkg upgrade pkg && pkg update && pkg install p5-GSSAPI .

@ jasonwilliams200OK , ya tengo esto (es perl ext. por cierto). El problema faltaba gssapi_ext.h. El truco consistía en hacer "pkg install krb5", ahora compilado de forma nativa.
Los he copiado en el tiempo de ejecución de coreclr, pero todavía no puedo ejecutar la aplicación ASP.NET Core :) La lucha continúa.

¿Cuál es el estado actual de esta tarea? ¿La lista de @janhenke es completa y precisa? ¿Se está haciendo todo el trabajo que hay que hacer? Entonces debería estar cerrado, ¿verdad?

Si es así, ¿por qué todavía tenemos esta tarea? https://github.com/dotnet/corefx/issues/2070

Si aún queda trabajo por hacer, ¿debería registrarse un nuevo número en función del estado actual de las cosas?

Creo que también se necesita esto: dotnet / corefx # 2046

¿Debería registrarse una nueva emisión en función de la situación actual?

Sí: +1:

Hablamos sobre el puerto impulsado por la comunidad para FreeBSD con @RussellHaley (de la comunidad FreeBSD) y @wfurt (del equipo de .NET Core), quienes expresaron interés en el trabajo.
Aquí hay una propuesta de plan que elaboramos (los comentarios / sugerencias son bienvenidos):

1. Produzca binarios en repositorios de CoreCLR y CoreFX dirigidos a FreeBSD: usar hacks está bien
   
   
   
   • Difícil de paralelizar, @wfurt trabajará en eso
   
   
   • La compilación puede ser una combinación de compilaciones de otras plataformas (Mac, Linux) dirigidas a FreeBSD
   
   
   • Necesitaremos pasos documentados (en la wiki de FreeBSD) para reproducir la compilación con correcciones de errores específicas de FreeBSD
   
   
2. Ejecute y estabilice las pruebas de CoreCLR (usando corerun)
   
   
   
   • Las pruebas se pueden construir en otra plataforma
   
   
   • Objetivo: proporciona una calidad básica de tiempo de ejecución
   
   
3. Ejecute y estabilice las pruebas de CoreFX (usando corerun)
   
   
   
   • Las pruebas se pueden construir en otra plataforma
   
   
   • Tenga en cuenta que esto requiere xunit. Creemos, basándonos en nuestra experiencia pasada de portabilidad, una vez que [2] esté hecho, xunit simplemente funcionará.
   
   
   • En teoría, esto se puede paralelizar con [2]; puede requerir un atajo xunit (por ejemplo, generar una receta de ejecución estática en otra plataforma)
   
   
4. Compilación de pila completa en FreeBSD (usando corerun como bootstrapper de [1] - [3])
   
   
   
   • Necesitaremos todas las herramientas (nuget, msbuild, roslyn) para trabajar en la mejora de .NET Core
   
   
5. Instaladores (puertos FreeBSD)
   
   
   
   • Primera etapa: uso de binarios de productos de feeds nuget
   
   
   • Segunda etapa: compilar el producto desde la fuente (bloqueado en la compilación desde el esfuerzo de la fuente)
   
   
   • Requiere experiencia de la comunidad FreeBSD y orientación sobre diseño
   
   
   • Nota: También podemos vincular paquetes de FreeBSD desde las páginas de descarga oficiales de .NET Core como paquetes de soporte de la comunidad
   
   
6. Ejecuciones regulares de compilación y prueba en FreeBSD
   
   
   
   • Objetivo: asegurarse de que los cambios en los repositorios de .NET Core que rompen FreeBSD se conozcan con anticipación
   
   
   • Diseño necesario
   
   
   • Requiere experiencia de la comunidad FreeBSD y orientación sobre diseño
   
   

Principios de funcionamiento:

• Los cambios en [2] - [4] deben realizarse principalmente en repositorios de CoreCLR / CoreFX (debido a los requisitos de firma de CLA, revisiones de código de expertos / miembros del equipo de .NET Core, etc.)
• Realizaremos un seguimiento del trabajo de alto nivel sobre este tema. Los errores específicos se archivarán como problemas separados.

Si alguien está interesado en ayudar, háganoslo saber aquí. Podemos distribuir fácilmente los elementos de trabajo de [2] y [3] anteriores una vez que estemos lo suficientemente lejos con [1].

La última versión de la propuesta está en la parte superior de este número.

Etiquetando a más personas que expresaron interés en la lista freebsd-mono ( este hilo ): @smortex @radovanovic @ Echo-8-ERA

Por cierto: no puedo encontrar la cuenta de Mathieu Prevot GitHub - [ACTUALIZACIÓN] Se encuentra en https://github.com/dotnet/corefx/issues/1626#issuecomment -330348424: @mprevot

Para NetBSD, echamos de menos los mutex de posix robustos, esta es la única característica que aún falta para producir mutex de robus con nombre. Ahora podemos depurar fallas de código administrado con LLDB / NetBSD ... funciona bien con archivos centrales. En mis intentos anteriores, morimos por la falta de esta característica en LLDB (comencé a portar este depurador para .NET).

Tener un mejor soporte de FreeBSD será de gran ayuda.

También hubo problemas en el pasado con la falta de soporte de invitado de Hyperv para adjuntar un buildbot NetBSD a las máquinas CI y verificar los parches ... para esto, podría necesitar la ayuda de MS. Espero que se requiera software propietario para ejecutarlo, que no soy de mi propiedad ... Podría encontrar un desarrollador para hacer el trabajo si hubiera un interés conjunto (inversión) entre The NetBSD Foundation y Microsoft.

¿Dónde echamos de menos los "mutex de posix robustos"? ¿Es parte de .NET Core PAL?

¿A qué sistema de IC se refiere? ¿Por qué está vinculado al esfuerzo del puerto de .NET Core?

¿Dónde echamos de menos los "mutex de posix robustos"?

En el kernel de NetBSD (y libc / libpthread), esto es parte de CoreCLR. FreeBSD lo desarrolló en los últimos dos años. Puede estar disponible en la última versión estable ... pero es necesario comprobarlo.

Quiero agregar esta función antes de reiniciar la migración de .NET. (También se detectó una pequeña API faltante para el enrutamiento de red ... pero la omito ahora).

¿Es parte de .NET Core PAL?

No recuerdo ahora, sin verificar el código: es la API que se usa para implementar .NET denominados exclusiones mutuas robustas (o tal vez sematóforos).

¿A qué sistema de IC se refiere?

NetBSD.

¿Por qué está vinculado al esfuerzo del puerto de .NET Core?

Era una característica opcional la última vez que miré. Decidí obtener paridad de características en las interfaces y utilidades del kernel (como LLDB). Solo mi estilo de trabajo, conseguir un bloque funcional y luego construir una casa. En algún momento lo necesitaremos de todos modos, así que ¿por qué no desarrollarlo de una vez? Gracias por entender :)

¿Quizás puedas etiquetar el grupo freebsd-dotnet en GH? Allí es miembro (o puede buscar el nombre de su cuenta). Su correo electrónico es [email protected]

[EDITAR] Eliminar mensajes de correo electrónico recibidos y respuesta anterior de @karelz

@RussellHaley no dude en etiquetar al grupo más grande si lo cree apropiado. No pude encontrar la cuenta de GH de Mathieu a través de su nombre o correo electrónico, eso es lo que quise decir anteriormente (por cierto: le hice ping por correo electrónico directamente).

Miraré etiquetar al grupo.

Aquí está el relato de Mathieu. ¿Quizás una configuración de privacidad?

https://github.com/mprevot

Salud,

Russ

El lunes 18 de septiembre de 2017 a la 1:01 p.m., Karel Zikmund [email protected]
escribió:

@RussellHaley https://github.com/russellhaley no dude en etiquetar el
grupo más grande si lo cree apropiado. No pude encontrar el GH de Mathieu
cuenta a través de su nombre o correo electrónico, eso es lo que quise decir arriba.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment-330338996 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ACENF_N6mtOo3fptvku-LUMioNpZG7coks5sjswWgaJpZM4EPG-N
.

No puedo ver en ningún lugar mencionado aquí, pero ¿qué versión más baja de FreeBSD estamos apuntando aquí (supongo que al menos 10 y posteriores, pero tal vez 9 también)?
(También estoy un poco confundido sobre qué discusión debería ocurrir en la lista de correo mono @freebsd , y ¿qué aquí?)

Bueno, si nos guiamos por Fedora, MS solo admitirá las versiones compatibles actualmente, es decir, 10.3 (10.4 pronto) y 11.1.

@radovanovic FreeBSD 9 ya no es compatible, 10 tendrá EoL en abril de 2018, 11 en 2021. Desde mi experiencia, no debería haber ningún problema con la compilación en 11 vs 10 (e incluso 9 si lo desea). FreeBSD se desarrolla teniendo en cuenta la compatibilidad con versiones anteriores.

@radovanovic También estoy un poco confundido, ¿qué discusión debería ocurrir en la lista de correo mono @ freebsd , y qué aquí?

Esperaba las discusiones técnicas, la coordinación del trabajo y el estado aquí, ya que esta es una audiencia más amplia que la lista de correo mono @ freebsd . OTOH, no queremos tener miles de millones de discusiones aleatorias sobre un tema, por lo que podríamos tomar algunas discusiones de diseño específicas en temas separados de este si crecen por encima de un número razonable de respuestas.

Finalmente pude ejecutar pruebas de corefx en FreeBSD 11.0 (sin pruebas de bucle externo)
Aprobado total: 144208
Total fallidos: 2622
Total omitido 207

Actualizaré https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD con instrucciones. Presentaré problemas específicos y los etiquetaré con os-freebsd y up-for-grab.
La batalla a gran escala puede comenzar. Voluntarios necesitados.

Y sí, me salté el paso dos propuesto. Volveré a eso también.

Con algunos cambios en el trabajo en curso, las estadísticas actuales se ven así:
Aprobado total: 238892
Total fallidos: 58
Total omitido 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 abierto para rastrear el soporte de vasos rotos.

¡Gran progreso! Agregar NetBSD cuando se tiene soporte para FreeBSD en el árbol debería ser simple.

@wfurt por favor comparta la dirección de correo electrónico,

El soporte inicial se ha fusionado con la rama maestra. La compilación debería funcionar como se describe en la página WIKI.
Estoy progresando lentamente en dotnet / corefx # 24386, pero eso no debería frenar a la mayoría de los usuarios.

¿Ya podemos arrancar .NET en FreeBSD?

No lo he intentado por un tiempo @krytarowski Hubo un impulso para actualizar las herramientas a la versión 2.0 y estaba esperando que ese esfuerzo se estabilizara. Lo intentaré de nuevo y publicaré una actualización.

Hola, estoy atascado con las pruebas administradas por clr que no se están ejecutando. https://pastebin.com/B5KhtKX5

Cualquier aportación sería genial, ya que ha sido un problema durante algún tiempo. También me encontré recientemente con un error de compilación en la construcción de corefx en Windows (maestro, revisión de Git 749194e). https://pastebin.com/JXUySLTY

Supongo que es un problema intermitente, pero esta noche me ha ralentizado.

Si observa el error:

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

Y la línea de código ofensiva :

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

Mi intuición sería que $maxProcesses no está definido, lo que lleva a una expresión booleana incompleta:

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

Esto debería ser bastante comprobable. Y si ese es el caso, solo tienes que ir a cazar hacia atrás para tratar de descubrir cómo terminaste así.

¡Gracias por tu ayuda! @josteink :) Tienes razón. El parche está aquí: https://pastebin.com/d5y9k1tw

Esto permite que las pruebas se ejecuten, pero me di por vencido con ~ 1000 errores de la misma naturaleza:

FALLIDO - JIT / Methodical / casts / iface / _il_dbgiface2 / _il_dbgiface2.sh
COMENZAR LA EJECUCIÓN
/usr/home/russellh/Git/coreclr/bin/tests/Windows_NT.x64.Debug/Tests/coreoverlay/corerun _il_dbgiface2.exe
coreclr_initialize falló - estado: 0x80004005
Esperado: 100
Reales: 255
FIN DE LA EJECUCIÓN - FALLADO

De acuerdo, según la excelente información de @janvorli , estaba ejecutando parte de mi compilación en versión y parte de mi compilación en depuración. Un vergonzoso error de copiar / pegar. Estoy reconstruyendo ahora.

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

El parche está aquí: https://pastebin.com/d5y9k1tw

Si tiene un parche que corrige una compilación defectuosa, recomendaría enviarlo como una solicitud de extracción para que se solucione para todos :)

Gracias, lo haré. Sin embargo, todavía estoy trabajando para que se ejecuten las pruebas y no estaba seguro de qué estaba causando el error posterior anoche.

Supongo que el soporte "pkg install" de Freebsd 11 para netcore 2.1 (una vez lanzado) no sucederá, ¿verdad?

TLDR; Se ha trabajado mucho, pero es necesario que alguien lo lleve a casa. Escribir el puerto Makefile es la parte fácil.

@wfurt pudo hacer que CLR y FX se construyeran usando Linux, pero en gran parte no fue probado. Pude obtener las partes 'nativas' para compilar en FreeBSD, pero no logré que las partes administradas se compilen en Windows (para FreeBSD). Todo fue un lío de transferir archivos entre sistemas operativos.

Por separado en la lista de correo [email protected] , @dragonsa ha importado una versión binaria de Dot Net Core 1 y toda la cadena de herramientas (msbuild, nuget, etc.) de MintOS usando emulación de Linux. Pude usar sus parches y ejecutar algunas de las herramientas, pero nunca pude construir nada. No estoy seguro de si estos parches se han comprometido todavía; Estaba en medio de revisarlos y cambié de trabajo. No tengo ninguna DotNet en mi puesto actual y estoy mejorando otras cosas en este momento.

¿Qué significa todo eso? Si alguien puede verificar los parches de @dragonsa , puede enviarlos al árbol de ports, entonces es técnicamente posible construir core 2 en FreeBSD de forma nativa. Sin embargo, como puede ver, hay muchas partes pequeñas que deben reunirse y organizarse. Dejé caer la pelota en eso, así que alguien necesita recogerla. Sugiero saltar a la lista de correo [email protected] . https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html

@russellhadley Gracias por la reseña Russell.

Hola,

Hablando de esto con un desarrollador de .NET aquí, estoy dispuesto a ayudar con el desarrollo de un paquete / puerto FreeBSD.

Divulgación completa: no soy un desarrollador de .NET, sin embargo, estoy dispuesto a trabajar con quien sea para incluir esto en el árbol.

~ cy

@cschuber He estado demasiado ocupado para vigilar el estado actual de las cosas, pero como alguien que envió muchos parches de FreeBSD y logró que Hello World funcionara hace 3 años, sería increíble si finalmente pudiéramos ver que esta cosa aterriza correctamente. Tienes todo mi apoyo :)

@cschuber , los problemas activos actuales es https://github.com/dotnet/coreclr/issues/18067. Principalmente, estas cuatro características se dejan https://github.com/dotnet/corefx/issues?q=is : open + label: os-freebsd + label : up-for-grabs + is: issue, entre las que parece estar el vigilante del sistema de archivos el más complicado / laborioso https://github.com/dotnet/corefx/issues/2046.

Gracias por la oferta @cschuber. Estamos casi en el punto en que puede ser posible.
Recientemente hemos estado trabajando con @mateusrodrigues para que .net funcione en FreeBSD y él está tratando de que PowerShell funcione. List @ kasper3 enviado son principalmente características que faltan. Creo que podemos lanzar PNSP por ahora. De mis posibles problemas más urgentes son dotnet / corefx # 30698 y https://github.com/dotnet/coreclr/issues/18481. Sería genial si alguien de la comunidad pudiera profundizar en ellos. No realicé pruebas recientemente, pero me temo que el número de fallas aumentó.
Deberíamos abrir un problema para cada nuevo grupo fallido.

También empiezo a corregir la compilación de fuentes, pero todavía quedan algunos desafíos por delante.
El compilador de c # está escrito en c #. La compilación de .net actual usa la versión anterior de .net para producir ensamblados administrados. También depende de los paquetes de Nuget.
En este momento, tenemos un cli de arranque lo suficientemente bueno como para que podamos construir coreclr, corefx y algunos otros repositorios en FreeBSD. Todavía no actualicé las instrucciones de construcción para reflejar los cambios 2.1 y la compilación de fuentes.

+1 Solo una nota para decir que me alegro de que esto todavía tenga algo de impulso. Es difícil seguir con tantas partes móviles, pero parece que la gente está progresando. Creé https://github.com/dotnet/coreclr/issues/6115 hace un tiempo, pero el proyecto en el que estaba trabajando se suspendió. Realmente espero que sea tan fácil como pkg install dotnet && dotnet build un día (sin compatibilidad con Linux).

También esperando esto

Tenemos construcciones diarias en marcha ahora. Se puede obtener runtime o sdk aquí: https://dotnetcli.blob.core.windows.net/dotnet/Runtime/master/dotnet-runtime-latest-freebsd-x64.tar.gz y
https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-freebsd-x64.tar.gz

También es posible realizar un cross-target, por ejemplo, en Linux o Windows, se puede hacer dotnet publish -r freebsd-x64 y eso crearía una aplicación FreeBSD autónoma.

Todavía está incompleto y sin respaldo, pero debería facilitar la contribución de cualquiera.
Sería genial si la gente pudiera intentarlo, informar problemas.
Además, este sería un buen momento para el impulso final para cerrar la brecha de funciones y corregir errores.

cc: @mateusrodrigues

Buen trabajo, @wfurt y @bartonjs.

Cuando propuse mis primeras confirmaciones de FreeBSD hace unos 2-3 años, en realidad no creía que llegaríamos aquí, pero ciertamente quería intentarlo.

Este es definitivamente un gran hito y, con suerte, facilitará que los nuevos contribuyentes ayuden a terminar el puerto.

Muchas gracias a todos los que nos ayudaron a llegar tan lejos 👍

¡Gran progreso! Todavía estoy luchando con la cadena de herramientas (la mayoría de los proyectos LLVM además de LLDB y LLD están terminados) y la virtualización asistida por hardware para NetBSD (Linux / BSD ahora comienza a arrancar hasta una excepción fatal de VTx, sistemas operativos más simples como FreeDOS ya funcionan) ... así que reanudaré mi portabilidad de NetBSD, con suerte más pronto que tarde. Un mejor soporte de FreeBSD ayudará con un currículum más fácil.

Impresionante :)

Celebramos la borrachera, ¿por qué el ensil bombsrdment?

@krytarowski ¿Puedes desarrollar de qué manera el 'soporte de FreeBSD' puede ser mejor?

Sería genial si algún gurú de FreeBSD pudiera echar un vistazo a https://github.com/dotnet/coreclr/issues/22124 Esperaría que los binarios compilados para 11 se ejecuten en 12, pero no parece ser el caso; (
Es fácil de reproducir con una aplicación simple y la versión 12.0 parece romper algo de lo que depende dotnet.

Hola, no soy un gurú, pero nos encontramos con una regresión de subprocesos en 12-RELEASE en el puerto Lua53.
Vea aquí el error original: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235158
y aquí para el error del sistema base que se identificó: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235211 (tenga en cuenta que el error del sistema base identifica el código que se puede usar para reproducir el problema para comparar).

La solución para Lua es vincular contra -pthread, aunque hay CERO requisito de Lua para -pthread.

gracias @RussellHaley. Eso parece un plomo prometedor.

Me alegro de haber podido ayudar. Me encantaría seguir el juego, pero apenas tengo las pocas horas necesarias para mantener el puerto de Lua. ¡Mantener el buen trabajo!

Como el que arregló la implementación de subprocesos de FreeBSD en coreclr , creo que los pthreads se usan de manera bastante consistente en todas partes, porque eso era lo que tenía que parchear para que la compilación se ejecutara.

Dicho esto, puede haber peros subyacentes y piezas que nunca tuve que tocar y que usan hilos "regulares" ...

¿Quizás alguien más que sepa más sobre la implementación general pueda intervenir? @janvorli ?

Esto me soluciona el problema:

[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

No realicé pruebas exhaustivas, pero al menos puedo ejecutar dotnet nuevamente.

Ok, puedo ver que el ejecutable dotnet no está vinculado con pthreads para otros sistemas que no sean Linux.
https://github.com/dotnet/core-setup/blob/2ef0b64810530961f492c33d37fc7509128e0a9b/src/corehost/cli/exe.cmake#L59 -L61

¿Significa eso que la respuesta para solucionar este problema es tan simple como parece? ¿Es tan simple como esto? https://github.com/josteink/core-setup/commit/25657ba2e181cce401acd7f4bf9d27a08a668470

Si es así, estaré feliz de convertirlo en un PR.

Sí, eso creo. Estaba esperando que @joperator lo confirmara.
No estoy seguro de si también necesitamos "dl", pero eso se puede resolver cuando envíe PR @josteink

Derecha. Mi error. Entonces, más así: https://github.com/josteink/core-setup/commit/a08f38e25a98c25f59c8ed8c8567a0cb08b1c1c6

He creado un PR para ello. Avíseme si necesita alguna enmienda: https://github.com/dotnet/core-setup/pull/5072

Derecha. Mi error. Entonces, más así: josteink / core-setup @ a08f38e

He creado un PR para ello. Avíseme si necesita alguna enmienda: dotnet / core-setup # 5072

Solo para su información, parece que esto ya está parcheado en el sistema base: https://reviews.freebsd.org/D18988

Parece que el problema principal en dotnet / coreclr # 22124 es @wfurt.
Solo tengo un problema cuando intento publicar una aplicación autónoma en FreeBSD 12.0.

Los paquetes oficiales de NuGet freebsd-x64 se han eliminado desde la versión preliminar 2 de .NET Core 3.0 y desde entonces no hemos podido publicar aplicaciones para FreeBSD. ¿Hay planes para volver a habilitarlos en 3.0?

Lamentablemente, tuvimos que restar prioridad a la aparición de FreeBSD (debido a varias razones y dificultades en el soporte de Azure de un extremo a otro) y no será una prioridad en .NET Core 3.0.
Nos encantaría mantenerlo semi-funcionando en el estado donde está ahora, pero no tenemos mucho tiempo para invertir ahora :(.

@karelz Gracias por su respuesta y entiendo el trabajo priorizado de .NET Core 3.0. Entonces me enfocaré en traer mis aplicaciones con la emulación de FreeBSD Linux. :)

@ hjc4869 O puede probar mono. IIRC, admitirá .NET Standard 3.0

Estoy planeando darle otra oportunidad, pero como mencionó @karelz, no es una prioridad para 3.0.

@newsash Mono es una opción aceptable para mí. Sin embargo, me resultó difícil compilar mi proyecto con los objetivos mono agregados a los archivos csproj de .NET Core existentes.

En una máquina Linux, intenté agregar net472 a TargetFrameworks y configurar la variable FrameworkPathOverride, pero eso no funcionó bien. Si consumo una API que está implementada tanto en mono como en .NET Core, pero no en .NET Framework, no se podrá compilar con mono. Además, aunque mono admite .NET Standard 2.1, todavía no pude agregar una referencia a .NET Standard 2.1 dlls en un net472 csproj.

¿Debo agregar un csproj separado y usar mono msbuild en lugar de usar herramientas dotnet, o tiene alguna sugerencia sobre el problema?

Solo un comentario rápido.

Con mono a punto de ser absorbido por .NET 5 según el reciente anuncio [1], proporcionar un soporte decente para FreeBSD se ha vuelto urgente.

Mono ha demostrado tener un soporte multiplataforma realmente bueno y se puede construir sin problemas desde los puertos FreeBSD. Muchas tiendas ejecutan sus cargas .net en FreeBSD ya que este sistema operativo tiene muchas características únicas. Hasta ahora, mono ha estado acortando la brecha, pero con .NET 5 parece probable que en un futuro cercano, mono se fusionará con NET 5 y la comunidad FreeBSD quedará totalmente aislada del ecosistema .NET.

Dotnet debería tener un soporte maduro de FreeBSD mucho antes de que esto suceda.

Creo que Microsoft debería admitir oficialmente FreeBSD en este punto y asegurarse de que todas las herramientas dotnet se construyan en esta plataforma.

@jasonpugsley armó las instrucciones https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD y @joperator está tratando de que la compilación de fuentes funcione https: // github. com / dotnet / source-build / issues / 1139

Tenemos las últimas ~ 30 pruebas que fallan para 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 está mirando System.Diagnostics.Tests.ProcessTests, por lo que fallar las pruebas de bloqueo parece ser la mayor brecha restante. Sería genial si alguien pudiera echar un vistazo a dotnet / corefx # 30899.

¿Me pregunto si hay actualizaciones sobre esto o si está abandonado?

@elfalem , estos días FreeBSD CI leg (que se compila de forma cruzada desde Ubuntu) se está ejecutando en dotnet / runtime PR. Utiliza una imagen de la ventana acoplable de https://github.com/dotnet/dotnet-buildtools-prereqs-docker/ , que tiene todos los requisitos previos instalados. Podemos usar el mismo contenedor de la ventana acoplable para publicar el paquete en tiempo de ejecución (básicamente un tar.gz), localmente o en una máquina remota. por ejemplo, podemos configurar una acción de GitHub en una de nuestras bifurcaciones, algo como: https://github.com/am11/runtime/blob/feature/freebsd/ci/.github/workflows/main.yml , que carga artefactos a las versiones de GitHub en la etiqueta push https://github.com/am11/runtime/releases/tag/6.0.0-dev.freebsd.1. El archivo dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz en este caso tiene suficientes bits para ejecutar una aplicación dotnet publicada (desde un sistema linux / mac diferente, que tiene dotnet SDK). Lo probé creando una nueva VM 12.2 (vagabundo), extraje y copié una aplicación publicada de mac a VM, funcionó:

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

Creo que @Thefrank estaba buscando crear un paquete de puertos FreeBSD adecuado en algún momento.

¿Me pregunto si hay actualizaciones sobre esto o si está abandonado?

es posible que desee ver https://github.com/dotnet/source-build/issues/1139
No lo he intentado recientemente mientras espero a dotNET5 final pero, desde hace unos meses, el tiempo de ejecución de FreeBSD solo se podía construir como una compilación cruzada en Linux. ASPNet y SDK también requerían compilación cruzada de Linux, pero solo se compilaban si las estrellas se alineaban (actualizaciones de arcade o algún otro bot automatizado no rompió una dependencia)

edit: y @ am11 publicó una mejor redacción mientras escribía un paseo nocturno. lee eso y no el mío
edit2: olvidé la puntuación y parece que final se publicó hace 2 días. supongo que debería ponerme a trabajar en eso o algo así

Aparte de todo lo anterior, creé el proyecto FreeBSD en https://github.com/dotnet/runtimelab/ y estoy progresando lentamente en la construcción y publicación de paquetes. El objetivo es compilar y publicar lo suficiente para que la aplicación se ejecute en FreeBSD y tenga semilla para la compilación de fuentes.

Pensé en escribir una actualización rápida. Finalmente logré alinear todos los planetas para construir 5.0.0 RTM en FreeBSD. No me había mantenido al día desde Preview3 y me tomó un tiempo (y _muchos_ intentos de compilación) encontrar la combinación correcta de compilaciones compatibles para obtener un 5.0 exitoso.
He podido construir PowerShell 7.1.0 con sorprendentemente pocos trucos, funciona aunque no lo he probado a fondo, pero parece una buena prueba del SDK.
Acabo de construir AspNetCore, pero todavía no lo he probado.

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

El único problema de hacer este trabajo manualmente (es decir, fuera del sistema de CI) es el problema causado por los cambios rotos que requieren que una compilación en particular esté disponible para la siguiente compilación. No sucede a menudo, pero requiere mucho ensayo y error para encontrar la confirmación correcta. Tener la compilación cruzada de Linux en el sistema CI debería solucionar eso, pero aún no lo he mirado. Aún así, es bueno saber que puedo crear un SDK completo y luego usar ese SDK para crear algo más.

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

Eso es un buen progreso @jasonpugsley. Estoy tratando de encontrar una mejor respuesta para la compilación, pero no pude dedicar una cantidad de tiempo decente en los últimos meses; (
¿PowerShell le dio alguna molestia debido a terminfo o copió la definición de terminal de otro lugar?

Tomé la definición de terminal de mi Mac de donde provenía.

@jasonpugsley estás muy por delante de mí. core y sdk compilados a partir de linux cross freebsd. funciona bien desde las pruebas limitadas que he hecho. ni runtime ni sdk crossbuilts pueden construirse en freebsd (linux y freebsd usan llvm9 y clang9).
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0
Lo tocaré un poco más si tengo más tiempo este fin de semana y también veré si puedo al menos obtener aspnetcore construido en linux para freebsd

@Thefrank , ¿quieres decir?

$ 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

está fallando o los binarios en artifacts/packages/Release/Shipping/dotnet-runtime-5.0.0-dev-freebsd-x64.tar.gz no se ejecutaron?
Si está intentando compilar SDK 5x en Ubuntu 18 o 20, es posible que desee aplicar este parche https://github.com/dotnet/sdk/commit/80e42f16422352f725d78be72071781d8365a238 (está en la rama maestra).

Realmente necesito dejar de hacer publicaciones cuando estoy medio dormido.
La construcción del tiempo de ejecución y sdk se completa en Linux.
Esos binarios se ejecutan en freebsd (dotnet --info, nueva consola y se ejecutan)
Esos binarios no pueden crear un tiempo de ejecución o un sdk desde la fuente en freebsd

Ah, vale. No he intentado modificar los binarios stage0 para reconstruir el tiempo de ejecución en FreeBSD como HostOS.

ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim. exportaciones: 1 : directiva desconocida: V1.0

Podría valer la pena informar este problema por separado. Probablemente hay varias formas de solucionarlo, pero este parche hace alguna diferencia:

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

¿Este parche hace alguna diferencia?

Esperaría que FreeBSD siguiera Linux en lo que respecta a los scripts de versiones de símbolos, no a Darwin. En mi opinión, es más probable que el problema sea que haya algo específico de GNU-awk en generateversionscript.awk

parche cambió el error:
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: _CreateProcessForLaunch
si el problema de la versión awk:

awk --version
awk version 20121220 (FreeBSD)

Si es fácil de experimentar, ¿puede intentar instalar el paquete gawk y cambiar la invocación en los archivos de CMake a gawk?

revirtió el parche. paquete gawk instalado.
Demasiado perezoso para descubrir cómo el script build.sh pasa cmake args ya que no tiene sentido de inmediato, así que simplemente enlacé simbólicamente gawk-> awk.
mismo error original
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0

edición tardía: parece que los binarios en Linux no se compilaron correctamente:

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

principalmente el RID: osx-x64 podría estar causando algunos problemas

principalmente el RID: osx-x64 podría estar causando algunos problemas

El SDK muestra ese RID después de algunas resoluciones de plataformas compatibles y no compatibles. Básicamente, no tiene ningún efecto sobre la ejecución de la aplicación. El RID real detectado por el tiempo de ejecución es correcto; de lo contrario, las aplicaciones (como dotnet(1) ) no se ejecutarán correctamente.
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 en mi caja.

Abierto # 45663 para rastrear el problema de ld. Yo también pude reproducirme.

@Thefrank con respecto al error de ld, intente esto:

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)

Eso activará la cláusula else en eng/native/functions.cmake aquí:

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

Para ser bastante honesto, no soy un experto en enlazadores, así que mientras esto funciona, no miré más a fondo para ver lo que realmente se requería / canónico para clang en FreeBSD.

Ahh, el problema del agente de usuario del vinculador vuelve a aparecer. La cadena de versión de LLD incluye (compatible with GNU linkers) en un intento de seguir la ruta GNU ld de las pruebas de configuración, pero claramente no es lo suficientemente inteligente para este caso :)

La coincidencia en LLD se ve bien aquí, incluso si la bandera LD_GNU ahora tiene un nombre algo incorrecto.

Sí, necesita más trabajo. El nombre de la bandera ahora es confuso. Por favor, nadie intente cometer esto como está.

De: Ed Maste [email protected]
Enviado: lunes 7 de diciembre de 2020 10:26:48 a.m.
Para: dotnet / runtime [email protected]
Cc: Jason Pugsley [email protected] ; Mencione menció[email protected]
Asunto: Re: [dotnet / runtime] Soporte para FreeBSD (# 14537)

Ahh, el problema del agente de usuario del vinculador vuelve a aparecer. La cadena de versión de LLD incluye (compatible con enlazadores GNU) en un intento de ir por la ruta GNU ld de las pruebas de configuración, pero claramente no es lo suficientemente inteligente para este caso :)

La coincidencia en LLD se ve bien aquí, incluso si la bandera LD_GNU ahora tiene un nombre algo incorrecto.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/dotnet/runtime/issues/14537#issuecomment-739583816 , o cancele la suscripción https://github.com/notifications/unsubscribe-auth/AECFDEXKTDFRAX4ZEE6VXZTSTQHLRANCNFSM4TS .

Opté por usar https://github.com/dotnet/runtime/pull/45664
Clr se acumula en el subconjunto Clr.Tools y luego falla con

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

el subconjunto "mono" y el subconjunto "libs" se completan sin errores

@Thefrank Es la segunda parte de esta diferencia que necesitas para solucionar ese problema:

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>

Podría ser mejor agregarlo a la línea LINUX como un OR en la condición.

@jasonpugsley que hizo el truco!
/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):
¡Sabía que me olvidé de hacer algo hace unos días! Esto debería ser interesante

editar: sin crossgen (también conocido como solo la segunda mitad)

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

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

Time Elapsed 00:12:05.56

editar la última edición en esta publicación, lo juro:
Sé que las pruebas pueden llevar un tiempo y dice una prueba de larga duración, pero esto se está yendo de las manos para una prueba.
System.Net.HttpListener.Tests: [Long Running Test] 'System.Net.Tests.HttpListenerResponseTests.AddLongHeader_DoesNotThrow', Elapsed: 00:36:20

eliminó la prueba después de esperar 2 horas, otras pruebas todavía tenían fallas

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