우선 비슷한 질문을 찾았습니다.휴대용 Linux 앱을 만드는 방법은 무엇입니까?그러나 그것은 내 질문을 실제로 해결하지는 않습니다. 그것은 아래에서 설명할 배포에 관한 것이 아니라 이미 수행 방법을 알고 있는(적어도 나는 알고 있다고 생각합니다) 응용 프로그램을 이식 가능하게 만들기 위해 컴파일하는 방법에 관한 것입니다.
이것이 내 상황입니다. 우리는 고객의 특정 문제를 해결하기 위해 고용되었으므로 고객에게 판매할 비공개 소스 애플리케이션을 개발할 것입니다. 그러나 우리는 그것이 어디에서 실행될 수 있어야 하는지에 대한 구체적인 정보를 제공받지 못했습니다. 즉, 배포판, 커널 버전 또는 기타 사항을 의미합니다. 작업은 매우 간단하며 저수준 드라이버나 이식성을 어렵게 만드는 어떤 것에 의존하지 않습니다. 그러나 우리는 몇 가지 타사 라이브러리에 의존합니다. 다음은 종속성에 대한 간단한 체계입니다.
app --+-- libA
| +-- lib1
+-- libB --+-- lib2
+-- lib3
여기서 libA,B 및 lib1,2,3은 모두 적절한 라이선스(LGPL, ASL 및 BSD)가 있는 오픈 소스 프로젝트입니다. 일단 컴파일되면 우리 프로그램의 공유 종속성은 libA, libB, lib1, lib2, lib3 및 libc, libm, libz, libstdc++, libpthread 등과 같은 여러 시스템 라이브러리가 됩니다. 모든 것이 동적으로 연결됩니다.
이제 대상 배포판이 없으므로 .deb 등과 같은 패키징 시스템과 독립적으로 유지하려고 합니다. 직접적인 종속성(libA 및 libB)은 그다지 일반적이지 않으므로 애플리케이션과 함께 이를 모두 제공하는 것이 확실한 선택입니다. lib1,2,3은 실제로 더 일반적이지만(즉, 그 중 하나가 libpng임) 대상 시스템에 설치될지는 아직 확실하지 않습니다. 우리는 최종 소프트웨어 패키지에 5개 모두를 포함하기로 결정했습니다.
우리가 무엇을 해야할지 전혀 모르는 것은 시스템 라이브러리입니다. 이 문제를 어떻게 처리해야 합니까? 우리는 그들이 올바른 라이브러리를 갖고 있고 최선을 다할 것이라고 가정하고 있습니까? 이러한 경우, 해당 라이브러리 중 하나가 변경되고 애플리케이션 작동이 중지되면 1~2년 후에 어떻게 될까요?
우리 소프트웨어와 함께 모든 것(libstdc++, glibc 등)을 배포해야 합니까? 이것은 옳지 않다고 생각하며 라이선스 조건에 어긋날 수도 있다고 생각합니다. 나는 과거에 [적어도] 일부 라이브러리의 자체 사본을 실제로 운반하는 일부 프로그램을 사용했다는 것을 알고 있습니다. 그것은 내 시스템에 있는 버전보다 오래된 버전이었고 상호 교환으로 인해 모든 것이 중단되었기 때문에 실제로 관심을 끌었습니다. 일하고 있습니다 (우연히 알게 된 사실입니다).
이것은 일반적으로 어떻게 처리됩니까?
답변1
Linux에서 이식 가능한 바이너리 실행 파일에 대한 엄격하게 올바른 접근 방식은Linux 표준 베이스그리고 그것의상세사양. LSB는 특정 라이브러리 버전(또는 해당 버전과의 호환성)을 지정하여 호환 가능한 배포판 전체에서 바이너리 호환성을 생성하도록 설계되었습니다. LSB(또는 적어도 이전 버전)는 다음과 같이 공식화되었습니다.ISO/IEC 23360. LSB 라이브러리(및 자체적으로 제공되는 라이브러리)에 대해서만 링크하도록 프로그램을 구축하면 모든 시스템 간에 이식 가능합니다.
LSB는 패키지의 RPM 형식을 지정하므로 하나만 생성하면 됩니다(엄격히). 패키지 관리자와의 통합을 포기한다면 타르볼로도 충분합니다.
귀하의 특정 사항 중 일부와 관련하여:
우리는 그들이 올바른 라이브러리를 갖고 있고 최선을 다할 것이라고 가정하고 있습니까?
상당히 간단한 LSB 호환 프로그램은 많은 시스템에서 있는 그대로 실행될 가능성이 높으므로 그렇게 할 수 있습니다.
그 외에도 RHEL 및 SUSE를 포함한 여러 배포판에서는 LSB 준수를 제공하려고 시도합니다. 일부는 적절한 종속성을 가져오는 특정 패키지를 통해 이를 제공합니다. 예를 들어 데비안에는소포lsb이는 다른 여러 가지를 가져오고 lsb-core차례로 적절한 종속성을 가져옵니다. 소프트웨어를 실행하려면 대상 시스템에서 이러한 패키지를 설치해야 할 수도 있습니다.
LSB는 예전보다 덜 인기가 있고 많은 시스템에서 공식적인 호환성이 약해졌지만 실제로는 상당히 넓은 범위에 걸쳐 이식성 있게 실행하는 것이 가능합니다. 규정 준수를 열망하는 일부 시스템조차도 보다 모호한 점 중 일부를 놓치지만 일반적인 목적에서는 종종 중요하지 않습니다(그리고 동일한 프로그램이 다음과 같은 시스템에서 작동할 수 있습니다).~하지 않다LSB 규격을 준수하려고 시도합니다).
이러한 경우, 해당 라이브러리 중 하나가 변경되고 애플리케이션 작동이 중지되면 1~2년 후에 어떻게 될까요?
애플리케이션 작동이 중지되면 애플리케이션 작동도 중지됩니다. 비즈니스 프로세스에 관한 질문입니다.
우리 소프트웨어와 함께 모든 것(libstdc++, glibc 등)을 배포해야 합니까?
아마도 그렇지 않을 것입니다. 특히 libc의 경우 시스템에서 동시에 여러 버전을 사용할 때 런타임 호환성 문제가 발생할 수 있습니다. 그러나 번들로 묶는 것이 더 실용적일 수 있는 다른 libc 구현이 있습니다.
대부분의 라이브러리는 성공적으로 번들링할 수 있지만 라이브러리 공급은 일반적으로 유지 관리 및 보안 문제이므로 피할 수 있는 경우에는 번들링을 하지 않는 것이 좋습니다. 라이브러리에서 버그나 보안 결함이 발견되면 배포판에서 해결할 시스템의 한 위치에서 이를 업데이트하는 것이 모든 복사본을 추적하고 교체 패키지를 받는 것보다 더 쉽고 안정적입니다.
보다 실용적인 단계로 고객에게 어디에서 실행하고 싶은지 물어볼 수도 있습니다. 당신은 지나치게 열정적일 수도 있습니다.
답변2
실제로는 다음을 수행해야 합니다.여러 개의가장 일반적인 Linux 배포판(및 버전)용 바이너리 패키지(예: .debDebian 및 Ubuntu, Fedora용). .rpm분명히 Fedora와 Ubuntu에 대해 서로 다른 패키지를 만들어야 하며 Debian Jessie 및 Ubuntu 16.04에 대해 서로 다른 패키지를 만들어야 할 수도 있습니다. 하지만,때때로Ubuntu용 패키지는 일부 (특정) Debian에 설치될 수 있으며 그 반대의 경우도 마찬가지입니다.
그러나 우리는 그것이 어디에서 실행될 수 있어야 하는지에 대한 구체적인 정보를 제공받지 못했습니다. 즉, 배포판, 커널 버전 또는 기타 사항을 의미합니다.
고객과 논의해야 합니다.
이러한 경우, 해당 라이브러리 중 하나가 변경되고 애플리케이션 작동이 중지되면 1~2년 후에 어떻게 될까요?
바이너리 패키지의 최신 변형을 빌드하고 출시해야 하며 이를 위해 노력(및 비용)을 소비하게 됩니다.
(기술적으로나 법적으로 가능한 경우) 일부 라이브러리를 정적으로 링크할 수 있습니다(LGPL 라이센스는 동적으로 링크하거나 클라이언트 시스템에서 정적으로 다시 링크할 수 있도록 권장함을 기억하십시오). 예를 들어 는 libstdc++버전보다 버전에 훨씬 더 민감하므로 정적으로 및 동적으로 libc연결할 수 있습니다 . 실제로 YMMV.libstdc++libc
다음을 갖는 것에 주목하세요.여러 개의특정 시스템 라이브러리 버전은 실제로 작동할 수도 있고 작동하지 않을 수도 있습니다. 일부 라이브러리는 시스템 리소스를 특정 방식으로 사용하므로 세부 사항이 매우 중요합니다.
추신. 고객과 더 많은 논의를 하고 무료 소프트웨어(오픈 소스)를 만들겠다고 제안해야 할 수도 있습니다. 일부 고객은 이를 선호할 수도 있습니다.