Runtime: Suporte para FreeBSD

Parece haver acordo no que diz respeito a https://github.com/dotnet/corefx/issues/1576 .

Quando também tivermos uma decisão sobre https://github.com/dotnet/corefx/issues/1625 , devemos poder começar a enviar algum código.

O acordo sobre dotnet / runtime # 14536 foi alcançado pelo portteam, a menos que a MSFT escolha o contrário, será FreeBSD . O problema dotnet / corefx # 1999 será potencialmente o problema que introduz a definição na API pública.

Acordo sobre dotnet / runtime # 14536 foi alcançado pelo portteam, a menos que MSFT escolha de outra forma, será FreeBSD

Se eu li isso direito, isso significa que quando https://github.com/dotnet/corefx/pull/1999 for mesclado, podemos considerar esta aprovação MSFT da nova API pública e, portanto, podemos avançar nas questões restantes com solicitações pull regulares sem necessidade de aprovação MSFT.

Se sim, isso parece bom para mim.

As próximas etapas de acordo com https://github.com/dotnet/corefx/pull/1999#issuecomment -111279577 são:

1. A "equipe de portes do FreeBSD" continua seu trabalho para obter uma versão FreeBSD do CoreFX produzida (monitorado por dotnet / corefx # 1626).
2. A equipe do port traz o suficiente da pilha CoreFX e CoreCLR no FreeBSD para que possamos começar a executar os testes de unidade CoreFX no FreeBSD.
3. Os testes alcançam algum nível mínimo de qualidade. Não sei exatamente o que isso parece ainda, mas espero que signifique algo como a maioria dos testes passa. Idealmente, não teríamos um monte de testes específicos desabilitados apenas para FreeBSD (em comparação com Linux e OSX, não gostaríamos de manter o FreeBSD em um padrão mais alto do que as outras plataformas * NIX que temos lá).
4. Trabalhando com a equipe de portes do FreeBSD, a equipe do CoreFX obtém os testes do CoreFX adicionados ao nosso sistema CI em execução no FreeBSD.
5. Discuta a fusão de um PR com base no problema dotnet / runtime # 14536, que adiciona a propriedade.

Isso me parece um plano totalmente razoável.

Ok, então vamos começar o trabalho de fazer o corefx funcionar.

O primeiro obstáculo na construção do corefx no FreeBSD parece ser mono. O script de construção insiste que a versão 4.1 é necessária. @ajensenwaud trabalhou nisso no anfitrião de Frankfurt, mas não tenho certeza de quão completo é.

Vou enfileirar uma compilação por agora e ver como fica a saída.

Editar: A compilação (mono) trava com o seguinte kicker no 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.

O primeiro obstáculo na construção do corefx no FreeBSD parece ser mono

FWIW, eu pessoalmente não acho que este seja o primeiro obstáculo. Existem dois problemas relacionados à construção:

1. Construindo assemblies que funcionam corretamente no FreeBSD
2. Construindo esses assemblies no FreeBSD

(1) é fundamental, e acredito sobre o que se trata esse problema. (2) é muito bom ter, mas a falta dele não impede a criação de um grande sistema para executar código gerenciado no FreeBSD.

É claro que você é livre para priorizar como achar adequado, mas minha recomendação seria focar em (1) em vez de (2).

Observe que ainda temos problemas para construir corefx no Linux e construí-lo no OSX, de forma que nosso sistema de CI constrói os assemblies para essas plataformas no Windows; ele então transporta os assemblies resultantes para a plataforma de destino para executar os testes.

Isso é bastante justo. Eu apenas presumi que seria mais fácil obter o suporte geral da plataforma FreeBSD incorporado ao corefx se pudéssemos construí-lo nós mesmos no FreeBSD.

Por enquanto, vou me contentar com a construção iniciada pelo Windows e tentarei criar uma configuração de construção ninja.

@josteink btw. corefx agora deve ser construído em Mono 4.0.1.44.

@akoeplinger Nice. Isso me deixa com alguma esperança de que possamos colocá-lo em execução no FreeBSD também :)

Bons pontos. No entanto, se realmente quisermos que o corefx faça parte do ambiente FreeBSD, realmente precisamos que ele seja capaz de compilar a partir do código-fonte para colocá-lo no sistema de Ports.

Ouvi dizer que o Mono 4.0.1.44 corrige muitos desses problemas, mas ainda não tive tempo de brincar com ele. Eu sei que a equipe do ports está atualizando o Makefile do port, assim como falamos com um novo patch.

Em 12 de junho de 2015, às 20:21, Stephen Toub [email protected] escreveu:

O primeiro obstáculo na construção do corefx no FreeBSD parece ser mono

FWIW, eu pessoalmente não acho que este seja o primeiro obstáculo. Existem dois problemas relacionados à construção:

Construindo assemblies que funcionam corretamente no FreeBSD
Construindo esses assemblies no FreeBSD
(1) é fundamental, e acredito sobre o que se trata esse problema. (2) é muito bom ter, mas a falta dele não impede a criação de um grande sistema para executar código gerenciado no FreeBSD.

É claro que você é livre para priorizar como achar adequado, mas minha recomendação seria focar em (1) em vez de (2).

Observe que quase não temos corefx build-on-Linux e build-on-OSX, de modo que nosso sistema de CI constrói os assemblies para essas plataformas no Windows; ele então transporta os assemblies resultantes para a plataforma de destino para executar os testes.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Sim, não estou de forma alguma discordando ... ser capaz de _build_ corefx no Linux, OSX e FreeBSD é importante. Estou simplesmente sugerindo que, de uma perspectiva de prioridade, é mais importante ser capaz de realmente _run_ corefx no Linux, OSX e FreeBSD. : wink: Se ambos puderem ser trabalhados em paralelo, tanto melhor.

@ghuntley ,
seria super: legal: se tivéssemos uma lista de verificação de tarefa de marcação descrevendo o que resta:

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

renderiza como:

• [] tarefa 1
• [] tarefa 2
• [] tarefa 3

Isso provavelmente irá encorajar outros a marcarem esses talentos e o suporte do FreeBSD chegará antes do previsto! :oculos escuros:

Pelo que sei, as seguintes peças de trabalho no CoreFX são necessárias para o suporte do FreeBSD:

• [x] Apresente a plataforma FreeBSD às ferramentas e scripts de construção. (Feito por @josteink e eu, PRs dotnet / corefx # 2021 mesclado, dotnet / corefx # 2030 mesclado)

13 Assemblies não compilam por conta própria e precisam de mudanças específicas do FreeBSD. Principalmente as peças de interoperabilidade que já existem para Linux / OS X (ordem pela ocorrência na saída da compilação):

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

Tentarei atualizar essa lista com base nos PRs abertos e mesclados.

Para sua informação: PR dotnet / corefx # 2039 mesclado

Apenas tentando estar à frente da curva aqui ... Como planejamos implementar System.IO.FileSystem.Watcher ?

O Iirc FreeBSD não tem inotify como o Linux e o Windows (que também é o motivo pelo qual não há Dropbox da última vez que verifiquei). Isso será uma fonte potencial de problemas vindo em nossa direção? Ou alguém tem uma ideia de como contornar isso?

Eu sugiro que retiremos isso por enquanto e lancemos uma PlatformNotSupportedException como Stephen Toub sugeriu no outro tópico (https://github.com/dotnet/corefx/pull/2021#issuecomment-111602342). Então, temos pelo menos um conjunto completo de assemblies e podemos continuar a trabalhar nesse problema específico sem bloquear as próximas etapas.

Você se importaria de abrir uma edição separada para isso?

Vamos mover System.IO.FileSystem.Watcher discussões para dotnet / corefx # 2046

Gente, existe algum bloqueador para System.Diagnostics.Process ?

@ jasonwilliams200OK adicionou o FreeBSD ao S.RT.I.RI no início desta manhã, que foi mesclado, mas os testes do FreeBSD em CheckPlatformTests tiveram que ser cancelados até que dotnet/buildtools fosse atualizado.

• [] Atualizar ferramentas de compilação para suportar FreeBSD - https://github.com/dotnet/buildtools/pull/180
• [] Reaplicar testes de [Fact,PlatformSpecific(PlatformID.FreeBSD)] a CheckPlatformTests - consulte https://github.com/dotnet/corefx/pull/2068#discussion_r32570244 e https://github.com/dotnet/corefx/pull/2068#discussion_r32570244
• [] Adicione public static OSPlatform FreeBSD a https://github.com/dotnet/corefx/pull/2068

@ jasonwilliams200OK houve algumas discussões ontem à noite sobre System.Diagnostics.Process no gitter que foram formalizadas em https://github.com/dotnet/corefx/issues/2070

@ghuntley , obrigado. Na verdade, li essas mensagens. System.Diagnostics.Process é complicado. A equipe de AFAIK e io.js teve desafios semelhantes com o gerenciamento de processos do FreeBSD. A equipe Mono provavelmente acertou em cheio , então vamos esperar que

System.IO.FileSystem.DriveInfo

Conforme discutido no gitter, para este eu tentei examinar o 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);
  }
}

