리눅스용 소프트웨어 패키지를 컴파일하고 인스톨하기: 문제해결

다음 이전 차례

7. 문제해결

에러 없이 xmkmf와 make에 성공했다면, 다음 절로 넘어가도 좋다. 하지만 "실제 생활"에서는 첫번에 제대로 되는 일은 거의 없다. 이때가 당신의 재치를 시험할 때다.

7.1 링크 에러

xmkmf를 실행했음에도 make가 다음과 같은 메시지를 내고 실패했다고 가정하자. Ling error: -lX11: No such file or directory 이 경우 Imake 파일이 제대로 설정되지 않았을 가능성이 크다. Makefile의 첫부분에 있는 다음과 같은 줄들을 확인해 보라.
LIB= -L/usr/X11/lib INCLUDE= -I/usr/X11/include/X11 LIBS= -lX11 -lc -lm
-L과 -I 스위치는 각각 컴파일러와 링커에게 라이브러리와 include 파일들을 어디에서 찾아야 하는지 알려주는 것이다. 이 예에서는 X11 라이브러리는 /usr/X11/lib 디렉터리에, X11의 include 파일들은 /usr/X11/include/X11 디렉터리에 있어야 한다. 당신의 컴퓨터는 이와 다르다면, Makefile에 필요한 수정을 가하고, make를 다시 해 보도록 하라.

