Runtime: Habilitando Linux ARM32 para .NET Core

CC @schelap ramarag @janvorli

Como mencionei na discussão em dotnet/core-setup#724, acredito que devemos ser consistentes na maneira como fazemos cross build em nossos repositórios. Isso significa usar rootfs e fazer a compilação cruzada usando clang e não GCC. Da mesma forma que fazemos no CoreCLR e CoreFX.
Espero que possamos reutilizar a lógica do build.sh no CoreCLR aqui.

@hqueue @hseok-oh O Ubuntu 14.04 é um alvo pretendido para o Arm32?

@ gkhanna79 O padrão do AFAIK é o ubuntu.14.04-arm para coreclr ARM e o ARM padrão rootfs é confiável, que é o ubuntu 14.04.

@hqueue @gkhanna79 RaspberryPI2 usou o Ubuntu 14.04. (mas não é mais mantido)
https://wiki.ubuntu.com/ARM/RaspberryPi

@hseok-oh Se o Ubuntu 14.04 não for mantido e suportado, existe um motivo específico para suportá-lo no Linux Arm32? Caso contrário, ele simplificará um monte de coisas (por exemplo, libcoreclrtraceptprovider.so compila bem para 16.04, mas precisa de trabalho adicional para 14.04).

O que você acha?

O padrão do AFAIK é o ubuntu.14.04-arm para coreclr ARM e o ARM padrão rootfs é confiável, que é o ubuntu 14.04

Não sei quem escolheu esses padrões ou por quê. Poderia ser porque o Tizen OS é baseado no Ubuntu 14.04? construímos libcoreclrtraceptprovider.so para Tizen?

@kouvel Este é o principal problema da lista de trabalho do Linux Arm32.

CC @schelap

O padrão do AFAIK é o ubuntu.14.04-arm para coreclr ARM e o ARM padrão rootfs é confiável, que é o ubuntu 14.04

Não sei quem escolheu esses padrões ou por quê. Poderia ser porque o Tizen OS é baseado no Ubuntu 14.04? construímos libcoreclrtraceptprovider.so para Tizen?

@gkhanna79
Eu não acho que esteja relacionado ao Tizen OS.
A explicação mais possível será que o Ubuntu 14.04 é selecionado por causa de dispositivos (por exemplo, ARM Emulator, Raspberry pi 2 e etc.) que foram usados ​​para ativar o CoreCLR ARM.
Por favor, confira https://github.com/dotnet/coreclr/issues/3805 para o emulador ARM que é usado no estágio inicial do CoreCLR ARM32.

Obrigado pela explicação @hqueue. Por enquanto, podemos continuar a construir para 14.04 e 16.04 e ver até onde precisaremos da implementação do 14.04.

Com relação ao emulador, notei que no repositório CoreCLR, inicializamos o emulador e configuramos o rootfs dentro dele e depois executamos o build. Isso é diferente das instruções de compilação que temos em https://github.com/dotnet/coreclr/blob/master/Documentation/building/cross-building.md , onde consiste em duas etapas:

1. Construir rootfs para uma arquitetura
2. Execute uma compilação cruzada do repositório

Nós nos esforçamos muito para garantir que a CI seja construída da mesma maneira que qualquer desenvolvedor faria. Como as etapas acima são como se espera que qualquer desenvolvedor na comunidade crie para o Arm32, o que você acha de atualizar o script CI para fazer exatamente isso e não depender do emulador para executar a compilação?

Em segundo lugar, o emulador só deve ser obrigado a implantar binários e executar testes. Percebo que executamos apenas 22 testes dentro do emulador, mesmo que o repositório tenha mais de 11 mil testes. Esses 22 testes adicionam algum valor da perspectiva do CI (por exemplo, aqui está um log de um PR recente que mostra os 22 testes executados - https://ci.dot.net/job/dotnet_coreclr/job/master/job/arm_emulator_cross_debug_ubuntu_prtest /1080/consoleFull) uma vez que eles não parecem cobrir os principais cenários em que as pausas podem ser introduzidas?

@gkhanna79 Para a primeira pergunta, chamarei @sjsinju @wateret , já que não estou ciente das últimas novidades do ARM CI.

@sjsinju @wateret Você pode responder a primeira pergunta acima sobre CI e emulador ARM?

Para o segundo, também acho que os testes não são suficientes para cobrir os principais cenários. Nós vamos olhar para eles.

@gkhanna79
CI cross-builds da mesma forma que qualquer desenvolvedor faria. Você pode conferir arm32_ci_script.sh#L227 . O emulador é apenas para execução de testes. Claro, ainda precisamos de rootfs pré-construídos para compilação cruzada.

Mais uma coisa que pode ser confusa é que o CI possui apenas rootfs arm-softfp que não podem ser criados por 'nenhum desenvolvedor'. Existe meu trabalho no CoreFX para habilitar o arm-hardfp (ubuntu 14.04). Depois de feito, vou aplicá-lo ao CoreCLR também.

@gkhanna79 Não consegui encontrar onde o libuv.so foi construído. Você poderia me dar um conselho?

@jyoungyun não tenho certeza se é a maneira como o libuv é construído para .NET, mas para raspberry pi as instruções até agora foram baixá-lo do projeto libuv e compilá-lo:

Veja esses comentários de @leemgs relacionados a dotnet/coreclr#6321

rpi2@arm# sudo apt-get install gyp
rpi2@arm# wget http://dist.libuv.org/dist/v1.0.0-rc1/libuv-v1.0.0-rc1.tar.gz 
(The latest version is v1.9.1: http://dist.libuv.org/dist/v1.9.1/libuv-v1.9.1.tar.gz)
rpi2@arm# tar -xvf libuv-v1.0.0-rc1.tar.gz
rpi2@arm# cd libuv-v1.0.0-rc1/
rpi2@arm# ./gyp_uv.py -f make -Duv_library=shared_library
rpi2@arm# make -C out
rpi2@arm# sudo cp out/Debug/lib.target/libuv.so /usr/lib/libuv.so.1.0.0-rc1
rpi2@arm# sudo ln -s libuv.so.1.0.0-rc1 /usr/lib/libuv.so.1

Isso funcionou para eu colocar o Kestrel em funcionamento no Raspberry Pi; mas observe que as versões mais recentes do libuv agora estão disponíveis em http://dist.libuv.org/dist/

CI cross-builds da mesma forma que qualquer desenvolvedor faria.

@wateret Meu ponto é que devemos desacoplar a construção cruzada no CI do emulador. A nuance é que, no CI, configuramos rootfs a partir do emulador e, em seguida, executamos a compilação cruzada, enquanto um desenvolvedor comum não. Minha sugestão é corrigir o script para fazer o seguinte:

1) Sem o emulador, execute o cross build (por exemplo, cross/build-rootfs.sh arm)
2) Carregue o emulador apenas para testes em execução. Assim, se decidirmos que o emulador pode não ser mais necessário para testes por algum motivo, a compilação cruzada continuará a funcionar como esperado.

@hqueue você achou algo interessante sobre a execução dos 22 testes no CI?

@qmfrederik Obrigado pela sua resposta. O que você está falando é como baixar libuv.so diretamente. Mas eu quero saber onde o libuv .nupkg é gerado.

@gkhanna79

configuramos rootfs a partir do emulador e, em seguida, executamos a compilação cruzada, enquanto um desenvolvedor comum não.

Apenas deixe as coisas claras, a imagem do emulador nada mais é do que rootfs pré-construídos. Claro que o emulador também precisa dele para executar testes.

Para o primeiro que você sugeriu, basicamente eu concordo com você. No entanto, leva muito tempo para construir rootfs com build-rootfs.sh . Tanto quanto me lembro, demorou 1-2 horas na minha máquina linux. Não tenho certeza se é aceitável.
Para o segundo, o emulador já é carregado apenas para testes em execução. A compilação não é executada no emulador. Ele se constrói de forma cruzada.

você achou algo interessante sobre a execução dos 22 testes em CI?