A execução dessa amostra gerou esta saída:

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

Portanto, parece que ele faz o que precisamos. A questão é: devemos fazer algum tipo de filtragem nos resultados?

Olhando para a "intenção" do objeto DriveInfo , vindo do mundo Windows do .NET, muitas vezes tem sido enumerar os locais disponíveis para armazenar ou recuperar arquivos ( C: , D: , etc). Mas ao usar sistemas de arquivos hierárquicos Unix, retornar / seria adequado para cobrir essas necessidades.

Então, o que devemos devolver? O que seria útil? Deveria mesmo considerá-lo útil ou não?

A versão Linux simplesmente despeja tudo, exceto coisas definidas para serem ignoradas:

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

Tentei colocar o seguinte filtro, mas realmente não mudou nada em termos de saída:

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

Alguma opinião?

@josteink , ótimas escavações! Com base em https://github.com/dotnet/corefx/issues/815#issuecomment -113825960 e https://github.com/dotnet/corefx/issues/1729 , acho que devemos colaborar com @sokket para chegar a uma solução que funciona em diferentes Unices.

Eu tenho uma versão em execução no OSX que usa getmntinfo e statfs para obter informações sobre cada ponto de montagem, o que parece ser o mapeamento mais lógico do conceito de Windows Drive. Vou verificar se as definições de função e estrutura no OSX correspondem às definições do FreeBSD e, se for o caso, meu commit para o OSX também funcionará para o BSD.

Com certeza vou adicionar você ao meu PR @josteink

Soa bem. Obrigado pelo aviso e obrigado por dar um pouco de amor ao FreeBSD também.

Eu pesquisei algumas pinvoke básicas para essas funções, e parece que precisamos fazer todo o empacotamento e conversões nós mesmos, então, se alguém já se esforçou, quem sou eu para dizer não? ;)

Sem problemas ... parece que a principal diferença era com as declarações de estrutura; já que provavelmente iremos bater mais nisso no futuro, estou fazendo algumas refatorações que nos permitirão compartilhar muitas das assinaturas do PInvoke. Vou adicionar uma descrição maior em meu PR (hoje ou amanhã, com base em como o teste é executado), mas basicamente adicionei as assinaturas PInvoke e as assinaturas de estrutura para o FreeBSD (com base nos cabeçalhos que encontrei online) e ele compila. Eu testei no Mac, então ele _deve_ (em teoria ...) funcionar no FreeBSD, já que é apenas uma mudança na declaração da estrutura, mas sua milhagem pode variar :). Caso contrário, você terá a classe DriveInfo e PInvokes 99% do caminho até lá e só precisará de alguns ajustes com base nas nuances do FreeBSD.

Excelente notícia @sokket. Criei uma conta para você na máquina que o time de portas usa para desenvolvimento, é baseada na Europa, mas está sempre ligada e tem muita memória e poder de processamento. Esperançosamente, isso ajudará e removerá alguns dos atritos ao trabalhar com o FreeBSD.

# ssh [email protected]

A autenticação de senha está desabilitada, use uma de suas chaves .

@josteink veja também o problema: https://github.com/dotnet/corefx/issues/815 (System.IO.FileSystem.DriveInfo para Mac / FreeBSD)

Existem atualizações? Alguém implementou os assemblies restantes no FreeBSD?

Tenho estado ocupada cuidando do meu novo bebê, não tive tempo para qualquer codificação em qualquer lugar.

Suspeitei que questões como essas estivessem latentes e acho que isso confirma até certo ponto.

Para os assemblies que ainda não foram implementados, vinculei a questão "como implementar" na lista acima. Espero que ajude a coordenar os esforços para implementar essas assembléias restantes.

Devo admitir que estava tendo dificuldade em acompanhar o que tínhamos feito e onde, então essa é definitivamente uma boa jogada. Bom trabalho :)

Onde encontro isso? Seria gratificante obter as assembleias restantes
implementado.

Em 25/07/15 22:10, Jan Henke escreveu:

Para os assemblies que ainda não foram implementados, vinculei o "como
para implementar o problema "na lista acima. Espero que ajude a coordenar
o esforço para fazer com que esses assemblies restantes sejam implementados.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment -124838781.

Este comentário aqui: https://github.com/dotnet/corefx/issues/1626#issuecomment -111800540

No momento, estou esperando que os shims nativos sejam finalizados, pois eles devem assumir a maior parte do trabalho de fazer com que esses assemblies funcionem no FreeBSD.

@nguerrera seria ótimo se você pudesse nos manter informados sobre o progresso. :)

Atualizar:
@janhenke confirmou que com https://github.com/dotnet/corefx/pull/2974 mesclado, System.IO.Pipes constrói no FreeBSD! :oculos escuros:

Atualizar:
dotnet / corefx # 2527 fechado, System.IO.MemoryMappedFiles compila no FreeBSD.
Obrigado @janhenke pela confirmação!

Graças à abordagem dos shims, tudo se resume a garantir que os shims compilem no FreeBSD. Felizmente, isso torna a vida muito mais fácil. :)

dotnet / corefx # 3257 deve nos trazer System.Diagnostic.Process e System.IO.FileSystem.Watcher deixando apenas System.Net.NameResolution sem solução. (Vou verificar as duas montagens mencionadas assim que o PR for mesclado e funcionar no FreeBSD)

dotnet / corefx # 3471 deve nos trazer System.Net.NameResolution e completar a lista acima.

dotnet / corefx # 3471 acabou de ser fundido :)

@sokket , obrigado pela atualização. Criei o master (f467911) no FreeBSD usando este guia: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24. O bloqueador atual é https://github.com/dotnet/buildtools/issues/292, que foi corrigido no upstream, mas aguardando a próxima implementação do buildtools. :)

Atualização: o novo buildtools com correção para dotnet / buildtools # 292 foi lançado no CoreFX master. A próxima parada do buildtools é https://github.com/dotnet/buildtools/issues/300 : ferramenta específica do sistema operacional ausente para poder executar os testes.

