에러 없이 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를 다시 해 보도록 하라.
/tmp/cca011551.o(.text+0x11): undefined reference to `cos'
이 문제에 대한 해법은 Makefile
내의 LIB이나 LIBS
부분(위의 예를 보라)에 -lm 을 더함으로써 수학 라이브러리
를
명시적으로 링크하는 것이다.
make -DUseInstalled -I/usr/X386/lib/X11/config
이것은 xmkmf와 동등한 저수준 명령(bare bone)의 일종이다.
# 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를 실행시켜야 할 수도 있다.
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 명령을 쓴다.
libc
를 요구하기로 악명이 높았다.
그보다 뒤에 나온 StarOffice 5.0도 새로운 glibc 2.1
라이브러리를 설치하고 나면 작동하지 않는다.
다행히도, 그 다음에 나온 StarOffice 5.1은 이 문제를 해결했다.
오래된 버젼의 StarOffice를 실행시키려면, root로서
라이브러리들을 적절한 디렉터리에 복사하고, 오래된 라이브러리를 삭제한 다음
심볼릭 링크를 다시 설정해야 한다. (이에 대한 정보가
더 필요하면 최신 버젼의 StarOffice miniHOWTO
를 보라.)
주의: 실수하면 당신의 시스템이 작동하지 않도록 할 수도 있으므로,
이 과정에서는 극도로 주의하여야 한다. 갱신된 최신 라이브러리는 대개 Sunsite에서
찾을 수 있다.
최신 라이브러리는 대개
Sunsite에서 찾을 수 있다.
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
로 정확한 디렉터리로의 심볼릭 링크를 추가해 주면 된다.
컴파일을 위해 당신 시스템에 없는 라이브러리가 필요하다면, 그 패키지는 링크
에러(undefined reference error
)를 일으킬 것이다. 그런 라이브러리는
비싼 것이거나, 다른 어떤 이유로 찾기 어려운 것일 수 있다. 그런 경우에는
정적으로 링크된 바이너리를 패키지 제작자나 리눅스 사용자 그룹에게서
구하는 것이 가장 쉬운 해결책이다.
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의 권한을 갖고 실행되며 따라서 심각한 손상을 끼칠 잠재력을 갖고 있다. 따라서 setuid 비트를 주기 전에 프로그램이 무엇을 하는지, 가능하다면 소스를 살펴봄으로써, 확인하도록 하라.
당신의 시스템에 가장 좋은 컴파일 옵션들이 설정되어 있는지 확인하기 위해서
Makefile
을 들여다보고 싶을 수도 있다.
예를 들어 -O2 옵션을 주면 최고 수준의 최적화를 선택하게 되고,
-fomit-frame-pointer 옵션은
(디버깅은 불가능하게 되지만) 바이너리를 더 작게 만들어 준다.
자신이 무엇을 하고 있는지 모른다면 이런 것들을 건드리지 않도록 하라.
그리고 어떤 경우에든 시험삼아 그냥 컴파일해서 제대로 돌아가는 것을 확인한 다음에
하도록 하라.
내 경험에 의하면, 응용 프로그램 가운데 그대로 문제없이 컴파일되는 것은 약
25% 정도였다. 50% 남짓은 간단하건 끔찍할 정도건 노력하면 컴파일할 수 있다.
즉 상당수의 패키지들은 아무리 해도 컴파일할 수가 없다는 뜻이다.
그렇다고 해도, 이 패키지들의 인텔 ELF
및 a.out
바이너리를
Sunsite나
TSX-11 archive 사이트에서 찾을 가능성도
있다.
레드 햇과
데비안도 흔히 쓰이는 리눅스
소프트웨어의 대부분이 미리 패키지화된 바이너리로 저장되어 있다.
혹은 소프트웨어의 제작자가 당신의 특별한 취향의 컴퓨터를 위해 컴파일된
바이너리를 제공해 줄 수도 있다.
미리 컴파일된 바이너리를 얻었다면, 당신의 시스템과의 호환성을 확인하기 위해
다음 사항들을 점검해야 한다.
바이너리가 당신의 하드웨어(예를 들어 인텔 x86)에서 작동해야 한다.
바이너리가 당신의 커널과 호환되는 것이어야 한다.(a.out 이나 elf)
당신의 라이브러리가 최신의 것이어야 한다.
당신의 시스템에 적절한 설치 유틸리티(rpm이나 deb)가 있어야 한다.
만약 모든 시도가 실패한다면, comp.os.linux.x나 comp.os.linux.development 같은 적절한 뉴스그룹에서 도움을 찾을 수 있다.
혹시 모든 노력이 수포로 돌아갔다고 하더라도, 최소한 당신은 최선을 다했으며 그 과정에서 많은 것을 배웠을 테니 너무 낙심할 필요는 없다.