@gkhanna79 Esses 22 testes são TCs em que observamos regressão com frequência ao criar o CoreCLR para Linux ARM32. Portanto, a cobertura de 22 testes não cobre o código que não é modificado com frequência. No entanto, não podemos executar todos os TCs (11K+) com emulador ARM porque demorou muito tempo e enfrentamos o tempo limite no ambiente de CI.

Também acho que precisamos de mais TCs para IC, mas não tenho certeza sobre como escolher os candidatos. Você pode sugerir alguma opção?

cc: @jyoungyun

@jyoungyun Acho que o pacote libuv NuGet está localizado aqui: https://github.com/aspnet/libuv-package?files=1

@qmfrederik Obrigado! Vou verificar esse repositório.

Finalmente, consegui obter um arquivo dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz, que confirmou que funciona bem no Raspberry PI2. Eu construí o repositório core-setup usando a fonte nupkg local e estes são os resultados criados a partir do CoreCLR e CoreFX (incluindo https://github.com/dotnet/corefx/pull/14655 patch). Se os nupkgs CoreCLR e CoreFX forem carregados no NugetServer ou em qualquer lugar, podemos gerar o .NET Core Runtime para Ubuntu ARM. Eu testei apenas no Ubuntu 14.04 e testarei no 16.04 mais tarde.

jyoung@DXL-Workstation:~/git/dotnet/core-setup-jy/artifacts/ubuntu.14.04-arm/packages$ ls
total 33M
-rwxrw---- 1 jyoung jyoung  28K Dec 21 18:18 dotnet-deb-tool.1.0.1-t-beta-001206.nupkg
-rw-rw---- 1 jyoung jyoung 226K Dec 21 18:19 dotnet-hostfxr-ubuntu-arm.1.2.0-beta-001206-00.tar.gz
-rw-rw---- 1 jyoung jyoung  17M Dec 21 18:19 dotnet-sharedframework-ubuntu-arm.1.2.0-beta-001206-00.tar.gz
-rw-rw---- 1 jyoung jyoung  17M Dec 21 18:19 dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz
drwxrwx--- 2 jyoung jyoung 4.0K Dec 21 17:04 intermediate

pi<strong i="10">@raspberrypi</strong>:~/Downloads/24919/shared/Microsoft.NETCore.App/1.2.0-beta-001206-00 $ ./dotnet hello.exe 
Hello World

Impressionante! Se houver alguma maneira de você compartilhar os pacotes/tarballs NuGet, ficarei feliz em experimentá-los em um RPi 2 e 3 e ver até onde vou com nosso produto baseado em .NET Core :)

Consegui obter um arquivo dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz

Esta é uma excelente notícia @jyoungyun! Obrigado a todos por conduzirem isso :)

O pacote LibUV vem do repositório ASP.NET. @Eilon Você pode informar em qual repositório se inscrever para construir este pacote?

Se os nupkgs CoreCLR e CoreFX forem carregados no NugetServer ou em qualquer lugar

Este é o trabalho que estou acompanhando para ser feito como parte do suporte de compilação do pipeline E2E nos três repositórios .NET Core (CoreCLR, CoreFX, Core-Setup).

@wateret

Tanto quanto me lembro, demorou 1-2 horas na minha máquina linux

Isso é interessante. Para mim, criar um novo rootfs leva cerca de 7 minutos no meu SSD USB 3.0 para compilações Trusty e Xenial. Todo o resto é custo de uma construção cruzada regular a partir daí. Portanto, minha pergunta sobre por que precisamos pegar rootfs do emulador e não apenas buscá-lo sempre. Com base nisso, para habilitar a construção de CI para o braço do Ubuntu 16.04, você planeja adicionar outro emulador que conterá rootfs?

@hqueue

Você pode sugerir alguma opção?

Você tem alguma automação em torno de testes em HW real? Meu pensamento atual é avaliar isso em favor do emulador no futuro previsível.

Também posso confirmar que criar um novo rootfs leva alguns minutos na minha caixa Linux. Provavelmente está relacionado à velocidade da conexão com a internet, pois o processo busca todos os pacotes necessários.

O código-fonte do libuv é de terceiros e está aqui: https://github.com/libuv/libuv

O processo de compilação da equipe ASP.NET para compilar o libuv está em nosso próprio repositório aqui: https://github.com/aspnet/libuv-build/

E faz referência ao código-fonte libuv por meio de um submódulo Git: https://github.com/aspnet/libuv-build/tree/dev/submodules

E, finalmente, a equipe do ASP.NET tem um repositório para pegar os binários libuv e empacotá-los em um pacote NuGet: https://github.com/aspnet/libuv-package

cc @moozzyk que sabe mais sobre a compilação libuv.

O que @Eilon disse.
Pacotes para diferentes sistemas operacionais/arquiteturas (atualmente Windows Win32/x64/arm, Linux (64 bits), macOS) são construídos a partir deste repositório https://github.com/aspnet/libuv-build/ (que extrai o código libuv como um submódulo) e enviado para o feed myget como pacotes Microsoft.AspNetCore.Internal.libuv-* específicos do SO. O repositório libuv-package é responsável por puxar os pacotes de compilação e criar o pacote über libuv que contém bits para todas as arquiteturas suportadas.

@qmfrederik Anexei um tarball do .NET Core Runtime para o Ubuntu 14.04 ARM. Quando estiver pronto para o Ubuntu 16.04, compartilharei o arquivo aqui. (Atualizado em 26/12: Anexei um tarball .NET Core Runtime para Ubuntu 16.04 ARM.)
dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz (Ubuntu 14.04 ARM)
dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz (Ubuntu 16.04 ARM)

@gkhanna79

Este é o trabalho que estou acompanhando para ser feito como parte do suporte de compilação do pipeline E2E nos três repositórios .NET Core (CoreCLR, CoreFX, Core-Setup).

Obrigado pelo seu apoio!

@Eilon @moozzyk @qmfrederik Obrigado pelos comentários. Na verdade, não precisamos do libuv.so no momento. No entanto, parece que o libuv para o braço Linux é necessário para liberar o .NET Core Runtime para o Ubuntu ARM. Devo adicionar o pacote libuv para o braço Linux? O que você acha?

@jyoungyun - a única coisa que atualmente requer libuv é o Asp.NET Core Http Server - Kestrel . Se você não usa o Asp.NET Core, pode passar sem libuv.
Atualmente, usamos uma maneira caseira de construir o libuv para diferentes plataformas (uma das razões era que seus scripts não suportavam o Windows ARM), mas eventualmente seria bom apenas construir o libuv usando scripts de seu repositório, o que tornaria a habilitação de novas plataformas mais fácil.

PARA SUA INFORMAÇÃO. Eu corri acima do tarball dotnet no Raspberry Pi3, que é ubuntu.16.04-arm.
Pelo menos, funciona bem com HelloWorld.exe e outros aplicativos simples. :) Obrigado @jyoungyun !

Você tem alguma automação em torno de testes em HW real? Meu pensamento atual é avaliar isso em favor do emulador no futuro previsível.

@gkhanna79 Infelizmente, não temos testes automatizados CoreCLR/CoreFX em HW e também leva várias horas para realizar testes completos de unidade CoreCLR no dispositivo ARM, por exemplo, Rpi2 ou Rpi3.
Também estamos interessados ​​na infra de teste, mas temo que os testes completos do CoreCLR/CoreFX possam não ser viáveis ​​para o ARM HW devido ao tempo limite, por exemplo, os testes do CoreFX são executados por muito mais tempo do que o CoreCLR. Portanto, acho que podemos ter que escolher testes mesmo quando a infra está disponível.

Parece que dotnet/core-setup#712 foi mesclado, então podemos verificar isso!

Atualize o script de construção para habilitar a construção cruzada (PR será postado em breve.)

@jyoungyun Acredito que você tenha concluído isso para o Core-Setup, certo? Em caso afirmativo, você pode adicionar detalhes de PR acima e marcar isso :) ?

Atualize o script de compilação para habilitar o download e o empacotamento para Linux/ARM.