@janhenke , você marcou System.Diagnostics.Process (# 2070) e System.IO.FileSystem.Watcher (# 2046) como concluídos; mas eles não são implementados nem compilados no FreeBSD. Você realmente verificou a lista compilando o código gerenciado?

Com base em minha experiência recente com commit 60c78da3c918b0d256cc1f878de06d351dbe3342 (consulte msbuild.log ), os seguintes assemblies não compilam:

• System.Diagnostics.Process
• System.Diagnostics.ProcessManager
• System.Diagnostics.ThreadInfo
• System.IO.FileSystemWatcher
• System.Net.SocketAddress _ (tudo bem, este foi adicionado recentemente) _

Pelo que me lembro, verifiquei a compilação dos shims associados. Uma vez que o código gerenciado deve estar livre de código específico do FreeBSD. Essas correções que você mencionou deveriam ter sido eliminadas com os PRs vinculados acima.
Mas também executei uma compilação completa no meio. No mínimo System.Diagnostics.ThreadInfo e System.IO.FileSystemWatcher compilaram. Portanto, algo deve ter regredido.

Essas correções que você mencionou deveriam ter sido eliminadas com os PRs vinculados acima.

Na verdade, PR https://github.com/dotnet/corefx/pull/3257 não está relacionado ao shim. Ainda há algum código PAL nos projetos gerenciados (a abordagem antiga), portanto, é necessário construir assemblies gerenciados para ter certeza absoluta.

Na verdade, PR dotnet / corefx # 3257 não está relacionado ao shim.

Discordo. Ele está refatorando o código P / Invoke para o shim System.Native. Além disso, como editei acima, estou relembrando pelo menos algumas das assembleias compiladas entre eles.

discordo

https://github.com/dotnet/corefx/pull/3257/files : veja as instâncias de .Unix.cs e .Linux.cs para System.Diagnostics. . Observe que .OSX.cs foi alterado.

Ele está refatorando o código P / Invoke para o System.Native shim

Sim, ele refatora alguns auxiliares comuns em System.Native , mas não System.Diagnostics.* et al.

Mesmo quando esses assemblies são apenas P / Invoking to System. * Libs, ainda pode haver trabalho FreeBSD necessário para alguns deles, por exemplo, System.Diagnostics.Process e System.IO.FileSystem.Watcher. Eles estão usando funcionalidades específicas para Linux e OS X e não planejamos abstrair isso por trás de shims nativos. O objetivo dos shims não é terminar com um único binário gerenciado para Unix, embora essa seja uma propriedade muito boa quando se trata do trabalho; o objetivo principal é evitar diferenças de ITB que causam fragilidade. Espero que pelo menos um punhado de assemblies continuará a ter binários específicos do Linux / OS X, onde um binário do FreeBSD também seria necessário.

Para sua informação, não há assemblies corefx chamados System.Diagnostics.ProcessManager,
System.Diagnostics.ThreadInfo,
System.IO.FileSystemWatcher ou
System.Net.SocketAddress. Esses são tipos em outras montagens.

Espero que pelo menos um punhado de assemblies continuará a ter binários específicos do Linux / OS X, onde um binário do FreeBSD também seria necessário.

Isso significa que sempre que Solaris e não glibc (musl e μlibc) direcionados ao Linux, como o suporte da Alpine, chegarão, eles terão binários separados? E então, diferentes arquiteturas ARM, MIPS, RISC, SPARC etc. exigiriam outro nível de separação?

Não faria sentido convergi-los para a interface POSIX / sys-calls o máximo possível e detectar as diferenças usando configs (via CMake) para serem usados ​​no mesmo binário (a menos que esteja afetando o tamanho / desempenho do assembleias significativamente)? Pelo que entendi, System.Native.so binário tem um auxiliar comum para outro System.*.Native.so que parece suficiente para o cumprimento do princípio de separação de interesses. Mas se for transformado em System.Net.Http.FreeBSD.ARM.Native.so ou System.Net.Http.Solaris.SPARC.so , então será totalmente incontrolável com "muitas peças móveis" etc.

não há assemblies corefx nomeados

Bom ponto. Na verdade, eu estava examinando as instâncias de falhas nos logs do msbuild e o número de .OSX.cs e .Linux.cs arquivos. :sorriso:

Não faria sentido convergi-los para interface POSIX / chamadas sys tanto quanto possível

Nós fazemos. Como você propõe fazer um bom monitoramento de arquivos via POSIX? Como você propõe que processemos bem a enumeração via POSIX?

Mas se ele for transformado em System.Net.Http.FreeBSD.ARM.Native.so ou System.Net.Http.Solaris.SPARC.so, então será bastante incontrolável com "muitas partes móveis" etc.

Eu não entendo isso. O ponto principal dos arquivos .so nativos é que você obtém binários nativos diferentes para cada plataforma de destino, mas eles não são chamados de System.Whatever.Platform.ext, apenas System.Whatever.ext; que permite ao compilador pegar a mesma lógica geral e usá-la com as definições específicas para aquela plataforma. Isso só funciona quando os mesmos símbolos existem em cada plataforma; o compilador não pega magicamente o código escrito para usar o inotify e permite que ele funcione com a interface de observação de arquivos de algum outro sistema. Em geral, tentamos usar APIs padronizadas onde faz sentido, mas para locais onde essas APIs não existem ou não são bem padronizadas ou onde há melhores soluções específicas de plataforma, usamos a melhor plataforma- soluções específicas, por exemplo, usando procfs para enumeração de processos no Linux, usando inotify para monitoramento de sistema de arquivos no Linux, etc. perspectiva de plataformas adicionais, como quando essas novas plataformas surgem, se as APIs existentes funcionam, a solução existente também funciona e, se não funcionar, você precisa escrever uma nova solução para essa plataforma. E, portanto, tentamos fazer o máximo possível em código gerenciado, usando nativos simplesmente para os shims 1: 1 que tornam esse código gerenciado muito mais portátil onde as APIs de destino são portáteis. Usamos #ifdefs no código nativo para encobrir pequenos detalhes, onde esta API em qual plataforma é próxima o suficiente daquela API em outra plataforma, mas isso não se estende a soluções inteiras sendo completamente diferentes; nesse ponto, a abstração se torna a API gerenciada e fazemos uma implementação gerenciada diferente para cada sistema.

Se o FreeBSD expõe o inotify como o Linux faz ou se expõe o EventStream como o OS X faz, então quando as APIs do sistema operacional estão por trás do shim, o shim pode facilmente ser feito para funcionar com o FreeBSD, e o mesmo binário gerenciado pode ser usado no FreeBSD. Se o FreeBSD não expõe tais APIs, você precisará escrever uma implementação personalizada de System.IO.FileSystem.Watcher com alguma solução de monitoramento de arquivos que está disponível no FreeBSD. Comentários semelhantes para System.Diagnostics.Process. Se o código para a observação de arquivos está na correção ou não, isso tem pouco impacto.

O plano é que todas essas APIs nativas sejam movidas para trás do shim. Mas eles estão longe de ser uma prioridade, já que não são muito portáteis, e você nos viu começando com APIs da libc que estão (ou deveriam estar) expostas em todos os lugares.

Como você propõe fazer um bom monitoramento de arquivos via POSIX?

Não podemos fazer tudo POSIX, já que o inotify é específico do Linux. O FreeBSD / OSX oferece implementações separadas.

Proposta:

Do ponto de vista da distribuição de binários nativos, cada SO deve receber um conjunto igual de binários com os mesmos nomes, mas com funcionalidades diferentes.

Aqui está uma estrutura proposta:

# 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

Isso é essencialmente o que temos, por exemplo

• "common_function_for_posix_compliants" são funções nativamente ajustadas de 1: 1 consumidas da lógica em um binário gerenciado pelo Unix compartilhado
• função "ligeiramente_diverged" são nativamente shimmed quase 1: 1 funções com alguns #ifdefs nativos consumidos da lógica em um binário gerenciado Unix compartilhado
• "painfully_diverged_watch_function" são / serão nativamente shimmed funções 1: 1 consumidas da lógica em binários gerenciados específicos da plataforma

A diferença real é se o código que implementa a lógica "dolorosamente divergente" é feito em C # ou C ++, e escolhemos C # e já está tudo implementado em C #. Não vi nenhum argumento convincente para explicar por que, nesses casos, reescrever tudo para C ++ seria uma opção significativamente mais convincente.

@ jasonwilliams200OK Com a atualização de hoje para mono, eu construo o corefx no próprio FreeBSD novamente. Há muitas mensagens de erro novas desde a última vez que o criei.
Eu estou me perguntando se Interop.Libc irá embora eventualmente?

@stephentoub Tudo se resume à embalagem. Ter todo o código específico da plataforma na parte nativa tem o benefício de ter um assembly gerenciado para todas as plataformas do tipo Unix.
Além disso, acredito fortemente que precisamos de uma implementação genérica para esses "código gerenciado dependente da plataforma. Mesmo que apenas lance uma NotImplementedExcpetion. Dessa forma, você pode portar muito mais facilmente para novas plataformas, se pelo menos compilar tudo imediatamente. Também daria a chance de pelo menos tentar rodar em uma plataforma sem suporte.
Geralmente é muito mais fácil se você pode pelo menos compilar com sucesso imediatamente.

@stephentoub , desculpe, eu estava misturando C ++ com C #. Agora eu entendo que a camada nativa está apenas expondo esses pontos de entrada (funções de libs nativas ou syscalls) e higienizando o IO e o código gerenciado é onde decidimos qual método de utilitário empacotado específico da plataforma / syscall empacotado a ser consumido. Além disso, ambas as camadas (nativa e gerenciada) não podem ser agnósticas do SO, onde funcionalidades não POSIX devem ser consumidas.

@janhenke , eu concordo. Eu também estou construindo mestre enquanto falamos. Há outro problema recorrente de assinatura de montagem, estou atingindo:

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]

