임베디드 Linux 설치에서 실행할 애플리케이션을 개발하려고 합니다. 내 개발 작업에 사용된 것보다 이전 버전의 libc가 함께 제공됩니다. 개발 컴퓨터에 chroot 환경을 만들고 chroot 환경이 장치를 미러링하는 방식으로 임베디드 장치에서 라이브러리를 복사한 다음 응용 프로그램을 빌드한다면 장치에서 실행해도 안전합니까? 내 개발 컴퓨터와 장치는 모두 x86 32비트이므로 크로스 컴파일할 필요가 없다고 생각합니다.
또한 내가 작성하는 애플리케이션이 추가 라이브러리(장치에 없는)에 대한 연결을 요구해야 한다면 chroot의 개발 시스템에 이러한 라이브러리를 빌드한 다음 애플리케이션 배포를 위해 장치에 복사해도 안전합니까?
이 주제에 대해 내가 읽은 모든 내용에 따르면 모든 것이 올바르게 연결되도록 할 수 있는 유일한 방법은 실제로 장치에 응용 프로그램을 구축하는 것입니다. 그러나 이는 최소 설치이므로 옵션이 아닙니다. gcc 설치와 함께 제공됩니다.
답변1
이것은 일반적으로 작동합니다. 한번 시도해 보려고 합니다. 하지만 알아두어야 할 몇 가지 사항이 있습니다.
빌드할 때 대상의 CPU 아키텍처 및 기능에 맞게 바이너리를 빌드해야 합니다. 둘 다 x86이라는 점을 고려하면 많은 도움이 되겠지만 sse3 등과 같은 프로세서 기능을 사용할 때는 여전히 주의해야 합니다. 대상 설치에 없는 기능을 활용하는 바이너리를 빌드하면 성공합니다. 작동하지 않습니다.
빌드 시스템의 커널은 chroot된 환경의 동작에 어느 정도 영향을 미칠 수 있습니다. chroot와 호스트 시스템에 서로 다른 커널을 사용할 수 없으므로 둘 사이에 불일치가 발생할 수 있습니다. 앱은 일반적으로 궁극적으로 이러한 문제를 방지하는 데 도움이 되는 표준 인터페이스를 제공하는 libc를 통해 커널과 통신합니다.
libc는 어느 정도 커널과 호환되어야 합니다. 인터페이스 변경에 따라 임베디드 시스템의 libc가 커널과 완전히 호환되지 않을 수 있습니다. 그러나 libc가 커널보다 이전 버전이라면 이는 문제가 되지 않을 것입니다(오래된 커널 인터페이스는 이전 바이너리를 지원하기 위해 계속 남아 있을 가능성이 더 높습니다).
호스트 시스템의 서비스는 임베디드 시스템에 표시됩니다. 이는 프로세스 테이블, 네트워크 인터페이스 등을 공유하므로 모든 chroot에 공통적입니다.
'추가 라이브러리'의 경우 정적 링크를 사용하여 이를 애플리케이션에 연결할 수 있습니다. 그러면 라이브러리를 디바이스에 배포하지 않아도 됩니다. 귀하의 마일리지가 다를 수 있습니다.
대신 가상 머신을 사용하여 이 작업을 수행하는 것을 고려할 수 있습니다. 프로세서 기능/플래그와 같은 모든 문제가 반드시 제거되는 것은 아니지만 임베디드 시스템과 훨씬 더 밀접하게 일치하는 환경을 가질 수 있습니다. 즉, 동일한 커널을 사용하고, 동일한 부팅 프로세스를 실행하고, 호스트 서비스에 의한 오염을 피할 수 있습니다...
chroot 내에 빌드 도구 체인을 설정하는 경우 새 파일을 임베디드 시스템에 다시 복사하는 방법에 대해 생각해 볼 수 있습니다. 아마도 툴체인 파일(gcc 등)을 복사하고 싶지 않을 것입니다.
이를 설정하고 테스트 애플리케이션을 작성하고, 라이브러리 등을 구축하고, 임베디드 시스템으로 이동했을 때 얼마나 잘 작동하는지 확인하십시오.