@hqueue Sobre o que é este item (está listado na seção Core-Setup)?

Devo adicionar o pacote libuv para o braço Linux? O que você acha?

@jyoungyun Acho que será uma boa ideia preparar as alterações para compilar lib-uv para arm32 (conforme rastreado por https://github.com/aspnet/libuv-build/issues/19).

@gkhanna79 @jyoungyun - o Linux/arm RID é suficiente? Que tal hard float vs. soft float? O RID linux-arm não transmite esta informação....

A convenção nos repositórios dotnet parece ser que arm = armhf e o softp deve
ser especificado explicitamente. Talvez um arm-softp livrado possa ser adicionado se
necessário

Em 27 de dezembro de 2016 19:01, "Pawel Kadluczka" [email protected] escreveu:

@gkhanna79 https://github.com/gkhanna79 @jyoungyun
https://github.com/jyoungyun - o Linux/arm RID é suficiente? Quão
sobre hard float vs soft float? O RID linux-arm não transmite isso
em formação....

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/core-setup/issues/725#issuecomment-269400424 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAL9OFobHMUWCNgwxEvC8nLJMdvM1PJtks5rMabfgaJpZM4LD3ey
.

Acredito que você tenha concluído isso para o Core-Setup, certo? Em caso afirmativo, você pode adicionar detalhes de PR acima e marcar isso :) ?
Sobre o que é este item (ele está listado na seção Core-Setup)?

@gkhanna79 No começo, pensamos que eram outras tarefas e eu estava planejando preparar PR separado para cada tarefa. Mas como você já notou, PR dotnet/core-setup#712 os habilitou completamente. Vou conferi-los. Obrigado por nos avisar :)

O Linux/arm RID é suficiente? Que tal hard float vs. soft float? O RID linux-arm não transmite esta informação....

@moozzyk @stevedesmond-ca @gkhanna79 @jyoungyun Eu também tenho a mesma pergunta desde quando essa tarefa foi iniciada e, por exemplo, não há distinção nos rids do Ubuntun entre diferentes ABIs flutuantes (por exemplo, hardfp, soft, softfp). Isso pode afetar todos os outros repositórios dotent, incluindo CoreCLR e CoreFX.

A convenção nos repositórios dotnet parece ser que arm = armhf e o softp deve
ser especificado explicitamente. Talvez um arm-softp livrado possa ser adicionado se
necessário

@stevedesmond-ca @moozzyk @gkhanna79 @hqueue Linux RID não contém as informações de float ABI, mas já usamos em combinação com RID e informações de float ABI como buildarch. Como @stevedesmond-ca mencionou acima, se necessário, podemos adicionar um arm-softfp rid como CoreCLR e CoreFX repos. Eu gostaria de manter a estrutura existente sobre as informações de RID e float ABI em core-setup e libuv-build. E vamos adicionar o arm-softfp à configuração do núcleo em breve para oferecer suporte ao Tizen OS. Tizen suporta apenas arm-softfp.

@gkhanna79 Todo o trabalho para construir a configuração do núcleo para o Ubuntu ARM já está mesclado via dotnet/core-setup#712. E postarei PR em breve para desativar o alvo GenerateDebs em relação ao dotnet/core-setup#849.

@gkhanna79 Também estou pensando em adicionar o Tizen ao Linux ARM32 e ele será iniciado de baixo para cima, ou seja, a partir do CoreCLR e CoreFX como fizemos para o Ubuntu 14.04 e 16.04. Acho que podemos seguir passos semelhantes. O que você acha disso? Eu posso construir CoreCLR para Tizen agora e posso adicionar rootfs para Tizen sempre que aprovado.

@hqueue @jyoungyun Devo admitir que não estou muito familiarizado com a diferença entre soft e hard fp. Você pode elaborá-los antes de seguirmos o caminho de determinar se eles exigem novos RIDs ou não?

adicionando o Tizen ao Linux ARM32 e ele será iniciado de baixo para cima

@hqueue Em geral, o conceito parece bom para mim. no entanto, antes de prosseguir com ele, gostaria de entender a diferença entre o Tizen (criado para Linux Arm32) e um Linux Arm32 .NET Core regular - você pode compartilhar mais detalhes sobre ele?

Você pode elaborá-los antes de seguirmos o caminho de determinar se eles exigem novos RIDs ou não?

@gkhanna79 GNU define três ABIs flutuantes para ARM, ou seja, soft , softfp e hard . (veja a parte -mfloat-abi=name em https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html) A principal diferença entre softfp e hard é a seguinte .

• GNU hard ABI: uso de instruções de ponto flutuante + uso de convenções de chamada específicas de FPU (ou seja, use registradores FP para parâmetros de ponto flutuante e valores de retorno)
• GNU softfp ABI: uso de instruções de ponto flutuante + uso de convenções de chamada soft-float (ou seja, usar registradores de pilha ou inteiros para parâmetros de ponto flutuante e valores de retorno)

Portanto, você não pode usar duas ABIs juntas, porque as convenções de chamada são diferentes.

Em dotnet , usamos hard e softfp para ARM. (sem soft ABI.)

• hard ABI: uma compilação padrão para ARM32, ou seja ./build.sh arm
• softfp ABI: podemos construir com ./build.sh arm-softfp

E todos os binários em arm rootfs têm hard ABI e os binários em arm-softfp rootfs têm softfp ABI.

Eu gostaria de entender a diferença entre o Tizen (criado para Linux Arm32) e um Linux Arm32 .NET Core regular - você pode compartilhar mais detalhes sobre ele?

@gkhanna79 Basicamente, você pode considerar o Tizen como outra distribuição de Linux/arm-softfp .
A principal diferença é a versão das bibliotecas/kernel e a composição dos pacotes em cada distribuição, por exemplo, a versão de libicu é diferente.
A diferença é semelhante à diferença entre ubuntu.14.04 e ubuntu.16.04 no Linux Arm32 .NET Core.

Resumidamente,

• Nós temos um rootfs ubuntu.14.04 para Linux/arm-softfp agora e podemos construir para ubuntu.14.04 usando ARM softfp ABI.
• Se adicionarmos rootfs do Tizen, teremos dois rootfs para Linux/arm-softfp , ou seja, ubuntu.14.04 e Tizen e poderemos construir para ubuntu.14.04 e Tizen usando ARM softfp ABI.

PARA SUA INFORMAÇÃO. No CoreCLR, temos um total de 5 rootfs para Linux/arm (hardfp), ou seja, jessie, vivid, trusty, sily e xenial.

Estou tentando explicar de forma resumida para evitar confusão. Se você tiver alguma dúvida, me avise :)

E todos os binários em arm rootfs têm hard ABI e binários em arm-softfp rootfs têm softfp ABI

Obrigado pela explicação @hqueue. Concordo que ativamos preguiçosamente o soft-fp se / assim que surgir a necessidade.

Obrigado pela breve explicação de Tizen @hqueue. Além das diferenças de versão de binários/kernel da plataforma, o Tizen está carregando o mesmo conjunto de binários que o .NET Core geralmente carrega? Ou seja, ao construir um aplicativo Tizen, você basicamente tem como alvo o .NET Core (e, portanto, tem um FX compartilhado baseado no Microsoft.NETCore.App) OU você tem (ou planeja ter) um mecanismo de direcionamento diferente (por exemplo, Samsung. Tizen) que poderia carregar um conjunto diferente de binários?

Além disso, como os aplicativos Tizen são ativados? Eles são ativados da mesma maneira que os aplicativos .NET Core (usando dotnet.exe) ou de alguma outra forma?

Basicamente, @hqueue , estou tentando entender se o Tizen é apenas mais uma distribuição equivalente para o .NET Core ou uma experiência de segmentação/AppModel completamente nova.

@gkhanna79 Acho que há várias perguntas aqui.

o Tizen está carregando o mesmo conjunto de binários que o .NET Core normalmente carrega?