postará o link msbuild.log gist completo em breve.

Além disso, acredito fortemente que precisamos de uma implementação genérica para esses "código gerenciado dependente de plataforma.

Eu concordo. Em vez de classes parciais, provavelmente podemos usar herança com métodos virtuais comuns e principalmente comuns em classe base abstrata e substituir "principalmente comum / parcialmente diferente" quando necessário. Em seguida, implemente métodos abstratos que são totalmente diferentes para cada sistema operacional. Com esta abordagem IMO, se onde a especialização / generalização está perdendo DRY'ing, podemos empregar ancestralidade de herança de vários graus. Mas da última vez que verifiquei, classes parciais eram preferidas à associação pai-filho no CoreFX (por algum motivo que não me lembro). :)

Aqui está o msbuild.log para o commit 2d36889:

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

/ cc: @akoeplinger

@ jasonwilliams200OK Por que tão complicado. Tudo o que precisa é uma condição "senão Windows, Linux, OS X" nos arquivos do projeto. Portanto, inclua um conjunto de arquivos específico da plataforma na construção ou os genéricos.

Não acho que o fato de alguns assemblies não poderem construir / funcionar para o FreeBSD deva ser um grande bloqueador para testar o resto deles. Provavelmente deveríamos apenas fazer com que aqueles com trabalho pendente (FileSystemWatcher, Process, Networking) sejam ignorados na construção e execução de teste no FreeBSD. Então, podemos trazê-los individualmente, enquanto temos um processo para evitar a regressão do que já funciona.

Eu não acho que o fato de alguns assemblies não poderem construir / funcionar para o FreeBSD ainda deva ser um grande bloqueador para testar o resto deles

Concordou

Provavelmente deveríamos apenas fazer com que aqueles com trabalho pendente (FileSystemWatcher, Process, Networking) sejam ignorados na construção e execução de teste no FreeBSD

Ou semelhante ao que @janhenke sugeriu, apenas permita que eles construam, seja removendo com arquivos que lançam PlatformNotSupported, ou apenas mapeando o FreeBSD para um dos casos que funcionam, por exemplo, se o FreeBSD for escolhido, apenas construa o Linux ( não vai funcionar, mas vai construir).

Com as alterações recentes de @ellismg (# 3684), posso executar testes simplificando o método anterior (https://github.com/dotnet/coreclr/issues/1633#issuecomment-143669303):

• Após https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 (especialmente a etapa para construir shims nativos separadamente _após_ a saída build.sh com status 1), baixe o arquivo zip dos cd /root; curl -o bins.zip "http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/debug_freebsd/lastSuccessfulBuild/artifact/*zip*/archive.zip (não se esqueça as aspas em torno de URL) e unzip bins.zip; chmod -R 0777 archive/; rm bins.zip; cd corefx .

(nada necessário da máquina Windows)

• Fiz o teste:

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

Diz:

40 teste (s) falharam

Não acho que o fato de alguns assemblies não poderem construir / funcionar para o FreeBSD deva ser um grande bloqueador para testar o resto deles.

Eu tenho que concordar com este. É melhor iniciar o controle de qualidade do trabalho que fizemos, em vez de esperar que tudo seja concluído antes de iniciar o teste.

Diz: 40 teste (s) falharam

40 de quantos? Em que estádio estamos? :)

40 de quantos? Em que estádio estamos? :)

me bate também. Os testes estão surgindo de assemblies de teste (dlls gerenciados) e o número total de testes não é visível.

O número que o script produz no final é o número de assemblies de teste que falharam. O xUnit deve gravar o número de testes que falharam por montagem no stdout como parte de sua execução. Os números também devem estar nos arquivos XML produzidos em cada pasta de montagem de teste.

Pode ser que o tempo de execução também esteja travando e, nesse caso, pode não haver logs produzidos por montagem de teste.

@ jasonwilliams200OK Você sabe se houve algum progresso na questão da assinatura da montagem? Estou acertando a mesma coisa no Ubuntu. Se ninguém está trabalhando nisso, talvez devêssemos abrir uma edição separada para isso.

@naamunds , que foi corrigido no CoreFX master como parte de https://github.com/dotnet/corefx/issues/3739.

Atualização - Hoje eu executei testes no FreeBSD, milhares deles estavam passando e alguns falhando devido à óbvia falta de System.Diagnostics.Process e amigos snafu. Após cerca de 40 minutos de execução bem-sucedida, ele travou os testes System.IO.FileSystem (por cerca de 15 minutos antes de eu pressionar Ctrl + C para encerrar).

@ jasonwilliams200OK como você conseguiu compilar o corefx no freebsd? Estou preso a erros sobre gssapi

@sec , no momento de fazer essas anotações: https://gist.github.com/jasonwilliams200OK/6efa7907e66275df2d24 , GSSAPI não era exigido pelo CoreFX. No entanto, parece que o pacote foi recentemente portado para o FreeBSD: http://www.freshports.org/security/p5-GSSAPI. Você pode querer tentar pkg upgrade pkg && pkg update && pkg install p5-GSSAPI .

@ jasonwilliams200OK , Eu já tenho isso (é perl ext. btw.) Problema estava faltando gssapi_ext.h. O truque era fazer "pkg install krb5" - agora compilado de forma nativa.
Eu os copiei para coreclr runtime, mas ainda não consigo executar o aplicativo ASP.NET Core :) a luta continua então.

Qual é o status atual desta tarefa? A lista de @janhenke é completa e precisa? Todo o trabalho que precisa ser feito está concluído? Então deve ser fechado, certo?

Se sim, por que ainda temos essa tarefa? https://github.com/dotnet/corefx/issues/2070

Se ainda houver trabalho a ser feito, um novo problema deve ser registrado com base no estado atual das coisas?

Acho que também é necessário - dotnet / corefx # 2046

deve um novo problema ser registrado com base no estado atual das coisas?

Sim: +1:

Discutimos o porte da comunidade para o FreeBSD com @RussellHaley (da comunidade do FreeBSD) e @wfurt (da equipe do .NET Core), que expressaram interesse no trabalho.
Aqui está uma proposta de plano que elaboramos (comentários / sugestões são bem-vindos):

1. Produza binários no repositório CoreCLR e CoreFX visando o FreeBSD - usar hacks não tem problema
   
   
   
   • Difícil de paralelizar, @wfurt funcionará nisso
   
   
   • A compilação pode ser uma mistura de compilações de outras plataformas (Mac, Linux) visando o FreeBSD
   
   
   • Precisaremos de etapas documentadas (no wiki do FreeBSD) para reproduzir a construção com correções de bugs específicos do FreeBSD
   
   
2. Executar e estabilizar testes CoreCLR (usando corerun)
   
   
   
   • Os testes podem ser construídos em outra plataforma
   
   
   • Objetivo: Fornece qualidade básica de tempo de execução
   
   
