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