Posso usar um chroot na minha máquina de desenvolvimento para criar um aplicativo para ser executado na instalação do Linux incorporado?

Posso usar um chroot na minha máquina de desenvolvimento para criar um aplicativo para ser executado na instalação do Linux incorporado?

Estou tentando desenvolver um aplicativo para ser executado em uma instalação Linux incorporada. Ele vem com uma versão mais antiga da libc do que a que tenho em minha máquina de desenvolvimento. Se eu criasse um ambiente chroot em minha máquina de desenvolvimento, copiasse as bibliotecas do meu dispositivo incorporado de forma que o ambiente chroot espelhe o dispositivo e depois construísse o aplicativo, seria seguro executar no dispositivo? Minha máquina de desenvolvimento e o dispositivo são x86 de 32 bits, então não acho que precise fazer compilação cruzada.

Além disso, o aplicativo que escrevo requer link para bibliotecas adicionais (que não estão presentes no dispositivo). Estou seguro para construir essas bibliotecas na máquina de desenvolvimento no chroot e depois apenas copiá-las para o dispositivo para implantação do aplicativo?

De todas as leituras que fiz sobre este assunto, parece que a única maneira de garantir que tudo se conecte corretamente seria construir o aplicativo no dispositivo, mas isso não é uma opção, pois é uma instalação mínima e não vem com instalação do gcc.

Responder1

Isso geralmente funcionará. Eu apenas tentaria, mas há algumas coisas que você precisa estar ciente:

  • Ao construir, os binários precisam ser construídos para a arquitetura de CPU e os recursos do seu destino. Dado que ambos são x86, isso ajudará muito, mas você ainda precisa ter cuidado ao usar recursos do processador como sse3, etc. não funciona.

  • O kernel do seu sistema de compilação pode exercer alguma influência sobre o comportamento do seu ambiente chroot. Você não pode usar um kernel diferente para um chroot versus o sistema host, então você pode encontrar discrepâncias entre os dois. Os aplicativos geralmente se comunicam com o kernel via libc, que fornece uma interface padrão que pode ajudar a evitar tais problemas.

  • Sua libc precisa ser compatível com seu kernel, até certo ponto. A libc do seu sistema embarcado pode não ser totalmente compatível com o seu kernel, dependendo das alterações na interface; entretanto, se a libc for anterior ao seu kernel, é improvável que isso seja um problema (é mais provável que as interfaces antigas do kernel permaneçam para suportar binários antigos).

  • Os serviços do seu sistema host ficarão visíveis para o seu sistema embarcado. Isso é comum a qualquer chroot, pois eles compartilham tabelas de processos, interfaces de rede, etc.

  • Para suas 'bibliotecas adicionais', você pode usar links estáticos para vinculá-las ao seu aplicativo. Então você pode evitar a implantação das bibliotecas no dispositivo. Sua milhagem pode variar.

Você pode considerar usar uma máquina virtual para fazer isso. Isso não removerá necessariamente todas as preocupações (como recursos/sinalizadores do processador), mas você pode ter um ambiente que corresponda muito mais ao seu sistema embarcado. Ou seja, você pode usar o mesmo kernel, executar o mesmo processo de boot, evitar a contaminação pelos serviços do host...

Esteja ciente de que se você configurar um conjunto de ferramentas de construção dentro de seu chroot, você pode querer pensar em como copiará os novos arquivos de volta para seu sistema embarcado; você provavelmente não deseja copiar os arquivos do conjunto de ferramentas (gcc, etc).

Tente configurá-lo e escrever um aplicativo de teste, construir algumas bibliotecas ou qualquer outra coisa, e ver como elas funcionam bem quando movidas para o sistema embarcado.

informação relacionada