3. Executar e estabilizar testes CoreFX (usando corerun)
   
   
   
   • Os testes podem ser construídos em outra plataforma
   
   
   • Observe que isso requer xunit. Acreditamos, com base em nossa experiência de portabilidade anterior, uma vez que [2] estiver pronto, o xunit funcionará.
   
   
   • Isso pode ser, em teoria, paralelizado com [2] - pode exigir o atalho xunit (por exemplo, gerar receita de execução estática em outra plataforma)
   
   
4. Full stack build on FreeBSD (usando corerun como bootstrapper de [1] - [3])
   
   
   
   • Precisaremos de todas as ferramentas (nuget, msbuild, roslyn) para trabalhar no boostrapping do .NET Core
   
   
5. Instaladores (portas FreeBSD)
   
   
   
   • Primeiro estágio: usando binários de produto de feeds nuget
   
   
   • Segundo estágio: Construir produto da origem (bloqueado na construção desde o esforço de origem)
   
   
   • Requer experiência da comunidade FreeBSD e orientação sobre design
   
   
   • Nota: Podemos vincular pacotes do FreeBSD também das páginas oficiais de download do .NET Core como pacotes de suporte à comunidade
   
   
6. Compilação regular e testes de execução no FreeBSD
   
   
   
   • Objetivo: certificar-se de que as alterações nos repositórios do .NET Core que quebram o FreeBSD sejam conhecidas o quanto antes
   
   
   • Design necessário
   
   
   • Requer experiência da comunidade FreeBSD e orientação sobre design
   
   

Princípios de operação:

• As alterações em [2] - [4] devem ser feitas principalmente nos repositórios CoreCLR / CoreFX (devido aos requisitos de assinatura do CLA, revisões de código de especialistas / membros da equipe .NET Core etc.)
• Acompanharemos o trabalho de alto nível nessa questão. Bugs específicos serão arquivados como problemas separados.

Se alguém estiver interessado em ajudar, por favor nos informe aqui. Podemos distribuir facilmente itens de trabalho de [2] e [3] acima, uma vez que estivermos longe o suficiente com [1].

A versão mais recente da proposta está no topo desta edição.

Marcando mais pessoas que expressaram interesse na lista freebsd-mono ( este tópico ): @smortex @radovanovic @ Echo-8-ERA

BTW: Não consigo encontrar a conta Mathieu Prevot GitHub - [ATUALIZAÇÃO] Encontrado em https://github.com/dotnet/corefx/issues/1626#issuecomment -330348424: @mprevot

Para NetBSD, sentimos falta de mutexes robus posix, este é o único recurso que ainda está faltando para produzir mutexes robus nomeados. Agora podemos depurar falhas de código gerenciado com LLDB / NetBSD .. funciona bem com arquivos principais. Em minhas tentativas anteriores morremos pela falta desse recurso no LLDB (comecei a portar este depurador para .NET).

Ter um melhor suporte ao FreeBSD ajudará significativamente.

Também houve problemas no passado com a falta de suporte de convidado de hyperv para anexar um buildbot do NetBSD a máquinas CI e verificar patches ... para isso, posso precisar da ajuda da MS. Imagino que seja necessário software proprietário para executá-lo, que não é meu ... Posso encontrar um desenvolvedor para fazer o trabalho se houver interesse conjunto (investimento) entre a Fundação NetBSD e a Microsoft.

Onde sentimos falta dos "mutexes robustos posix"? É parte do .NET Core PAL?

A qual sistema de CI você está se referindo? Por que ele está vinculado ao esforço de porta do .NET Core?

Onde sentimos falta dos "mutexes robustos posix"?

No kernel do NetBSD (e libc / libpthread), isso faz parte do CoreCLR. FreeBSD o desenvolveu nos últimos dois anos. Ele pode estar disponível na versão estável mais recente .. mas é necessário verificar.

Quero adicionar este recurso antes de reiniciar a portabilidade do .NET. (Também foi detectada uma pequena API ausente para roteamento de rede ... mas vou pular agora).

É parte do .NET Core PAL?

Não me lembro agora, sem verificar o código - é a API usada para implementar do .NET denominados mutexes robustos (ou talvez semapthores).

A qual sistema de CI você está se referindo?

NetBSD.

Por que ele está vinculado ao esforço de porta do .NET Core?

Era um recurso opcional da última vez que olhei. Decidi obter paridade de recursos nas interfaces do kernel e utilitários (como LLDB). Apenas o meu estilo de trabalho, conseguir um bloco funcional para depois construir uma casa. Em algum momento, precisaremos dele de qualquer maneira, então por que não desenvolvê-lo de uma vez. Obrigado pela compreensão :)

Talvez você possa apenas marcar o grupo freebsd-dotnet no GH? Ele é um membro lá (ou você pode pesquisar o nome da conta). Seu e-mail é [email protected]

[EDIT] Excluir e-mails e respostas anteriores de @karelz

@RussellHaley sinta-se à vontade para marcar o grupo maior se achar apropriado. Não consegui encontrar a conta GH de Mathieu por seu nome nem por e-mail, foi o que quis dizer acima (BTW: enviei um ping diretamente para ele por e-mail).

Vou dar uma olhada em como marcar o grupo.

Aqui está o relato de Mathieu. Talvez uma configuração de privacidade?

https://github.com/mprevot

Saúde,

Russ

Na segunda-feira, 18 de setembro de 2017 às 13:01, Karel Zikmund [email protected]
escreveu:

@RussellHaley https://github.com/russellhaley sinta-se à vontade para marcar o
grupo maior se você achar que é apropriado. Não consegui encontrar o GH de Mathieu
conta via seu nome nem e-mail, foi o que eu quis dizer acima.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/corefx/issues/1626#issuecomment-330338996 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ACENF_N6mtOo3fptvku-LUMioNpZG7coks5sjswWgaJpZM4EPG-N
.

Não consigo ver nenhum lugar aqui mencionado, mas qual versão mais baixa do FreeBSD estamos almejando aqui (suponho que pelo menos 10 e mais tarde, mas talvez 9 também)?
(Também estou um pouco confuso sobre qual discussão deve acontecer na lista de discussão mono @freebsd , e o que aqui?)

Bem, se o Fedora for alguma indicação, a MS oferecerá suporte apenas às versões atualmente suportadas, ou seja, 10.3 (10.4 em breve) e 11.1.

@radovanovic FreeBSD 9 não é mais suportado, 10 será EoL em abril de 2018, 11 em 2021. De minha experiência, não deve haver nenhum problema com compilar em 11 vs 10 (e até 9 se você quiser). O FreeBSD é desenvolvido tendo em mente a compatibilidade com versões anteriores.

@radovanovic Eu também estou um pouco confuso sobre qual discussão deveria acontecer na lista de discussão mono @ freebsd , e o que aqui?

Eu esperava as discussões técnicas, coordenação de trabalho e status aqui, pois este é um público mais amplo do que a lista de discussão mono @ freebsd . OTOH, não queremos zilhões de discussões aleatórias sobre uma questão, então podemos levar algumas discussões de design específicas para questões separadas desta se elas crescerem acima de um número razoável de respostas.

Finalmente consegui executar testes corefx no FreeBSD 11.0 (sem testes outerloop)
Total aprovado: 144208
Falha total: 2622
Total pulado de 207

Vou atualizar https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD com instruções. Vou registrar questões específicas e marcá-las com os-freebsd e pronto para uso.
A batalha em grande escala pode começar. Precisa-se de voluntários.

E sim, pulei a etapa dois proposta. Voltarei a ele também.

Com algumas alterações de trabalho em andamento, as estatísticas atuais se parecem com:
Total aprovado: 238892
Falha total: 58
Total pulado 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 aberto para rastrear suporte de copos quebrados.

Ótimo progresso! Adicionar o NetBSD quando houver suporte para o FreeBSD na árvore deve ser simples.

@wfurt, por favor, compartilhe o endereço de e-mail, vou deixar cair algumas linhas.

O suporte inicial foi mesclado ao branch master. A compilação deve funcionar conforme descrito na página WIKI.
Estou progredindo lentamente no dotnet / corefx # 24386, mas isso não deve impedir a maioria dos usuários.