다음과 같이 수학 라이브러리 함수에 대한 정의되지 않은 참조(undefined reference)가 있을 경우:
/tmp/cca011551.o(.text+0x11): undefined reference to `cos'
이 문제에 대한 해법은 Makefile 내의 LIB이나 LIBS 부분(위의 예를 보라)에 -lm 을 더함으로써 수학 라이브러리를 명시적으로 링크하는 것이다.

xmkmf가 실패했을 때 해 볼 수 있는 또다른 것은 다음의 스크립트다.
make -DUseInstalled -I/usr/X386/lib/X11/config
이것은 xmkmf와 동등한 저수준 명령(bare bone)의 일종이다.

매우 드문 경우지만, root로서 ldconfig를 실행시키는 것이 해법이 될 수도 있다.
# ldconfig 는 공유 라이브러리의 심볼릭 링크를 갱신한다. 이것은 반드시 필요한 것은 아닐 수도 있다.

어떤 Makefile은 당신의 시스템에 있는 라이브러리에 대해 인식되지 않은(unrecognized) 별명(alias)를 사용하기도 한다. 예를 들어, 컴파일은 libX11.so.6을 요구하지만 /usr/X11R6/lib에는 그런 파일이나 링크가 없을 수 있다. 하지만 libX11.so.6.1은 있다. 해결책은 root로서 ln -s /usr/X11R6/lib/libX11.so.6.1 /usr/X11R6/lib/libX11.so.6 을 하는 것이다. 이 다음에는 ldconfig를 실행시켜야 할 수도 있다.

때로는 소스를 컴파일하기 위해 오래된 X11R5의 라이브러리가 필요할 수도 있다. /usr/X11R6/lib에 R5의 라이브러리가 있다면(처음 리눅스를 설치할 때 이것을 설치하도록 옵션을 주었다면), 소프트웨어를 컴파일하기 위해 필요한 링크가 제대로 있는지만 확인하면 된다. R5 라이브러리의 이름은 libX11.so.3.1.0, libXaw.so.3.1.0, libXt.so.3.1.0 이다. 보통 libX11.so.3 -> libX11.so.3.1.0과 같은 링크가 필요하다. 소프트웨어가 libX11.so -> libX11.so.3.1.0 형태의 링크를 필요로 할 수도 있다. 물론 "빠져있던" 링크를 만들려면, root로서 ln -s libX11.so.3.1.0 libX11.so 명령을 쓴다.

어떤 패키지는 라이브러리를 최신 버젼으로 설치하도록 요구하기도 한다. 예를 들어, StarDivision GmbH의 StarOffice 패키지 4.x 버젼들은 5.4.4 이상의 버젼을 가진 libc를 요구하기로 악명이 높았다. 그보다 뒤에 나온 StarOffice 5.0도 새로운 glibc 2.1 라이브러리를 설치하고 나면 작동하지 않는다. 다행히도, 그 다음에 나온 StarOffice 5.1은 이 문제를 해결했다. 오래된 버젼의 StarOffice를 실행시키려면, root로서 라이브러리들을 적절한 디렉터리에 복사하고, 오래된 라이브러리를 삭제한 다음 심볼릭 링크를 다시 설정해야 한다. (이에 대한 정보가 더 필요하면 최신 버젼의 StarOffice miniHOWTO를 보라.) 주의: 실수하면 당신의 시스템이 작동하지 않도록 할 수도 있으므로, 이 과정에서는 극도로 주의하여야 한다. 갱신된 최신 라이브러리는 대개 Sunsite에서 찾을 수 있다. 최신 라이브러리는 대개 Sunsite에서 찾을 수 있다.

7.2 다른 문제들

설치되어 있는 Perl 이나 그밖의 쉘 스크립트가 No such file or directory라는 에러 메시지를 낼 수 있다. 이 경우에는 파일이 실행 가능하게 되어 있는지 허가권을 확인하고, 스크립트가 호출하는 쉘이나 프로그램이 지정된 위치에 있는지 파일의 헤더 부분을 확인하도록 한다. 예를 들어 스크립트가 아래와 같이 시작한다고 하자.
#!/usr/local/bin/perl
Perl이 사실은 /usr/local/bin이 아니라 /usr/bin 디렉터리에 설치되어 있다면, 이 스크립트는 실행되지 않을 것이다. 이 문제를 해결하는 데에는 두 가지 방법이 있다. 스크립트 파일의 헤더를 #!/usr/bin/perl로 바꾸거나, ln -s /usr/bin/perl /usr/local/bin/perl 로 정확한 디렉터리로의 심볼릭 링크를 추가해 주면 된다.

어떤 X11 소프트웨어를 컴파일하려면 Motif 라이브러리가 필요하다. 표준적인 리눅스 배포본에는 Motif 라이브러리가 없으며, 현재 Motif는 100-200 달러다. (많은 경우 프리웨어인 Lesstif 도 쓸 수 있지만.) 어떤 패키지를 컴파일하기 위해 Motif가 필요한데, Motif 라이브러리를 가지고 있지 않다면 정적으로 링크된 바이너리를 구할 수 있을 것이다. 정적 링크는 라이브러리 루틴들을 바이너리 자체에 넣는 것이다. 이렇게 하면 바이너리 파일은 훨씬 커지지만, 해당 라이브러리가 없는 시스템에서도 수행시킬 수 있다.
컴파일을 위해 당신 시스템에 없는 라이브러리가 필요하다면, 그 패키지는 링크 에러(undefined reference error)를 일으킬 것이다. 그런 라이브러리는 비싼 것이거나, 다른 어떤 이유로 찾기 어려운 것일 수 있다. 그런 경우에는 정적으로 링크된 바이너리를 패키지 제작자나 리눅스 사용자 그룹에게서 구하는 것이 가장 쉬운 해결책이다.

configure 스크립트를 수행시켰더니 당신이 컴파일하려는 패키지와는 관계없어 보이는 이상한 Makefile을 만드는 경우가 있다. 이것은 당신의 path 중의 다른 어딘가에서 발견된 엉뚱한 configure를 수행했다는 뜻이다. 이런 일을 피하려면 항상 ./configure로 실행하도록 하자.

대부분의 리눅스 배포본은 옛날의 lib 5에서 libc 6 /glibc 2 라이브러리로 바뀌었다. 옛날 라이브러리와 함께 작동하도록 미리 컴파일된 바이너리라면 당신이 라이브러리를 업그레이드할 경우 문제를 일으킬 수 있다. 해법은 프로그램을 소스에서부터 다시 컴파일하든지, 미리 컴파일된 새로운 바이너리를 얻는 것이다. 혹시 당신이 시스템을 libc 6으로 업그레이드하는 중이고 이런 문제를 경험했다면 Eric Green의 Glibc 2 HOWTO를 참고하도록 하라.
glibc 버젼들 사이에는 약간의 호환되지 않는 점이 있다는 것에 주의하라. 이 때문에 glibc 2.1에서 컴파일된 바이너리는 glibc 2.0과는 작동하지 않는다거나 그 반대의 경우가 있을 수 있다.

때로는 Makefile 안의 컴파일 옵션에서 -ansi 옵션을 제거할 필요가 있을 수도 있다. 이렇게 하면 gcc가 갖고 있는 ANSI 이외의 특징들을 활성화시키며, 이런 특징들을 요구하는 패키지들을 컴파일할 수 있게 된다. (이 사실을 지적해 준 Sebastien Blondeel에게 감사한다.)

어떤 프로그램들은 root 권한으로 실행되도록 하기 위해 setuid root를 해주어야 한다. 이렇게 하는 명령은 root로서 chmod u+s 파일이름 하는 것이다. (프로그램이 그 이전에 미리 root 소유로 되어 있어야 한다는 점에 주의하라.) 이 명령은 파일 허가권 내의 setuid 비트를 설정하는 기능을 한다. 이 문제는 프로그램이 모뎀이나 cd-rom 드라이브 같은 시스템 하드웨어에 접근하거나, 어느 특히 악명높은 에뮬레이션 패키지 처럼 콘솔 모드에서 SVGA 라이브러리를 호출할 경우 일어난다. 프로그램이 root로서는 실행되지만, 일반 사용자에게는 access denied 에러 메시지를 내보낸다면 이 허가권 문제를 의심해보기 바란다.

주의: root로의 setuid를 가진 프로그램은 시스템에 보안 상의 위험 요인이 될 수 있다. 이런 프로그램은 root의 권한을 갖고 실행되며 따라서 심각한 손상을 끼칠 잠재력을 갖고 있다. 따라서 setuid 비트를 주기 전에 프로그램이 무엇을 하는지, 가능하다면 소스를 살펴봄으로써, 확인하도록 하라.

7.3 변경(tweaking)과 미세한 조정(fine tuning)

당신의 시스템에 가장 좋은 컴파일 옵션들이 설정되어 있는지 확인하기 위해서 Makefile을 들여다보고 싶을 수도 있다. 예를 들어 -O2 옵션을 주면 최고 수준의 최적화를 선택하게 되고, -fomit-frame-pointer 옵션은 (디버깅은 불가능하게 되지만) 바이너리를 더 작게 만들어 준다. 자신이 무엇을 하고 있는지 모른다면 이런 것들을 건드리지 않도록 하라. 그리고 어떤 경우에든 시험삼아 그냥 컴파일해서 제대로 돌아가는 것을 확인한 다음에 하도록 하라.

7.4 더 도움이 필요할 때 가 볼 곳

내 경험에 의하면, 응용 프로그램 가운데 그대로 문제없이 컴파일되는 것은 약 25% 정도였다. 50% 남짓은 간단하건 끔찍할 정도건 노력하면 컴파일할 수 있다. 즉 상당수의 패키지들은 아무리 해도 컴파일할 수가 없다는 뜻이다. 그렇다고 해도, 이 패키지들의 인텔 ELF 및 a.out 바이너리를 Sunsite나 TSX-11 archive 사이트에서 찾을 가능성도 있다. 레드 햇과 데비안도 흔히 쓰이는 리눅스 소프트웨어의 대부분이 미리 패키지화된 바이너리로 저장되어 있다. 혹은 소프트웨어의 제작자가 당신의 특별한 취향의 컴퓨터를 위해 컴파일된 바이너리를 제공해 줄 수도 있다.

미리 컴파일된 바이너리를 얻었다면, 당신의 시스템과의 호환성을 확인하기 위해 다음 사항들을 점검해야 한다.

바이너리가 당신의 하드웨어(예를 들어 인텔 x86)에서 작동해야 한다.
바이너리가 당신의 커널과 호환되는 것이어야 한다.(a.out 이나 elf)
당신의 라이브러리가 최신의 것이어야 한다.
당신의 시스템에 적절한 설치 유틸리티(rpm이나 deb)가 있어야 한다.

만약 모든 시도가 실패한다면, comp.os.linux.x나 comp.os.linux.development 같은 적절한 뉴스그룹에서 도움을 찾을 수 있다.

혹시 모든 노력이 수포로 돌아갔다고 하더라도, 최소한 당신은 최선을 다했으며 그 과정에서 많은 것을 배웠을 테니 너무 낙심할 필요는 없다.

다음 이전 차례