Para CoreCLR e CoreFX, certo. Usaremos exatamente o mesmo conjunto de binários em Linux/arm-softfp, e AFAIK não há diferença entre Linux/ARM e Linux/arm-softfp até agora.

O próprio Tizen usa o sistema de empacotamento RPM para plataforma. CoreCLR e CoreFX para Tizen já estão sendo construídos com o sistema de compilação Tizen (https://build.tizen.org) na comunidade Tizen (https://www.tizen.org).
CoreCLR para Tizen: https://build.tizen.org/package/show?package=coreclr&project=Tizen%3AMobile
CoreFX para Tizen: https://build.tizen.org/package/show?package=corefx&project=Tizen%3AMobile

Ou seja, ao construir um aplicativo Tizen, você basicamente tem como alvo o .NET Core (e, portanto, tem um FX compartilhado baseado no Microsoft.NETCore.App) OU você tem (ou planeja ter) um mecanismo de direcionamento diferente (por exemplo, Samsung. Tizen) que poderia carregar um conjunto diferente de binários?
Além disso, como os aplicativos Tizen são ativados? Eles são ativados da mesma maneira que os aplicativos .NET Core (usando dotnet.exe) ou de alguma outra forma?

Existem vários modelos de aplicativos no Tizen e o .NET Core será um deles. Acho que isso pode ser explicado por @lemmaa e @idkiller.
@lemmaa @idkiller Por favor, analise essas perguntas.

Estou tentando entender se o Tizen é apenas outra distro equivalente para o .NET Core ou uma experiência de direcionamento/AppModel completamente nova.

@gkhanna79 Eu não acho que isso forneça uma experiência completamente nova. Como o Tizen atuará como outra distribuição do Linux, pelo menos acho que você pode considerá-lo como outra distribuição equivalente ao .NET Core.
@lemmaa @idkiller o que você acha disso?

Acho que podemos continuar a discussão no próximo ano para mais detalhes :)

@gkhanna79 @hqueue @hseok-oh O que você acha de nomear arm-softfp como armsf para nupkgs? Eu acho que não parece tão bonito ter um - entre o nome do buildarch. Por favor me dê uma boa ideia. :)

@jyoungyun Que tal usar armel para nosso softfp de braço? Parece que armel é usado para binários ARM softfp no Ubuntu e seria ótimo se pudéssemos seguir convenções na comunidade Linux.

Veja https://wiki.ubuntu.com/ToolChain

armel: soft-float ABI / hard-float ABI, padronizado para arm-linux-gnueabi.
armhf: hard-float ABI / soft-float ABI, padronizado para arm-linux-gnueabihf.

@gkhanna79 Se target significa "biblioteca de estrutura de base", o Tizen atual usa Microsoft.NETCore.App como uma estrutura de base para desenvolver aplicativos de usuário.
mas nós o usamos apenas como uma "estrutura base", o Tizen Apps não é executado como outro aplicativo dotnet.
Tizen não usou dotnet.exe ou outra ferramenta como corerun, coreconsole.
Tizen tem seu próprio launcher original e internamente usa interface de libcoreclr.so diretamente.
Neste modelo, binários e dlls em coreclr e Microsoft.NETCore.App devem ser pré-instalados no dispositivo e o aplicativo deve ser executado como Framework-dependent deployments . O pacote de aplicativos real tem apenas dll ou exe de aplicativo ou dependência do aplicativo.
mas hoje em dia preparamos outro modelo como Self-contained deployments . ele deve usar em dispositivo que não possui tempo de execução.
Quanto ao empacotamento, os aplicativos Tizen não são empacotados com nupkg. (usa tpk )
existem algumas APIs para aplicativos Tizen ( https://git.tizen.org/cgit/?q=csapi )
compilação interna para essas APIs no GBS e compilação para aplicativo de usuário no VisualStudio usam nupkg, mas o aplicativo não é compactado para nupkg.

@jyoungyun Eu concordo com @hqueue em seguir a convenção. Dado que já temos um RID "arm" (em https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/runtime.json), vamos usá-lo para hardfp (e sinônimo para armhf acima). Para suporte softfp, armel soa bem para mim e algo que devemos adicionar em https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/runtime.json.

CC @janvorli

Faz sentido para mim.

@hqueue @gkhanna79 @janvorli Também concordo com a opinião do @hqueue ! Parece bom para mim também. Vou postar um PR para apoiar a construção do armel na configuração do núcleo em breve.

@gkhanna79 @janvorli Legal! Preparamos PR para armel em CoreCLR e CoreFX e atualizamos a agenda desta edição para armel . Estamos trabalhando no Core-Setup também. Também atualizei o tópico Tizen na parte arm-softfp (armel). Dê uma olhada também :)

Nós temos um rootfs ubuntu.14.04 para Linux/arm-softfp agora e podemos construir para ubuntu.14.04 usando ARM softfp ABI.

@gkhanna79 Cometi um erro nas respostas anteriores. Para ARM softfp, usamos debian 8 (jessie) rootfs não ubuntu14.04 . Portanto rid será debian.8-armel se usarmos armel para ARM softfp.

@hqueue eu limpei/reordenei os itens de trabalho para armel e Tizen.

@gkhanna79 https://dotnet.myget.org/feed/aspnetcore-ci-dev/package/nuget/Libuv/1.10.0-preview1-22036 contém versões de braço do Libuv para Linux. Avise-me assim que o pacote for replicado e eu puder atualizar https://github.com/dotnet/core-setup/blob/master/pkg/projects/Microsoft.NETCore.App/project.json#L43

@moozzyk Fiz o upload para myget e deve estar visível assim que myget o tornar visível :)

@gkhanna79 - atualizado. Acho que você pode marcar "Build LibUV for Arm32 (Issue aspnet/libuv-build#19)". verificado.

@moozzyk Pronto!

@gkhanna79 Devemos fornecer sdk para liberar o arm and armel oficialmente? E .. o tarball do SDK deve suportar a resolução do NETCoreApp1.1 (será NETCoreApp2.0 ) para o lançamento oficial? Você pode nos dizer o que precisamos para nos preparar para um lançamento oficial? No momento, o tarball sdk que eu fiz do projeto cli não resolve NETCoreApp1.1 devido ao erro Unable to resolve dependency 'Microsoft.CodeAnalysis.CSharp' . Então eu estou querendo saber se eu tenho que resolver esse problema para o lançamento oficial e se eu tenho que corrigir roslyn para corrigi-lo.

Por favor @jyoungyun , você pode enviar seu projeto HellowWorld e as caixas? Eu tenho:
Raspberry Pi3 + ubuntu.16.04-arm + dotnet-ubuntu-arm.1.2.0-beta-001206-00.tar.gz.

Você poderia me dizer como compilar um projeto netcore para rodar no Raspberry? Estou usando janelas.

Obrigado

@scrambler86 Oi, eu anexei o tarball do SDK para o ubuntu.14.04-arm. Mesmo este arquivo é para o ubuntu.14.04-arm, mas acho que não há problema em executar no ubuntu.16.04-arm. Depois de instalar o tarball do SDK, você pode usar o comando dotnet new para criar um projeto HelloWorld. Eu costumo construir core-setup e projeto cli na seguinte ordem.

1. Compile CoreCLR para ubuntu.14.04-arm
2. Construir CoreFX para ubuntu.14.04-arm
3. Copie os nupkgs resultantes de CoreCLR e CoreFX para um diretório específico e adicione a linha abaixo ao arquivo NuGet.Config na configuração principal.

<add key="Local" value="The speicific directory path" />

1. Crie a configuração do Core com o comando ./build.sh --skiptests --env-vars DISABLE_CROSSGEN=1,TARGETPLATFORM=arm,TARGETRID=ubuntu.14.04-arm,CROSS=1,ROOTFS_DIR=/home/jyoung/git/dotnet/rootfs/arm .
2. Copie os resultados nupkgs do core-setup para um diretório específico e adicione a linha superior ao NuGet.Config no cli.
3. Construa cli com o comando ./build.sh --env-vars DOTNET_RUNTIME_ID=ubuntu.14.04-arm -c Release /p:CLIBUILD_SKIP_TESTS=true /p:DISABLE_CROSSGEN=1 .
   Mas para usar a opção --env-vars , o cli precisa de https://github.com/dotnet/cli/pull/5290 PR.