Já podemos inicializar o .NET no FreeBSD?

Eu não tentei por um tempo @krytarowski Houve um empurrão para atualizar o ferramental para a versão 2.0 e eu estava esperando que esse esforço se estabilizasse. Vou tentar novamente e postarei atualizações.

Oi, estou atolado com os testes gerenciados clr não funcionando. https://pastebin.com/B5KhtKX5

Qualquer entrada seria ótima, pois isso tem sido um problema há algum tempo. Recentemente, também encontrei uma falha de compilação na construção corefx no Windows (mestre, revisão Git 749194e). https://pastebin.com/JXUySLTY

Presumo que seja um problema intermitente, mas me atrasou esta noite.

Se você observar o erro:

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

E a linha de código ofensiva :

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

Minha intuição seria de que $maxProcesses não está definido, levando a uma expressão booleana incompleta:

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

Isso deve ser bastante testável. E se for esse o caso, você apenas tem que voltar atrás para tentar descobrir como você acabou assim.

Obrigado pela ajuda! @josteink :) Você está correto. O patch está aqui: https://pastebin.com/d5y9k1tw

Isso permite que os testes sejam executados, mas desisti em cerca de 1000 erros, todos da mesma natureza:

FALHOU - JIT / Methodical / casts / iface / _il_dbgiface2 / _il_dbgiface2.sh
COMEÇAR A EXECUÇÃO
/usr/home/russellh/Git/coreclr/bin/tests/Windows_NT.x64.Debug/Tests/coreoverlay/corerun _il_dbgiface2.exe
coreclr_initialize falhou - status: 0x80004005
Esperado: 100
Real: 255
EXECUÇÃO FINAL - FALHOU

Ok, de acordo com as excelentes informações de @janvorli , eu estava executando parte da minha compilação na versão e parte da minha compilação na depuração. Um erro embaraçoso de copiar / colar. Estou reconstruindo agora.

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

O patch está aqui: https://pastebin.com/d5y9k1tw

Se você tiver um patch que corrige uma compilação quebrada, recomendo enviá-lo como um pull-request para que seja corrigido para todos :)

Obrigado, eu vou. Ainda estou trabalhando para que os testes sejam executados e não tinha certeza do que estava causando o erro subsequente na noite passada.

Suponho que o suporte do Freebsd 11 "pkg install" para o netcore 2.1 (uma vez lançado) não acontecerá, certo?

TLDR; Muito trabalho foi feito, mas é preciso haver alguém para levá-lo para casa. Escrever o Makefile do port é a parte fácil.

@wfurt conseguiu que o CLR e o FX fossem construídos usando Linux, mas não foi testado em grande parte. Consegui fazer com que as partes 'nativas' fossem compiladas no FreeBSD, mas perdi tempo para que as partes gerenciadas fossem compiladas no Windows (para o FreeBSD). A coisa toda era uma bagunça de transferência de arquivos entre sistemas operacionais.

Separadamente na [email protected] lista de discussão, @dragonsa importou uma versão binária do Dot Net Núcleo 1 e todo o toolschain (msbuild, NuGet etc) a partir Mintos usando emulação Linux. Consegui usar seus patches e executar algumas das ferramentas, mas nunca consegui construir nada. Não tenho certeza se esses patches já foram confirmados; Eu estava revisando-os e mudei de emprego. Não tenho nenhum DotNet em minha função atual e estou trabalhando em outras coisas agora.

O que significa tudo isso? Se alguém pode verificar os patches do @dragonsa , ele pode empurrá-los para a árvore de ports, então é tecnicamente possível construir o Core 2 no FreeBSD nativamente. Como você pode ver, porém, há muitas pequenas partes que precisam ser reunidas e organizadas. Deixei cair a bola nisso, então alguém precisa pegá-la. Sugiro saltar sobre o [email protected] lista de discussão. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html

@russellhadley Obrigado pela

Oi,

Discutindo isso com um desenvolvedor .NET aqui, estou disposto a ajudar no desenvolvimento de um port / pacote do FreeBSD.

Divulgação completa: não sou um desenvolvedor .NET, mas estou disposto a trabalhar com quem quer que seja para colocar isso na árvore.

~ cy

@cschuber , tenho estado muito ocupado para ficar de olho no status atual das coisas, mas como alguém que enviou muitos patches do FreeBSD e conseguiu fazer o Hello World rodar há cerca de 3 anos, seria incrível se pudéssemos finalmente ver essa coisa sendo aterrada corretamente. Você tem meu total apoio :)

@cschuber , os problemas ativos atualmente são https://github.com/dotnet/coreclr/issues/18067. Principalmente esses quatro recursos são deixados https://github.com/dotnet/corefx/issues?q=is : open + label: os-freebsd + label : up-for-grabs + is: issue, entre o qual o observador do sistema de arquivos parece estar o mais complicado / trabalhoso https://github.com/dotnet/corefx/issues/2046.

Obrigado pela oferta @cschuber. Estamos quase no ponto em que isso pode ser possível.
Temos trabalhado recentemente com @mateusrodrigues para fazer o .net funcionar no FreeBSD e ele está tentando fazer o PowerShell funcionar. A lista @ kasper3 enviada https://github.com/dotnet/coreclr/issues/18481. Seria ótimo se qualquer pessoa da comunidade pudesse explorá-los. Não fiz testes recentemente, mas temo que o número de falhas tenha aumentado.
Devemos abrir a questão para cada novo grupo com falha.

Eu também começo a consertar o código-fonte, mas ainda há alguns desafios pela frente.
O compilador c # é escrito em c #. A compilação .net atual usa a versão anterior do .net para produzir assemblies gerenciados. Também depende de pacotes do Nuget.
No momento, temos bootstrap cli bom o suficiente para que possamos construir coreclr, corefx e alguns outros repositórios no FreeBSD. Eu não atualizei as instruções de construção ainda para refletir as alterações 2.1 e a construção do código-fonte.

1 Apenas uma nota para dizer que estou feliz que ainda tenha algum ímpeto. É difícil seguir com tantas partes móveis, mas parece que as pessoas estão fazendo progresso. Criei https://github.com/dotnet/coreclr/issues/6115 há um tempo, mas o projeto em que estava trabalhando foi suspenso. Eu realmente espero que seja tão fácil quanto pkg install dotnet && dotnet build um dia (sem compatibilidade com o Linux).

Também estou ansioso por isso

Temos compilações diárias em andamento agora. Pode-se obter runtime ou sdk aqui: https://dotnetcli.blob.core.windows.net/dotnet/Runtime/master/dotnet-runtime-latest-freebsd-x64.tar.gz e
https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-freebsd-x64.tar.gz

Também é possível fazer cross-target, por exemplo, em Linux ou Windows, pode-se fazer dotnet publish -r freebsd-x64 e isso criaria um aplicativo FreeBSD independente.

Ainda está incompleto e sem suporte, mas deve tornar mais fácil para qualquer pessoa contribuir.
Seria ótimo se as pessoas pudessem tentar, relatar problemas.
Além disso, este seria um bom momento para o empurrão final para fechar a lacuna de recursos e corrigir bugs.

cc: @mateusrodrigues

Bom trabalho, @wfurt e @bartonjs.

Quando propus meus primeiros commits do FreeBSD, cerca de 2-3 anos atrás, eu realmente não acreditava que chegaríamos aqui, mas certamente queria tentar.

Este é definitivamente um grande marco e, com sorte, tornará mais fácil para os novos contribuidores ajudarem a finalizar a conversão.

Muito obrigado a todos que nos ajudaram a chegar até aqui 👍

Ótimo progresso! Eu ainda estou lutando com o conjunto de ferramentas (a maioria dos projetos LLVM além de LLDB e LLD estão concluídos) e virtualização assistida por hardware para NetBSD (Linux / BSD agora começa a inicializar até uma exceção fatal VTx, sistemas operacionais mais simples como FreeDOS já funcionam) .. então vou retomar minha portabilidade do NetBSD, espero que mais cedo ou mais tarde. Melhor suporte ao FreeBSD ajudará com um currículo mais fácil.

