리눅스 컴파일 바이너리 호환 문제
글쓴이: spacelee / 작성시간: 수, 2006/01/25 - 11:14오전
가령, 리눅스의 여러 커널 버젼, 여러 glibc 버젼에서
돌아가는 소프트웨어가 있다고 가정할때
가장 하위의 커널, glibc 버젼에서 컴파일한 binary 파일을
다른 상위 커널, glibc 커널 버젼에서 돌아가게 해도
문제가 없는지 궁금합니다.
( 또 커널, glibc 버젼말고 고려해야 되는 다른 버젼도 있는지
궁금합니다. )
저의 경험으로는 대체적으로 문제는 없었는데,
어떤 경우에는 특정 문제가 발생했을때 정확한 버젼에서
컴파일해서 해결한 적도 있었습니다.
이런 경험들이 일관성이 없고
정확한 원인을 몰라서
고수님들의 조언 부탁드립니다.
Forums:
바이너리로 배포할때는가급적 공유라이브러리를 쓰지않고,정적라이브
바이너리로 배포할때는
가급적
공유라이브러리를 쓰지않고,
정적라이브러리를 사용하여
배포해야 문제가 안생기죠.
[quote="wslee"]바이너리로 배포할때는가급적 공유라이브러
답변 감사합니다.~~^^
가령 제가 만든 바이너리의 ldd 정보가 아래와 같다고 할때
아래의 so들 모두를 정적으로 하는게 좋다는 얘기신가여?
제 시스템에는 아래 라이브러리들에대한 정적 라이브러리가 없던데
원래 없는건지, 설치할때 선택해야 되는지..^^;;
잘 몰라서 도움 부탁드립니다.^^;;
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
# gcc -static ...
# gcc -static ...
무조건 static으로 해결할 수 있는 것도 아닙니다. 때에 따라서 dy
무조건 static으로 해결할 수 있는 것도 아닙니다. 때에 따라서 dynamic linking을 써야만 하는 경우가 의외로 많습니다. 이런 경우 Linux용 상용 application들이 어떤 식으로 제공하고 있는지 살펴보시면 도움이 될 것입니다.
예를 들어 대부분의 Linux의 게임들은 SDL library에 기초하고 있으며, 게임을 배포할때, 미리 컴파일된 공유 SDL library를 자체 포함하고 있습니다. 그 다음 script를 통해 LD_LIBRARY_PATH등을 설정하고, 실제 게임 binary executable을 실행합니다.
물론 배포하고자 하는 library들의 copyright을 미리 보고 참고해야 하며, 공개용이라 하더라도 EULA.txt 또는 COPYRIGHT 파일에 적절하게 명시해야 합니다.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Korean Ver: http://cinsk.github.io/cfaqs/
여러가지 도움 말씀 감사드립니다.^^읽어보다 보니 여러가지 궁금한 것
여러가지 도움 말씀 감사드립니다.^^
읽어보다 보니 여러가지 궁금한 것들이 마구 생겨서
또 질문 드립니다.^^;;
1.
-static 옵션 관련하여
알려주신 옵션으로 컴파일하고 테스트 해보니
정상적으로 동작하는 것 같습니다.^^;; (감솨~)
그런데 궁금한 것이
libdl.so.2 => /lib/libdl.so.2
이런 라이브러리 같은 경우 lib 디렉토리에 상응하는 .a 파일이 없는데
어떻게 static 으로 포함되는지 궁금합니다.
2.
그리고 libdl이나 libpthread같은 경우 중요한 라이브러리일텐데
이것들이 static으로 포함되서 커널이나, glibc 버젼이 좀 다른
리눅스 시스템에서 동작하는데에는 문제가 없는지 궁금합니다.
3.
cinsk 님이 말씀하신 '때에 따라서 dynamic linking'을 써야하는
경우라면 어떤 경우를 말씀하신는 것인지 간단한 예를
알려주시면 안될까여?^^;;
4.
cinsk 님 말씀대로 저희 시스템에 설치된
몇가지 상용 패키지를 ldd로 보니
이런 정도의 shared library는 쓰고 있습니다.
알려주신 SDL 라이브러리는 찾아보니
기본적인 시스템 라이브러리보다 약간 윗레벨의 기능을 제공하는 것이
아닌가 싶습니다.
그럼 시스템 라이브러리 (예를들어 pthread,libdl,libm)등도
혹시 SDL처럼 별도로 제공이 되는 라이브러리들이 있는지요?
(그래서 리눅스 커널이나 glibc 버젼과는 무관하게 배포할 수 있는
그런 라이브러리..)
아니면 위에처럼 그냥 -static옵션으로 처리하면 시스템라이브러리가
static으로 포함되서 다른데서 쓰는데 문제가 없는지요?
너무 많은 질문 드린것 같네요.^^;;
( ps. cinsk님 항상 좋은 답변 주셔서 감사합니다.^^)
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
게시판 열심히 검색해본 결과 몇가지 자문자답합니다. (더 알려주셔도
게시판 열심히 검색해본 결과 몇가지 자문자답합니다.
(더 알려주셔도 감솨~^^)
열심히 게시판을 검색해보니 관련된 답변을 주신 분이 계시네요.
http://bbs.kldp.org/viewtopic.php?t=1584&highlight=-static
역시 열심히 검색해보니 cinsk님이 이미 답변하신 내용이 있네요. ^^;;
그 글타래에서는 newlib,uclibc,busybox에 대해서 알려주셨었네요.
아 라이브러리들을 간단히 찾아보니 주로 embedded 시스템에서 쓰이는 라이브러리인것 같은데, glibc를 완벽하게 대체 가능한가요?
간략하게, 쓰시면서 느끼신 장단점을 알려주시면 안될까요?^^;;
(ps. 하면 할수록 검색도 쉬운게 아니라는 생각이 드네요.^^;;)
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
내가 알기로는 gcc에서 -static 옵션은 있으나 마나한 옵션으로
내가 알기로는
gcc에서 -static 옵션은 있으나 마나한 옵션으로 알고 있는데요.
그거 줘도 정적라이브러리 없으면 링크 안됩니다.
정적라이브러리로 링크하기 위해선
정적라이브러리가 꼭 있어야 하고 아울러 공유라이브러리와
다른 이름으로 존재 해야 합니다.
같은 이름의 정적 공유 있으면 공유를 써버림.
정적 라이브러리가 아예 없는 경우는 소스파일 구해다
정적 라이브러리 만들어 줘야 하지 않을까 사료됨
그까이꺼 라이브러리 만들때 옵션 하나만 달리주면
정적이 되는거고 공유가 되는거 그까이꺼 만드는건 그까이꺼 아닐찌..
자세한건 나두 안해봐서 모름 휘릭~
리눅스 유닉스는
윈도그 도스 같은 자료실이 생길수 없는 애로사항이
나름대로 있는거 갸틈
[quote="wslee"]내가 알기로는 gcc에서 -static 옵
아 저두 .a가 없는데 -static으로 되는 상황이 이상해서
만들어진 바이너리 파일을 ldd로 확인해봤는데
연결될 동적 라이브러리가 없다고 나오더라구요.
그래서 여쭤본거구요.
저두 이쪽을 정확히 몰라서 혼돈스럽네여.^^;;
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
저두 인터넷서 대충 읽은게 다라 -_-;;집에와서 테스트 해보니 -s
저두 인터넷서 대충 읽은게 다라 -_-;;
집에와서 테스트 해보니 -static 옵션만 줘도 정적으로 잘 되네요 ^^;;
무지막대하게 용량이 큰 바이너리 하나 나오는군요.
일단 정적라이브러리는 /usr/lib 여기에 다 들어가 있습니다.
요기 들어가 찾아보시 .a로 끝나는 정적라이브러리 다 있습니다.
글고
ld-linux.so 이 라이브러리는 공유라이브러리와 링크됐을시
공유라이브러리를 불러오는 공유라이브러리 입니다.
고로 정적링크 되면 그 역할이 필요 없는 라이브러리고요.
libdl.so 요건 프로그램에서 공유라이브러리를 함수처럼
필요할때 불러다 쓸때 필요한 라이브러리입니다..
모든걸 다 정적링크 시키면 필요 없을겁니다..
물런 프로그램 짤때 이런 기능 쓰지도 말아야 겠지요.
[quote="wslee"]저두 인터넷서 대충 읽은게 다라 -_-;;
아 감솨^^
.a들이 어디 있는지 궁금했는데 /usr/lib 에 있었군요.
왜 /lib에 같이 안넣어놓고 거기다 넣어놨나 싶네여.....^^;;
이제 하나 남은 마지막 궁금한 점은
스태틱 컴파일 된 바이너리가
커널이나 glibc 버젼이 다른 시스템에서
안정적으로 도느냐 하는 문제이네요. ?
게시판 검색을 해보니 어떤 분은 libpthread같은 것을
스태틱하게 링크 시키면 위험할 것 같다는 얘기를 하셨는데
다른 분들 경험은 어떠신지 궁금하네요.
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
시스템 콜들을 사용한 경우, 그리고 그 중에서도 Linux 커널에 의
시스템 콜들을 사용한 경우,
그리고 그 중에서도 Linux 커널에 의존적인 시스템 콜을 사용한 경우라면
static 링크를 하더라도 문제가 발생할 확률이 높습니다.
libpthread 의 경우, 커널 2.6을 기본으로 채용하는 배포본들은 NPTL 을 사용하는 경우가 대부분이며
NPTL 을 사용하기 위해서는 커널의 지원도 있어야 하기 때문에
기존의 libpthread (linuxthread 라 부릅니다) 라이브러리와 문제를 일으킬 수 있다고 생각됩니다.
위에서 말씀드린 'Linux 커널에 의존적인 시스템 콜' 의 경우는
해당 시스템 콜의 man 페이지를 확인해 보시면 Linux 에 의존적인지 아닌지를
파악할 수 있습니다.
보통 man 페이지에 PORTING 이나 NOTE 로 언급이 되어 있습니다.
[quote="kslee80"]시스템 콜들을 사용한 경우, 그리고 그
도움말씀 감사합니다.^^
그럼 만약 배포 방식을
"하위버젼 컴파일 -> 상위 버젼 적용"으로 제한한다면
말씀하신 내용이 문제가 될 소지가 있을까요?
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
[quote]그럼 만약 배포 방식을"하위버젼 컴파일 -> 상위
시스템 콜의 경우는 언제건 문제가 발생할 소지가 있습니다.
시스템 콜을 하는 경우, 실제로 라이브러리에서는 해당 콜에 대해서 하는 역할이 없습니다..
예를 들자면, Linux 에서 시스템 콜을 사용하는 경우,
실제로 해당 시스템 콜을 위해서 C 라이브러리가 링크되지만
C 라이브러리에 포함되어 있는 해당 함수 루틴은 단순히 레지스터 셋팅하고 인터럽트를 발생시키는 코드일 뿐입니다.
시스템 콜의 실제적인 동작은 커널이 담당하기 때문이죠.
결론적으로, 정적 컴파일을 하더라도 시스템 콜은 커널에 따라서 다른 동작을 보이게 되고,
이것 때문에 하위 커널버젼에 맞춰져서 작성된 프로그램을 정적 컴파일 하더라도
상위 커널버젼으로 동작하는 시스템에서 동작하지 않는 경우를 자주 접했습니다.
(libpthread 의 경우도 대부분의 함수가 시스템 콜을 사용합니다)
그렇지만, 위에 말씀드린 커널 버젼에 따라 상이한 동작을 보이는 시스템 콜은 흔하지 않습니다.
Linux 의 시스템 콜들 중, Linux 에 의존적인 시스템 콜들은 많지 않으며,
대부분은 POSIX 시스템 콜들로 대체 가능합니다.
(Linux 에 의존적인 시스템 콜의 구분 법은 저번 답글에 적은대로 man 페이지를 확인해 보시면 됩니다)
그리고, POSIX 에 정의되어 있는 콜들의 경우는
커널 버젼에 큰 영향을 받지 않고 POSIX 에 정의된 동작을 보입니다.
(이래서 표준을 준수하는 경우에 속편한 경우가 많죠;;)
그 외에 man 페이지 상에서 3번 섹션에 포함되는 C Library function 들의 경우야
정적 컴파일시 모든 코드가 바이너리상에 포함되므로 커널과는 전혀 상관없이 동작합니다.
결론적으로,
시스템 콜들 중, Linux 에 의존적인 콜들을 점검해서 Linux 에 의존적인 시스템 콜을 줄이는 것이 필요하며,
Linux 에 의존적인 시스템 콜을 거의 사용하지 않았다...라고 한다면
정말 특이한 상황 아니라면 문제가 될 확률은 거의 없습니다.
[quote="kslee80"][quote]그럼 만약 배포 방식을"하
흐..다행이네요.
제가 작업하고 있는 app는 초기부터 posix 기반으로
틀을 잡아와서 위의 룰만 지키면 크게 문제될 것 같지는 않네요.
도움말씀 정말 감사드립니다.^^
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
지금 [b]리눅스[/b] 상에서 [b]바이너리[/b]의 호환성 얘기를 하
지금 리눅스 상에서 바이너리의 호환성 얘기를 하는데 시스템 콜 얘기는 거의 불필요하지 않나 합니다. 당연히 리눅스 외의 다른 운영체제에서는 바이너리 호환성이 없어서 다시 컴파일 해야 하므로 의미가 없습니다.
리눅스 커널에 따라 시스템 콜이 바뀌는 것도 그리 많지 않고 어차피 glibc나 기타 라이브러리의 wrapper를 통해 부르기 때문에 라이브러리 차원에서 적절히 처리해주리라고 생각합니다. 2.6에 추가된 최신 기술을 (e.g. epoll) 사용한 것을 2.4에서 사용한다던가 하지 않는 한 큰 문제가 없으리라 생각합니다.
역시 가장 문제가 되는 것은 linuxthreads에서 nptl로 넘어간 쓰레드 처리에 관한 내용이 되겠네요. 2.4에서 linuxthreas의 libpthread까지 static하게 컴파일한 바이너리를 2.6에서 돌리면 어떻게 되는지 저도 해본 바가 없어서 잘 모르겠습니다. 다른 분이 첨언해 주시겠죠 :)
이런 면에서
제가 잘 모르는 쓰레드 문제를 제외하면 이 방식은 프로그램의 실행에는 거의 문제가 없을거라 생각합니다.
다만, 라이센스 문제가 걸릴 수 있습니다. GPL 라이센스의 라이브러리는 정적링크하여 배포할 수가 없기 때문에 문제의 소지가 생길 수 있습니다. 이 부분을 잘 고려해 보시기 바랍니다. 정적 링크를 했을 경우엔 수정을 했는지 알 수 없기 때문이죠.
제가 보기에는 동적 링크로 프로그램을 작성하되 호환성이 없어보이는 라이브러리를 같이 배포하여 특정 디렉토리에 놓고 LD_LIBRARY_PATH 환경변수를 이용해 먼저 로드하도록 하는 것이 가장 좋아보입니다.
생각 못했던 라이센스 문제도 있네요. ㅜㅜ그런데 쓰레드쪽에 대해서
생각 못했던 라이센스 문제도 있네요. ㅜㅜ
그런데 쓰레드쪽에 대해서 궁금한 것이 있습니다.
많이 찾아보기는 했는데 명확한 답변을 못찾아서요.
제가 쓰는 리눅스는
Linux dev 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:59:02 EST
2004 i686 i686 i386 GNU/Linux
이런 버젼인데,
/lib쪽을 뒤져보면 libthread.so가 세군데 존재합니다.
/lib,/lib/tls,/lib/i386이 각각 존재하는데
찾아보면 /lib가 linuxthread, /lib/tls가 nptl쪽인거 같더군요.
그런데 nptl이 제 시스템처럼 2.4에도 존재하는데
nptl의 히스토리가 어떻게 흘러갔는지 궁금합니다.
2003년 10월 인가로 glibc에 포함됐다고 c10k 사이트에서 본것도 같구요.
정리하면
linuxthread와 nptl이 glibc 수준의 개념인지 커널에서의 개념인지?
nptl이 2.4에도 공식적으로 포함된 것인지?
2.4와 2.6에 포함된 기능이나 안정성다른지?
2.4에서 nptl을 사용해도 괜찮다면 링크해주기 위한 옵션은 무엇인지?
리눅스 pthread 히스토리에 대한 내용이 전반적으로 찾아봐도 명확하게
정리된 내용을 찾지 못해서 혼란스럽습니다..
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
glibc가 LGPL이죠...따라서 동적링크는 허용되는데 정적으로
glibc가 LGPL이죠...
따라서 동적링크는 허용되는데 정적으로 했다면 해당 프로그램도 소스까지 LGPL로 공개해야 합니다.
GPL이면 상용프로그램과는 아예 링크 뭇하죠.
Written By the Black Knight of Destruction
생각해보니 저희 리눅스 시스템은 redhat linux ES를 쓰네요.
생각해보니 저희 리눅스 시스템은 redhat linux ES를 쓰네요.
redhat에서 나온 상용 리눅스 입니다. ^^;;
처음에는 오픈 리눅스에 저희 소프트웨어를 설치했었는데,
오픈 리눅스가 하이 퍼포먼스에서는 문제가 많거나,
또 버그 업데이트가 늦은 편이라 하도 고생을 많이 해서
상용 리눅스로 바꾸고 고객들에게도 그렇게 권장하고 있습니다.
따라서 저희 고객들은 redhat es나 as를 많이 씁니다.
제가 리눅스를 많이는 모르지만 저희 회사의 경험상 그렇습니다.
이 문제에 대해서도 재밌는 토론거리가 되지 않을까 싶네요.
이미 다뤄졌던 문제 일 수도 있겠구요. ^^:;
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
댓글 달기