dotnet-sdk-ubuntu.14.04-arm.1.0.0-preview5-004431.tar.gz

@jyoungyun Obrigado por sua ajuda, é muito apreciada!
@scrambler86 Acabei de encontrar este post também que pode ser útil https://github.com/dotnet/core/blob/master/samples/RaspberryPiInstructions.md

Atualizei os tarballs de tempo de execução compartilhados para ubuntu.14.04 arm e ubuntu.16.04 arm. Esses tarballs contêm dlls libuv.so e CodeAnalysis que estavam faltando nos últimos tarballs.

E também carreguei os tarballs do SDK para o rpi3.
Você pode usá-lo na seguinte ordem.

1. Extraia o tempo de execução compartilhado correspondente e o sdk tar.gz para a mesma pasta em seu Pi e vá para essa pasta no terminal .
   dotnet-ubuntu.14.04-arm.1.2.0-beta-001291-00.tar.gz (tempo de execução compartilhado)
   dotnet-sdk-ubuntu.14.04-arm.1.0.0-preview5-004431.tar.gz (sdk)
   dotnet-ubuntu.16.04-arm.1.2.0-beta-001291-00.tar.gz (tempo de execução compartilhado)
   dotnet-sdk-ubuntu.16.04-arm.1.0.0-preview5-004431.tar.gz (sdk)

mkdir dotnet
tar xvzf dotnet-ubuntu.16.04-arm.1.2.0-beta-001291-00.tar.gz -C ./dotnet
tar xvzf dotnet-sdk-ubuntu.16.04-arm.1.0.0-preview5-004431.tar.gz -C ./dotnet

1. Faça um link simbólico de dotnet para /usr/bin/dotnet .
   ln -sf /usr/bin/dotnet /yourpath/dotnet/dotnet
2. Crie uma pasta chamada helloworld e entre nela.
3. Execute dotnet new e então dotnet restore e dotnet publish para publicar seu aplicativo helloworld.
   Mas, no meu caso, não consegui resolver NETCoreApp1.1 mesmo tendo os arquivos nupkg relacionados.

Acabei de enviar algumas instruções simples para o dotnet/core master. Eles apontam para alguns tarballs mais antigos. Vou ajustá-lo para apontar para estes. Ansioso para quando estes podem fazer parte da construção diária. :)

https://github.com/dotnet/core/blob/master/samples/RaspberryPiInstructions.md

@scrambler86 , nas próximas semanas, devemos conseguir publicar todos os pacotes para realmente criar um aplicativo autônomo no Windows que tenha como alvo o arm32 linux. É disso que precisamos para que a experiência do desenvolvedor no Windows visando o Raspberry Pi seja concluída. Por enquanto, se o aplicativo que você escreve não carrega o tempo de execução com ele e pode ser executado apenas no tempo de execução compartilhado, você poderá publicar no Windows e copiar a saída publicada para o seu Pi. Experimente e deixe-nos saber.

@jyoungyun , você tem um nuget.config que aponta para uma pasta local contendo seus pacotes? Sem isso, acho que não saberia como encontrá-los.

@jyoungyun Todas as ramificações principais serão atualizadas para resolver .NETCoreApp 2.0. No entanto, antes que isso aconteça, precisamos ter os pacotes nuget publicados nos quais estou trabalhando, pois o build-rootfs.sh falha em nossa infraestrutura de compilação oficial.

Então, todo esse belo trabalho está voltado para o 2.0, ou é a versão 1.2?

1.2 está em processo de ser renomeado 2.0

No entanto, antes que isso aconteça, precisamos ter os pacotes nuget publicados nos quais estou trabalhando, pois o build-rootfs.sh falha em nossa infraestrutura de compilação oficial.

@gkhanna79 Você tem problemas com buiild-rootfs.sh para arm e armel, ou seja, ./build-rootfs.sh arm e ./build-rootfs.sh armel ? Que tipo de problema você está sofrendo? Acho que também podemos investigar o problema, se possível.

Era algo sobre construir no Docker, que é como construímos muitas de nossas partes Linux de nossa construção.

@Petermarcu Sim, atualizei um arquivo NuGet.Config para apontar para uma pasta local contendo nossos nupkgs. Mas ainda não conseguiu resolver NETCoreApp1.1. A mensagem de erro é como abaixo.

Retrying 'FindPackagesByIdAsync' for source 'https://api.nuget.org/v3-flatcontainer/system.globalization/index.json'.
  A task was canceled.

Duvido que seja um problema da rede corporativa. Você já viu esse tipo de erro?

eu não tenho. @ericstj alguma opinião?

O NuGet geralmente falhará se tiver algum feed em sua lista que não possa ser resolvido. A restauração do NuGet/dotnet geralmente ecoará todos os feeds que está usando, bem como todas as fontes de configuração para o console quando você executá-lo. Verifique se você não está usando feeds nuget que não podem ser resolvidos em sua rede privada.

Ok, 2.0 é. Obrigado @stevedesmond-ca.
Então, o esforço de configuração principal para o braço será lançado na versão 2.0?

Era algo sobre construir no Docker, que é como construímos muitas de nossas partes Linux de nossa construção.

@Petermarcu @gkhanna79 FYI. Entre rootfs de braço, rootfs for armel( Tizen ) (construído a partir de build-rootfs.sh armel tizen ) tem uma estrutura mais simples do que outros rootfs ( ubuntu e debian ) e requer menos esforço. Por exemplo, armel( Tizen ) rootfs contém apenas componentes necessários para compilação (cerca de 100 MB), mas outros rootfs, ou seja, arm ( Ubuntu ) e armel ( Debian ), tem todos os componentes Linux da distribuição Linux padrão (cerca de 700 MB) e requer operação debootstrap com sudo previdenciário durante build-rootfs.sh . Portanto, requer mais recursos, incluindo largura de banda de rede, armazenamento e computação.
Também experimentamos falhas em algum momento na caixa do host x64 Linux ao construir rootfs para ubuntu-arm e debian-armel devido a vários motivos, incluindo problemas de rede e etc. Raiz de Tizen.

@hqueue O fato de as imagens do Docker serem um contêiner e não um ambiente virtualizado criou problemas - não teve nada a ver com a criação do rootfs.

O problema específico foi que eu consegui compilar o LinuxArm32 na imagem do Docker na minha máquina de desenvolvimento, mas não consegui fazê-lo em nossa compilação oficial. Depois de investigar várias opções, adotei uma abordagem diferente para comparar as diferenças entre o caso de sucesso e o caso de falha. O problema é que, mesmo quando tentada em um contêiner do Docker, a compilação cruzada espera (na invocação do segundo estágio que o qemu-debootstrap inicia) que a máquina host tenha as dependências de compilação cruzada também instaladas. Como eles não estavam presentes na imagem do sistema operacional host em nossa compilação oficial e presentes apenas no contêiner do Docker, a compilação cruzada no contêiner do Docker falharia.

Eu tirei uma de nossas máquinas oficiais de compilação ontem, instalei os pacotes ausentes e consegui uma compilação limpa do Linux Arm32 em uma imagem do Docker finalmente! :) Vou atualizar nossas máquinas oficiais e em breve começarei isso.

Com o que foi dito acima, precisamos produzir .NET Core para armhf e armel. Assim, debian.8-armel ou Tizen armel build será um aditivo e não uma alternativa ao armhf build.

@gkhanna79 Fico feliz em ouvir o progresso e obrigado por todos os seus esforços :)

Atualizando o thread primário - a compilação do pipeline CoreCLR agora está publicando pacotes Arm32 (armhf) para Ubuntu 14.04 e Ubuntu 16.04 no myget! Aqui está o primeiro conjunto de pacotes que foram publicados hoje a partir do repositório:

https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.ubuntu.14.04-arm.Microsoft.NETCore.Runtime.CoreCLR

https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.ubuntu.16.04-arm.Microsoft.NETCore.Runtime.CoreCLR

@gkhanna79 Em primeiro lugar, muito obrigado por publicar pacotes para CoreCLR :)

Testamos com os pacotes acima, mas infelizmente, acho que tem bug devido a clang que é usado ao construir o CoreCLR.

O llvm-3.8 atual e abaixo não pode compilar CoreCLR e CoreFX corretamente com otimização -O3 para ARM, porque eles têm bug relacionado ao TLS. Você pode encontrar detalhes em https://github.com/dotnet/coreclr/blob/master/Documentation/building/linux-instructions.md#how -to-enable--o3-optimization-level-for-armlinux
(Há muitos problemas relacionados a isso. Um deles é https://github.com/dotnet/coreclr/issues/6530 )

Portanto, acho que devemos considerar a atualização da versão do llvm para o lançamento do ARM e também discutiremos esse problema com o problema dotnet/core-setup#790 (arm32 CI). Vamos passar para dotnet/core-setup#790 e continuarei a discussão lá.

BTW A solução mais simples é usar "-O1" em vez de "-O3" ao construir o CoreCLR com infra-estruturas atuais.

Muito bem @hqueue - continuarei a discussão com você em dotnet/core-setup#790.

Atenção, caso alguém mais os queira, tenho compilações automatizadas do .NET Core Runtime para ubuntu.16.04-arm funcionando agora, por meio de vários scripts bash.

https://github.com/stevedesmond-ca/dotnet-arm/releases/

Estou planejando publicar nightlies (incluindo o SDK na próxima semana) até que as compilações oficiais de CI possam ser configuradas.

Excelente @stevedesmond-ca! Estou trabalhando no suporte CoreFX para compilações oficiais agora.

BTW, suas compilações são para o Ubuntu 14.04 ou 16.04? E imagino que você já esteja consumindo os pacotes que publicamos para o CoreCLR, certo?

16.04 só agora. Estou construindo o CoreCLR e o CoreFX do zero e, em seguida, alimentando os artefatos deles na configuração do núcleo, muito semelhante a como @jyoungyun descrito aqui .

Uma vez que o CoreCLR no myget é construído com -O1 (atualmente eu recebo o -O3 TLS segfault do que é puxado para baixo), deve ser mais fácil usar compilações oficiais. Eu acho que há valor em poder fazer tudo offline, desacoplar o processo de construção do processo de publicação de CI atual, mas isso é apenas minha preferência pessoal.

@stevedesmond-ca Eu tentei executar seu contêiner docker integrado no meu RPi3 com o seguinte dockerfile:

FROM armv7/armhf-ubuntu:16.04

ENV VERSION 2.0.0-beta-001455-00

RUN apt-get update -q -y && \
apt-get upgrade -q -y && \
apt-get install -q -y wget

RUN wget https://github.com/stevedesmond-ca/dotnet-arm/releases/download/$VERSION/dotnet-ubuntu-arm.$VERSION.tar.gz && \
mkdir -p /usr/share/dotnet && \
tar -xf dotnet-ubuntu-arm.$VERSION.tar.gz -C /usr/share/dotnet/ && \
ln -sf /usr/share/dotnet/dotnet /usr/bin/dotnet

RUN mkdir dotnet
COPY dotnet-arm/hello-world/hello-world.csproj dotnet/hello-world.csproj
COPY dotnet-arm/hello-world/hello-world.deps.json dotnet/hello-world.deps.json
COPY dotnet-arm/hello-world/hello-world.dll dotnet/hello-world.dll
COPY dotnet-arm/hello-world/hello-world.pdb dotnet/hello-world.pdb
COPY dotnet-arm/hello-world/hello-world.runtimeconfig.json dotnet/hello-world.runtimeconfig.json
COPY dotnet-arm/hello-world/Program.cs dotnet/Program.cs

Em seguida, inicio o contêiner com docker run -it core /bin/bash e executo na pasta dotnet dotnet hello-world.dll , mas recebo um erro:

Failed to load /usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.0-beta-001455-00/libcoreclr.so, error: libunwind.so.8: cannot open shared object file: No such file or directory
Failed to bind to CoreCLR at '/usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.0-beta-001455-00/libcoreclr.so'

Alguma dica sobre o erro estúpido que estou cometendo?

@bjoernbusch confira https://github.com/dotnet/core/blob/master/samples/RaspberryPiInstructions.md - especificamente a parte "prereq packages" - é provável que eles não estejam na imagem base

Sim! facepalm era isso, agora está funcionando! Obrigado!

@stevedesmond-ca Obrigado por compartilhar seu tarball :) Funciona bem no meu PI3 de framboesa também. Agora estou tentando construir a configuração do núcleo usando o docker. Seu sistema de CI usa o docker para liberar, não é? Mas quando tentei construir com o docker, me deparei com um pequeno problema que todos os argumentos que correspondem ao argumento do docker foram removidos por https://github.com/dotnet/core-setup/blob/master/build.sh#L36L37 linhas. Você já construiu o core-setup para o Ubuntu.16.04-arm no docker? Minha linha de comando de compilação é como abaixo. Após analisar build.sh, alguns argumentos são removidos.

./build.sh --docker ubuntu.16.04 --env-vars "DISABLE_CROSSGEN=1,TARGETPLATFORM=arm,TARGETRID=ubuntu.16.04-arm,CROSS=1,ROOTFS_DIR=/opt/code/cross/rootfs/arm"
->
Argumtens~~~~:--env-vars DISABLE_CROSSGEN=1,TARGETPLATFORM=arm,TARGETRID=-arm,CROSS=1,ROOTFS_DIR=/opt/code/cross/rootfs/arm

Em breve farei um PR. Se eu estiver errado, me avise.

Estou apenas fazendo minhas compilações a partir de uma VM xenial, sem Docker envolvido.

Obrigado por compartilhar o tarball do debian softfp! Consegui fazê-lo funcionar em uma das plataformas embarcadas com as quais normalmente trabalho (O NI roboRIO para FRC). Funcionou fantasticamente e até foi capaz de executar um programa baseado em soquete bastante complexo sem problemas que eu pudesse encontrar. Vai ser tão bom não ter que compilar mais o Mono.

Funcionou fantasticamente, e até foi capaz de executar um programa baseado em soquete bastante complexo sem problemas que eu pudesse encontrar

@ThadHouse Fico feliz em saber que ajuda. E também tenho que ouvir que aplicativos complexos reais são executados em dotnet para debian (softfp) em dispositivo real :)

@ThadHouse Na verdade eu testei a operação para o tarball debian.8-armel no DockerImage usando rpi3. É realmente uma boa notícia que funciona bem no dispositivo real. :)

@gkhanna79 Você poderia me informar o progresso do upload do nupkg para o braço na configuração do núcleo? AFAIK isso deve ser precedido, os nupkgs do CoreFX podem fazer o upload para o MyGet Feed. Obrigado por seu apoio contínuo.

@jyoungyun Fiz builds de teste no fim de semana e eles parecem bons e esperam tê-los funcionando até terça-feira, se tudo correr bem. Vou manter esta discussão atualizada com o status.

Se você obtiver os pacotes NuGet, ficarei feliz em ajudar a testar a versão debian.8.

Note que na verdade não estou testando em um sistema debian, mas na verdade é um sistema arch. Mas tem o mesmo sysroot, ou muito próximo do que posso dizer.