Incrível :)

Nós celebramos a embriaguez por que o bombardeio ensil ??

@krytarowski Você pode desenvolver de que maneiras o 'suporte ao FreeBSD' pode ser melhor?

Seria ótimo se algum guru do FreeBSD pudesse dar uma olhada em https://github.com/dotnet/coreclr/issues/22124 Eu esperaria que binários compilados para 11 rodassem em 12, mas não parece ser o caso; (
É fácil de reproduzir com um aplicativo simples e a versão 12.0 parece quebrar algo de que o dotnet depende.

Olá, não sou um guru, mas encontramos uma regressão de threading em 12-RELEASE na porta Lua53.
Veja aqui o bug original: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235158
e aqui para o bug do sistema básico que foi identificado: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235211 (observe que o bug do sistema básico identifica o código que pode ser usado para reproduzir o problema para comparação).

A correção para Lua é vincular-se a -pthread, embora haja um requisito ZERO de Lua para -pthread.

obrigado @RussellHaley. Parece uma pista promissora.

Que bom que pude ajudar. Adoraria jogar junto, mas mal tenho as poucas horas necessárias para manter o porto da Lua. Continue com o ótimo trabalho!

Como aquele que consertou a implementação de threading do FreeBSD no coreclr , acho que os pthreads são usados ​​de forma bastante consistente, porque foi isso que eu tive que corrigir para fazer a compilação funcionar.

Dito isso, pode haver buts e peças subjacentes que eu nunca tive que tocar e que usam fios "regulares" ...

Talvez alguém que saiba mais sobre a implementação geral possa intervir? @janvorli ?

Isso corrige o problema para mim:

[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

Não fiz nenhum teste extenso, mas pelo menos posso executar dotnet novamente.

Ok, posso ver que o executável dotnet não está vinculado a pthreads para outros sistemas além do Linux.
https://github.com/dotnet/core-setup/blob/2ef0b64810530961f492c33d37fc7509128e0a9b/src/corehost/cli/exe.cmake#L59 -L61

Isso significa que a resposta para consertar isso é tão simples quanto parece? Ou seja, tão simples quanto isso? https://github.com/josteink/core-setup/commit/25657ba2e181cce401acd7f4bf9d27a08a668470

Se sim, terei todo o gosto em torná-lo um PR.

Acho que sim. Estava esperando a confirmação de @joperator .
Não tenho certeza se precisamos de "dl" também, mas isso pode ser resolvido quando você enviar PR @josteink

Direito. Foi mal. Então, mais parecido com isso: https://github.com/josteink/core-setup/commit/a08f38e25a98c25f59c8ed8c8567a0cb08b1c1c6

Eu criei um PR para isso. Avise-me se precisar de alguma emenda: https://github.com/dotnet/core-setup/pull/5072

Direito. Foi mal. Então, mais assim: josteink / core-setup @ a08f38e

Eu criei um PR para isso. Avise-me se precisar de alguma emenda: dotnet / core-setup # 5072

Apenas para sua informação, parece que já está corrigido no sistema básico: https://reviews.freebsd.org/D18988

Parece que o problema principal no dotnet / coreclr # 22124 foi corrigido em @wfurt.
Eu só tenho um problema ao tentar publicar um aplicativo independente no FreeBSD 12.0.

Os pacotes NuGet oficiais do freebsd-x64 foram removidos desde o .NET Core 3.0 preview 2 e não pudemos publicar aplicativos para o FreeBSD desde então. Existem planos para reativá-los no 3.0?

Infelizmente, tivemos que tirar a prioridade do FreeBSD (devido a vários motivos e dificuldades no suporte de ponta a ponta do Azure) e isso não será prioridade no .NET Core 3.0.
Adoraríamos mantê-lo semi-funcional no estado em que se encontra agora, mas não temos muito tempo para investir agora :(.

@karelz Obrigado pela sua resposta e compreendo o trabalho priorizado do .NET Core 3.0. Vou me concentrar em trazer meus aplicativos com emulação FreeBSD Linux então. :)

@ hjc4869 Ou você pode tentar mono. IIRC, ele suportará .NET Standard 3.0

Estou planejando tentar novamente , mas como

@newsash Mono é uma opção aceitável para mim. No entanto, achei difícil construir meu projeto com os destinos mono adicionados aos arquivos csproj existentes do .NET Core.

Em uma máquina Linux, tentei adicionar net472 a TargetFrameworks e definir a variável FrameworkPathOverride, mas não funcionou bem. Se eu consumir uma API implementada tanto em mono quanto em .NET Core, mas não em .NET Framework, ela falhará ao construir com mono. Além disso, embora mono suporte .NET Standard 2.1, ainda não consegui adicionar referência a dlls .NET Standard 2.1 em um csproj net472.

Devo adicionar um csproj separado e usar mono msbuild em vez de usar ferramentas dotnet, ou você tem alguma sugestão sobre o problema?

Apenas uma observação rápida.

Com o mono prestes a ser engolido pelo .NET 5, conforme o anúncio recente [1], fornecer suporte decente para o FreeBSD tornou-se urgente.

Mono provou ter um suporte multiplataforma realmente bom e pode ser construído sem problemas a partir de portas do FreeBSD. Muitas lojas executam suas cargas .net no FreeBSD, uma vez que este sistema operacional tem muitos recursos exclusivos. Até agora, o mono tem preenchido a lacuna, mas com o .NET 5 parece provável que em um futuro próximo, o mono será mesclado com o NET 5 e a comunidade do FreeBSD será totalmente desligada do ecossistema .NET.

Dotnet deve ter suporte ao FreeBSD maduro bem antes que isso aconteça.

Eu acho que a Microsoft deveria oficialmente dar suporte ao FreeBSD neste ponto e garantir que todas as ferramentas dotnet sejam compiladas nesta plataforma.

@jasonpugsley reuniu as instruções https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD e @joperator está tentando fazer o código-fonte funcionar https: // github. com / dotnet / source-build / issues / 1139

Temos cerca de 30 últimos testes com falha 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á olhando System.Diagnostics.Tests.ProcessTests, portanto, a falha nos testes de bloqueio parece ser a maior lacuna restante. Seria ótimo se alguém pudesse dar uma olhada no dotnet / corefx # 30899.

Gostaria de saber se há alguma atualização sobre isso ou se foi abandonado?

@elfalem , atualmente a perna de CI do FreeBSD (que compila do Ubuntu) está rodando em PRs dotnet / runtime. Ele usa uma imagem docker de https://github.com/dotnet/dotnet-buildtools-prereqs-docker/ , que tem todos os pré-requisitos instalados. Podemos usar o mesmo contêiner do docker para publicar o pacote de tempo de execução (basicamente um tar.gz), localmente ou em uma máquina remota. por exemplo, podemos configurar uma ação GitHub em um de nosso fork branch, algo como: https://github.com/am11/runtime/blob/feature/freebsd/ci/.github/workflows/main.yml , que carrega artefatos para lançamentos do GitHub no tag push https://github.com/am11/runtime/releases/tag/6.0.0-dev.freebsd.1. O arquivo dotnet-runtime-6.0.0-dev-freebsd-x64.tar.gz neste caso tem bits suficientes para apenas executar um aplicativo dotnet publicado (de um sistema Linux / mac diferente, que tem dotnet SDK). Eu testei criando uma nova VM 12.2 (vagrant), extraí e copiei um aplicativo publicado do mac para a VM, funcionou:

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

Acho que @Thefrank estava pensando em criar um pacote de Ports FreeBSD adequado em algum momento.

Gostaria de saber se há alguma atualização sobre isso ou se foi abandonado?

você pode querer dar uma olhada em https://github.com/dotnet/source-build/issues/1139
Não tentei recentemente enquanto espero pelo dotNET5 final, mas, há alguns meses, o tempo de execução do FreeBSD só poderia ser construído como uma compilação cruzada no Linux. ASPNet e SDK também exigiam compilação cruzada do Linux, mas apenas construídas se as estrelas estivessem alinhadas (atualizações de arcade ou algum outro bot automatizado não quebrou a dependência)

edit: and @ am11 postou uma redação melhor enquanto eu
edit2: esqueci a pontuação e parece que o final foi lançado 2 dias atrás. acho que devo começar a trabalhar nisso ou algo assim

Além de tudo isso, criei o projeto FreeBSD em https://github.com/dotnet/runtimelab/ e estou progredindo lentamente na construção e publicação de pacotes. O objetivo é construir e publicar o suficiente para que o aplicativo rode no FreeBSD e tenha sementes para a construção do código-fonte.

Pensei em escrever uma atualização rápida. Finalmente alinhei todos os planetas para construir o RTM 5.0.0 no FreeBSD. Eu não tinha acompanhado desde o Preview3 e demorou um pouco (e _muitas_ tentativas de compilação) para encontrar a combinação certa de compilações compatíveis para obter um 5.0 bem-sucedido.
Consegui construir o PowerShell 7.1.0 com surpreendentemente poucos hacks, ele funciona embora não o tenha testado completamente, mas parece um bom teste do SDK.
Acabei de criar o AspNetCore, mas ainda não o testei.

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

O único problema em fazer este trabalho manualmente (ou seja, fora do sistema de CI) é o problema causado por alterações interrompidas que exigem que um determinado build esteja disponível para o próximo build a ser usado. Isso não acontece com frequência, mas requer muita tentativa e erro para encontrar o commit correto. Ter a compilação cruzada do Linux no sistema de CI deve corrigir isso, mas ainda não olhei para isso. Ainda assim, é bom saber que posso construir um SDK completo e então usar esse SDK para construir outra coisa.

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

Isso é um bom progresso, @jasonpugsley. Estou tentando encontrar uma resposta melhor para a construção, mas não consegui dedicar nenhum tempo decente nos últimos meses; (
O PowerShell incomodou você por causa do terminfo ou você copiou a definição do terminal de outro lugar?

Peguei a definição do terminal do meu Mac de onde fui ssh'd.

@jasonpugsley, você está muito à minha frente. core e sdk construídos a partir do linux cross freebsd. funcionar bem a partir do teste limitado ive feito. nem runtime nem sdk crossbuilts são capazes de construir no freebsd (linux e freebsd estão usando llvm9 e clang9).
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0
Vou mexer um pouco mais se tiver mais tempo neste fim de semana e também ver se pelo menos consigo obter aspnetcore integrado no Linux para freebsd

@Thefrank , você quer dizer:

$ 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á falhando ou os binários em artifacts/packages/Release/Shipping/dotnet-runtime-5.0.0-dev-freebsd-x64.tar.gz falharam ao executar?
Se você está tentando compilar o SDK 5x no Ubuntu 18 ou 20, pode aplicar este patch https://github.com/dotnet/sdk/commit/80e42f16422352f725d78be72071781d8365a238 (está no branch master).

Eu realmente preciso parar de fazer postagens quando estou meio dormindo.
A construção do tempo de execução e do SDK é concluída no Linux.
Esses binários são executados em freebsd (dotnet --info, novo console e execução)
Esses binários são incapazes de criar um runtime ou sdk a partir da fonte no freebsd

Ah ok. Eu não tentei dogfodding os binários do stage0 para reconstruir o tempo de execução no FreeBSD como HostOS.

ld: erro: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim. exportações: 1 : diretiva desconhecida: V1.0

Pode valer a pena relatar esse problema separadamente. Provavelmente, existem várias maneiras de consertá-lo, mas esse patch faz alguma diferença:

--- 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 patch faz alguma diferença

Eu esperaria que o FreeBSD seguisse o Linux no que diz respeito aos scripts de versão de símbolo, não o Darwin. IMO, é mais provável que o problema seja que haja algo específico do GNU-awk em generateversionscript.awk

patch mudou o erro:
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: _CreateProcessForLaunch
se o problema da versão do awk:

awk --version
awk version 20121220 (FreeBSD)

Se for fácil de experimentar, você pode tentar instalar o pacote gawk e alterar a invocação nos arquivos CMake para gawk?

reverteu o patch. pacote gawk instalado.
preguiçoso demais para descobrir como o script build.sh passa argumentos cmake, já que não faz sentido imediatamente, então eu apenas vinculei gawk-> awk.
mesmo erro original
ld: error: /root/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/src/dlls/dbgshim/dbgshim.exports:1: unknown directive: V1.0

edição tardia: parece que os binários no Linux não foram compilados corretamente:

# ./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 RID: osx-x64 pode estar causando alguns problemas

principalmente o RID: osx-x64 pode estar causando alguns problemas

Esse RID é exibido pelo SDK após algumas resoluções de plataformas compatíveis e não compatíveis. Basicamente, não tem efeito na execução do aplicativo. O RID real detectado pelo tempo de execução está correto, caso contrário, os aplicativos (como dotnet(1) ) não serão executados corretamente.
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 na minha caixa.

# 45663 aberto para rastrear o problema de ld. Eu também consegui reproduzir.

@Thefrank em relação ao erro ld, tente isto:

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)

Isso ativará a cláusula else em eng/native/functions.cmake aqui:

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 bem honesto, não sou nenhum especialista em linker, então, enquanto isso funciona, não olhei mais a fundo para ver o que era realmente necessário / canônico para o clang no FreeBSD.

Ahh, o problema do agente do usuário do vinculador ocorre novamente. A string de versão do LLD inclui (compatible with GNU linkers) em uma tentativa de seguir o caminho GNU ld dos testes de configuração, mas claramente não é inteligente o suficiente para este caso :)