@ gkhanna79 Meu erro :( O upload de nupkgs do CoreFX deve estar à frente do trabalho de configuração do núcleo. E encontrei os nupkgs do CoreFX para ARM no dotnet-core myget. Obrigado.

Agora temos versões do Ubuntu 14.04 e 16.04 Arm32 sendo publicadas diariamente! Aqui está o primeiro conjunto de pacotes que saiu hoje:

https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.ubuntu.14.04-arm.Microsoft.NETCore.App/2.0.0-beta-001559-00

https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.ubuntu.16.04-arm.Microsoft.NETCore.App/2.0.0-beta-001559-00

Agora temos versões do Ubuntu 14.04 e 16.04 Arm32 sendo publicadas diariamente! Aqui está o primeiro conjunto de pacotes que saiu hoje:

Isso é ótimo! Existem planos para uma compilação arm32 portátil? Seria super ter o dotnet rodando
Rasbian, Fedora, ... também.

@tmds Sim, planejamos analisar isso em breve.

existe alguma compilação que eu possa usar no Raspbian Pixel agora? Hoje atualizei minha distro que de alguma forma quebrou o mono que eu estava usando até este ponto. Se não, existe algum ETA nas compilações que podem ser usadas no raspberry pi?

@TheRadziu Não tenho certeza se funciona no pixel raspbian corretamente ou não, mas https://dotnetcli.blob.core.windows.net/dotnet/master/Binaries/Latest/dotnet-ubuntu.16.04-arm.latest.tar .gz é para ubuntu-mate (ubuntu.16.04-arm) e funciona bem no meu rpi3 com ubuntu-mate.
Tanto o raspbian quanto o ubuntu-mate são baseados no debian, então acho que você também pode experimentá-lo no raspbian. Se houver um problema de versão, o ubuntu.14.04-arm também está disponível em https://dotnetcli.blob.core.windows.net/dotnet/master/Binaries/Latest/dotnet-ubuntu-arm.latest.tar.gz.

Você pode encontrá-los na página de compilação diária em https://github.com/dotnet/core-setup/.

@hqueue obrigado pela sua resposta! Infelizmente não consigo fazer funcionar
./dotnet: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version GLIBCXX_3.4.21' não encontrado (requerido por ./dotnet) when I checked it by strings /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 | grep GLIBCXX`ele listou GLIBCXX_3.4 até GLIBCXX_3.4.20 .
Gostaria de saber se posso atualizá-lo de alguma forma

@TheRadziu Por favor, tente ubuntu.14.04-arm em https://dotnetcli.blob.core.windows.net/dotnet/master/Binaries/Latest/dotnet-ubuntu-arm.latest.tar.gz

Parece que o ubuntu.14.04-arm requer 3.4 e 3.4.18 e não 3.4.21.

@TheRadziu @hqueue fyi, glibc tem um recurso de compatibilidade com versões anteriores. A compilação linux x64 portátil do dotnet requer, no mínimo, a glibc 2.14. A compilação arm32 portátil terá um requisito semelhante.

@gkhanna79 Descobri que o dotnet/core-setup#789 (Ativar suporte ao Pipeline Build para Linux Arm32) está fechado recentemente para arm.
Podemos adicionar "Enable Pipeline build support for Linux Arm32" para armel(tizen) e criar um novo problema para o item? Deixe-nos saber o seu plano para o pipeline armel, para que possamos acompanhar o ritmo com você :)

@hqueue Sim, crie um novo problema (atribuído a mim) para a compilação do pipeline do Tizen para cada um dos 3 repositórios e adicione-o à lista de itens de trabalho do Tizen acima.

@gkhanna79 O que você tem em um plano de lançamento 2.0.0 sobre sdk ? Atualmente não consigo encontrar o branch para a versão 2.0.0 em cli .

@jyoungyun , dê uma olhada no branch master do repositório cli.

@hqueue @hseok-oh @jyoungyun Na última semana, mudei nossas compilações oficiais de pipeline para usar as imagens do Docker _ubuntu1404_cross_prereqs_v2_ e _ubuntu1604_cross_prereqs_v2_ que contêm o conjunto de ferramentas arm32 em _/crossrootfs/arm_. Você pode atualizar os scripts de CI que você está adicionando/adicionado para repositórios CoreCLR/CoreFX/Core-Setup para usá-los e remover a etapa build-rootfs?

@gkhanna79 Legal! Vamos atualizar o script.

@Petermarcu Obrigado!

Estou tentando criar uma API Web do .NET Core para meu Raspberry Pi 3 executando o Ubuntu 16.04 com o tempo de execução lates 2x. Estou usando o Visual Studio Code no meu Windows ao desenvolver. Minha versão atual do SDK é 2.0.0-alpha-004853 , mas quando eu faço dotnet new webapi ele adiciona essas referências de pacote no meu arquivo csproj:

<PackageReference Include="Microsoft.AspNetCore" Version="1.0.3" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.0.2" />
<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.0.1" />

Ouvi dizer que esse é o motivo pelo qual não consigo executá-lo quando tento publicar o arquivo usando dotnet publish --runtime ubuntu.16.04-arm . Talvez existam outros problemas que eu possa encontrar também.

Eu sou relativamente novo em tudo isso, então não tenho certeza de qual é o meu próximo passo. Como incluo os 2x compatíveis? O que estou tentando fazer é possível no momento?

@challe Por favor, registre um problema no repositório CLI para conduzir a discussão sobre como obter um SDK CLI que suporte a estrutura 2.0 (que está em desenvolvimento no momento).

Eu farei isso. Obrigado.

Oi, tentei executar a versão 1.0.0-preview5-004431, mas não funciona. Não funciona nem com hello world. Alguém pode me dizer se existe alguma versão funcional que eu possa usar? Se puder, poste o link para download. Obrigada.

@rahulreddy65 Vamos discutir isso em https://github.com/dotnet/cli/issues/5868.

@gkhanna79 Aplique dois itens nas imagens do docker na próxima atualização das imagens do docker.

• Adicione rootfs x86 e cadeia de ferramentas no ubuntu1404 ou/e 1604 (e nova imagem docker x86 para teste). Estamos preparando a compilação x86 linux CI.
• Aplique dotnet/coreclr#9897 no rootfs do ubuntu1404 para construir libcoreclrtraceptprovider.so

Eu cria um novo problema para a imagem do docker x86. dotnet/coreclr#9903.

@gkhanna79 Posso saber quando os nupkgs tizen são enviados para o servidor MyGet? Eu quero habilitar tizen CI na configuração do núcleo. E... você vai carregar o tarball do braço do Ubuntu para o servidor Azure? Estou tentando construir o cli para o braço do ubuntu, mas depende do servidor do Azure para baixar o tarball de tempo de execução.

O tarball do Ubuntu está disponível - consulte https://dotnetcli.blob.core.windows.net/dotnet/master/Binaries/Latest/dotnet-ubuntu.16.04-arm.latest.tar.gz. Isso não ajuda @jyoungyun ?

Oh, eu vejo. Eu posso usá-lo. O mesmo tarball está em ambos os caminhos abaixo. Obrigada.
https://dotnetcli.blob.core.windows.net/dotnet/master
https://dotnetcli.azureedge.net/dotnet/master

@ gkhanna79 Você deseja habilitar o ubuntu 16.04 arm CI por padrão?

@jyoungyun Existe uma diferença significativa entre o 14.04 e o 16.04? IMHO, a menos que comecemos a ver problemas exclusivos para ele (que se manifestarão como quebras de compilação no pipeline oficial), ter um deve ser suficiente. O que você acha?

@hqueue Estou correto na minha suposição de que esta compilação dotnet-debian.8-armel.1.2.0-beta-001271-00.tar.gz deve ser executada no PI Zero Raspbian?
Eu tentei, mas recebo falha de segmentação ao executar o comando dotnet. Alguma coisa que eu possa fazer para resolver?

Acho que não funciona no Pi Zero. Acho que ninguém olhou o porquê.

@olegsavelos a compilação debian.8-armel não funcionará em um raspberry pi zero. Todas as compilações aqui são para dispositivos armv7, com as diferentes versões selecionando entre hard float ABI e soft float ABI. O Pi Zero (e o Pi original) é um dispositivo armv6. Eu não sei o que será necessário para que o armv6 funcione e construa, mas pode variar de bastante fácil (mudança de sinalizadores do compilador) a muito difícil. Eu simplesmente não sei.

Alguém pode lançar alguma luz sobre o suporte Armv6?