A correspondência no LLD parece boa aqui, mesmo se a bandeira LD_GNU agora estiver com um nome incorreto.

Sim, precisa de mais trabalho. O nome da bandeira agora é confuso. Por favor, não tente fazer commit no estado em que se encontra.

De: Ed Maste [email protected]
Enviado: segunda-feira, 7 de dezembro de 2020 10:26:48
Para: dotnet / runtime [email protected]
Cc: Jason Pugsley [email protected] ; Mencione mençã[email protected]
Assunto: Re: [dotnet / runtime] Suporte para FreeBSD (# 14537)

Ahh, o problema do agente do usuário do vinculador ocorre novamente. A string de versão do LLD inclui (compatível com linkers GNU) em uma tentativa de seguir o caminho GNU ld dos testes de configuração, mas claramente não é inteligente o suficiente para este caso :)

A correspondência no LLD parece boa aqui, mesmo se o sinalizador LD_GNU agora estiver com um nome incorreto.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/dotnet/runtime/issues/14537#issuecomment-739583816 ou cancele a inscrição https://github.com/notifications/unsubscribe-auth/AECFDEXKTDFRAX4ZEE6VXZTSTQHLRANCNFSM4TS3XPA .

Optei por usar https://github.com/dotnet/runtime/pull/45664
Clr acumula até o subconjunto Clr.Tools e falha com

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

subconjunto "mono" e subconjunto "libs" completo sem erros

@Thefrank É a segunda parte deste diff que você precisa para corrigir esse 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>

Pode ser melhor adicionado à linha LINUX como um OR na condição.

@jasonpugsley isso fez o truque!
/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):
Eu sabia que esqueci de fazer algo há alguns dias! Isso deve ser interessante

editar: sem crossgen (também conhecido como apenas segunda metade)

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

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

Time Elapsed 00:12:05.56

editar a última edição deste post, eu juro:
Eu sei que os testes podem demorar um pouco e diz teste de longa duração, mas isso está ficando fora de controle para um teste
System.Net.HttpListener.Tests: [Long Running Test] 'System.Net.Tests.HttpListenerResponseTests.AddLongHeader_DoesNotThrow', Elapsed: 00:36:20

matou o teste depois de esperar 2hr outros testes ainda tiveram falhas

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