@jyoungyun , o .net core tizen build funcionará em uma imagem incluindo https://github.com/TizenTeam/meta-tizen no yocto?

@olegsavelos Se você quis dizer PI Zero com Broadcom BCM2835, temo que não seja fácil trabalhar dotnet-debian.8-armel.1.2.0-beta-001271-00.tar.gz no seu Pi Zero. Também concordo com @ThadHouse que o PI Zero é baseado no armv6 e pode variar de fácil a muito difícil.

O dotnet atual do AFAIK para ARM usa o Thumb-2 ISA que não está disponível no armv6 e o ​​recurso vfp que está disponível principalmente no armv7, mas apenas opcionalmente disponível no armv6. Armv6 suporta o Thumb antigo e não o Thumb2, portanto você pode ter que construir (1) todos os componentes nativos do dotnet para armv6 e também (2) pode ter que atualizar o compilador JIT e o subcomponente (escrito em linguagem assmebly) do CoreCLR e CoreFX para fazer uso de Thumb ISA e recurso vfp suportado de Broadcom BCM2835 em vez de armv7. Mas não posso estimar quanto esforço será necessário.

Mono parece estar funcionando bem no armv6, então não seria possível portar as partes do código relacionadas ao armv6 para o .net core? De qualquer forma, acho que o PI Zero é uma excelente plataforma para uma ampla gama de soluções e seria uma pena não suportá-lo.

Alguém pode me dizer quando poderei construir e executar programas no arm32 linux? obrigado

@rahulreddy65 Se você estiver usando o Ubuntu 14.04 ou o Ubuntu 16.04 para arm, acho que você pode executar programas C # no arm32 linux instalando o binário de https://github.com/dotnet/core-setup#daily -builds.

• Ubuntu 14.04-arm https://dotnetcli.blob.core.windows.net/dotnet/master/Binaries/Latest/dotnet-ubuntu-arm.latest.tar.gz
• Ubuntu 16.04-arm https://dotnetcli.blob.core.windows.net/dotnet/master/Binaries/Latest/dotnet-ubuntu.16.04-arm.latest.tar.gz

Se você deseja compilar o programa C# a partir do arm32 linux, ele ainda não está disponível. No entanto, você pode compilar o programa C# de outro ambiente, por exemplo, x64 linux ou x64 Windows, e executar o programa no braço do Ubuntu.

E há outra maneira de simplesmente construir e executar o programa C# para arm32 linux com o runtime framework versão 2.0.0-beta-001620-00 e posterior. Por favor, dê uma olhada em https://github.com/dotnet/core/blob/master/samples/RaspberryPiInstructions.md
No entanto, também requer um ambiente x64 para compilar o programa C#.

@olegsavelos Acho melhor você abrir um problema sobre o suporte ao armv6 em https://github.com/dotnet/coreclr , porque a maioria dos trabalhos necessários são relevantes para o coreclr e os especialistas que podem responder às suas perguntas (por exemplo, suporte a nova CPU) são ali também :)

@hqueue Obrigado! Farei isso :)

Finalmente, obtive resultados abaixo!!!

pi3<strong i="6">@raspberry</strong>:~/Downloads/c$ time NUGET_PACKAGES=/home/pi3/Downloads/c/p dotnet build
Microsoft (R) Build Engine version 15.2.47.30403
Copyright (C) Microsoft Corporation. All rights reserved.

  c -> /home/pi3/Downloads/c/bin/Debug/netcoreapp2.0/c.dll

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

Time Elapsed 00:00:27.08

real    0m40.917s
user    0m43.890s
sys 0m1.390s

pi3<strong i="7">@raspberry</strong>:~/Downloads/c$ time NUGET_PACKAGES=/home/pi3/Downloads/c/p dotnet run
Hello World!

real    0m51.861s
user    0m54.380s
sys 0m1.870s

O desempenho é muito... baixo, mas o Raspberry PI pode construir o próprio arquivo cs!

@jyoungyun são esses resultados da compilação de lançamento do coreclr?

@janvorli Todo o nupkg usado na compilação do cli foi baixado do servidor myget, então este tempo de execução (coreclr) é o build de lançamento com a opção -O1. Se clang3.9 estiver habilitado, o resultado será mais rápido. :)

@jyoungyun foi descoberto em outro problema que o comando dotnet run adiciona bastante sobrecarga ao início do aplicativo gerenciado (no x64 Linux, adiciona cerca de 2 segundos) em comparação com a passagem do assembly gerenciado diretamente para o dotnet sem o "run" .
Você poderia tentar medir esse caso também? Só para ficar claro, quero dizer correr time dotnet /home/pi3/Downloads/c/bin/Debug/netcoreapp2.0/c.dll

@janvorli No raspberry PI3, passar dll como argumento directy é cerca de 40 segundos mais rápido do que usar dotnet run. Isso parece ser muita sobrecarga no comando dotnet run ...

pi3<strong i="7">@raspberry</strong>:~/Downloads/c$ time dotnet run
Hello World!

real    0m44.373s
user    0m56.000s
sys 0m1.800s

pi3<strong i="8">@raspberry</strong>:~/Downloads/c$ time dotnet /home/pi3/Downloads/c/bin/Debug/netcoreapp2.0/c.dll
Hello World!

real    0m1.389s
user    0m1.340s
sys 0m0.040s

@jyoungyun Obrigado por medi-lo! Nós realmente precisamos fazer algo com isso. Adicionarei essas informações ao outro problema em que a lentidão foi relatada para x64.

@janvorli @jyoungyun Acho que uma das grandes diferenças do timz pode ser devido à falta de imagem nativa para o arm cli, que pode estar disponível para o próprio x64 cli.

Bem, mesmo no x64, há uma enorme diferença nessas duas maneiras de iniciar o aplicativo. Veja https://github.com/dotnet/cli/issues/6241

Eu vejo muito progresso relacionado ao Raspberry PI 2/3 e Ubuntu... mas o que é necessário para que meu projeto dotnet core 2 seja executado em um i.MX7 (Cortex-A7) com um linux baseado em angstrom ?

Do meu entendimento limitado, a arquitetura deve ser armhf, que é a arquitetura padrão em todos os guias de compilação cruzada dotnet que encontrei até agora.

Comecei a compilar CLR e FX, mas tudo parece centrado no Ubuntu. O resultado funcionará no angstrom, desde que os pré-requisitos necessários (como libunwind, etc) estejam instalados?

@nzain - tente executar usando Linux (armhf) (para SO baseado em glibc) na tabela em core-setup-readme .
Isso funciona bem para nós (imx6 yocto poky), no entanto, você pode ter que trazer dependências nativas para o seu os -dist manualmente.
Observe também que dotnet/core-setup#2358 não está completamente resolvido, mas o código é mesclado, então pode ser que as correções não sejam validadas.

O .NET Core 2.0 funciona perfeitamente em um Raspberry Pi 3 com Raspbian Jessy Lite. O seguinte é necessário para fazê-lo funcionar:

Na instalação vanilla do SO execute: sudo apt install libunwind8

Em seu projeto .NET Core, inclua:

<TargetFramework>netcoreapp2.0</TargetFramework>
<RuntimeIdentifiers>win10-x64;linux-arm</RuntimeIdentifiers>

Para publicar na linha de comando/vscode:

dotnet restore
dotnet build
dotnet publish --output Publish --runtime linux-arm

Quando o nome do seu projeto for MyProject: copie todos os arquivos no diretório Publish para o Pi e execute

chmod 744 MyProject
./MyProject

Aproveitar :)

@hqueue @jyoungyun Podemos fechar este problema já que o problema pendente (de acordo com a lista acima) está no repositório CoreCLR e rastreado por https://github.com/dotnet/coreclr/issues/8549?

@gkhanna79 Claro. Vou marcar https://github.com/dotnet/coreclr/issues/8549 na lista como feito com comentário.

O fechamento deste problema e os problemas restantes do CoreCLR serão discutidos em https://github.com/dotnet/coreclr/issues/8549