· KLDP.org · KLDP.net · KLDP Wiki · KLDP BBS ·
LFS/Preparation
이 문서는 안양대학교 컴퓨터 공학과 SI 연구실의 문서 프로젝트를 통해 생성한 페이지를 옮겨온 것입니다. 번역을 해주신 김유석, 김관빈, 전신원, 민경대, 김기훈, 임정호, 백석곤, 이호주, 안혜림 님께 감사의 말씀을 전합니다. 이 문서는 LFS 5.1-Pre 1 을 기준으로 제작된 문서입니다. (2004년12월29일 기준) 최신의 정보에 맞게 조금씩 업데이트 할 예정이며, LFS에 대한 전체 내용은 [http]http://wiki.kldp.org/wiki.php/LFS/를 통해 연결됩니다. 본 문서는 LFS 시스템의 준비단계에 해당하는 패키지와 패치를 구하는 부분을 설명합니다.

목차

1 새파티션 만들기
1.1 소 개
1.2 새 파티션 만들기
1.3 새 파티션에 파일 시스템 만들기
1.4 새 파티션을 마운트하기
2 필요한 패키지와 패치들
2.1 소 개
2.2 모든 패키지들
2.3 필요한 패치들
3 임시 시스템 구축하기
3.1 소 개
3.2 Toolchain technical notes
3.3 정적연결에 대한 주의
3.4 $LFS/tools 디렉토리 만들기
3.5 "LFS" 계정 만들기
3.6 기본 환경 변수 설정하기
3.7 Binutils-2.14 - Pass 1 설치
3.7.1 Binutils의 인스톨
3.8 GCC-3.3.2 - Pass 1 설치
3.8.1 GCC 설치
3.9 Linux-2.4.24 헤더들 설치
3.10 kernel 헤더 설치
3.11 Glibc-2.3.3 설치
3.11.1 Glibc 설치
3.12 "Locking in" Glibc
3.13 Expect-5.40.0 설치
3.13.1 Expect 설치
3.13.2 Expect 내용
3.13.3 요약
3.14 DejaGnu-1.4.4 설치
3.14.1 DejaGnu 설치
3.14.2 DejaGnu 내용
3.14.3 요약
3.15 GCC-3.3.2 - Pass 2 설치
3.15.1 GCC의 재 인스톨
3.16 Binutils-2.14 - Pass 2 설치
3.16.1 Binutils 재설치하기
3.17 Gawk-3.1.3 설치
3.17.1 Gawk 설치
3.18 Coreutils-5.0 설치
3.18.1 Coreutils 설치
3.19 Bzip2-1.0.2 설치
3.19.1 Bzip2 설치
3.20 Gzip-1.3.5 설치
3.20.1 Gzip 설치
3.21 Diffutils-2.8.1 설치
3.21.1 Diffutils 설치
3.22 Findutils-4.1.20 설치
3.22.1 Findutils 설치
3.23 Make-3.80 설치
3.23.1 Make 설치
3.24 Grep-2.5.1 설치
3.24.1 Grep 설치
3.25 Sed-4.0.9 설치
3.25.1 Sed 설치
3.26 Gettext-0.14.1 설치
3.26.1 Gettext 설치
3.27 Ncurses-5.4 설치
3.27.1 Ncurses-5.4 설치
3.28 Patch-2.5.4 설치
3.28.1 Patch 설치
3.29 Tar-1.13.25 설치
3.29.1 Tar 설치
3.30 Texinfo-4.6 설치
3.30.1 Texinfo 설치
3.31 Bash-2.05b 설치
3.31.1 Bash 설치
3.32 Util-linux-2.12 설치
3.32.1 Util-linux 설치
3.33 Perl-5.8.3 설치
3.33.1 Perl 설치
3.34 Stripping

[edit]

1 새파티션 만들기

[edit]

1.1 소 개


이번 장에서는 LFS시스템을 설치하기 위한 파티션 작업에 대해 다룰 것입니다. 우리는 이제 새로운 파티션을 만들고 그 파티션에 파일 시스템을 구축하고 마운트를 할 것입니다.

[edit]

1.2 새 파티션 만들기


새로운 Linux 시스템을 구축하기 위해서는 어느 정도 빈 공간이 있어야 합니다.(디스크의 빈 파티션). 만약 LFS를 만들기 위한 HDD의 여유공간이 없고, 남는 파티션도 없다면, 기존 배포판이 설치된 곳에 설치해야 합니다. 처음부터 LFS를 설치하는것은 추천하지 않습니다. 하지만, HDD공간이 정말 없고, 당신이 용감하다면 다음의 문서를 참고하기 바랍니다. http://www.linuxfromscratch.org/hints/downloads/files/lfs_next_to_existing_systems.txt

최소 설치 사양을 위해서는 1.2GB정도의 파티션이 필요합니다. 모든 소스 타르볼을 저장하고 모든 패키지를 컴파일 하는데 이 정도의 공간이면 충분합니다.하지만, LFS시스템을 첫번째 리눅스 시스템으로 사용 할 것이라면,당신은 아마도 응용소프트웨어를 더 설치해야 할 것이고, 그러기 위해서는 약 2~3GB정도가 더 필요할 것입니다.

시스템에 램이 충분하지 않을 경우, 가상 메모리를 사용하는 것은 좋은 방법입니다. -- 가상 메모리는 램이 부족할때만 가끔씩 사용됩니다 .LFS시스템은 기존 리눅스 시스템과 가상공간을 공유할 수 있습니다. 그러므로 만약, 기존의 리눅스 시스템이 가상메모리를 사용하고 있다면 새롭게 만들 필요가 없습니다.

cfdisk2나 fdisk를 실행할때 arguement로 HDD이름을 넣어주면 새로운 파티션을 만들수 있습니다. -- 예를 들어 /dev/hda는 첫번째 IDE 디스크입니다. 필요하다면 리눅스 native파티션과 swap파티션을 만드세요. 만약 프로그램의 사용법을 모른다면 cfdisk나 fdisk의 man페이지를 참조하기 바랍니다.

새로운 파티션을 어떻게 나눴는지 기억하세요. -- hda5같은. (이름) 만약 스왑공간을 만들었다면 그 이름 역시 기억하세요. 이런 이름들은 나중에 /etc/fstab파 일에서 사용될 겁니다

[edit]

1.3 새 파티션에 파일 시스템 만들기


빈 파티션이 있다면, 그 위에 파일 시스템을 만들 수 있습니다. 리눅스상에서는 ext2가 주로 사용되지만, 요즘의 대용량 HDD에서는 journaling file system (ext3)가 점점 보편화 되는 추세입니다.우리는 ext2를 만들것입니다, 하지만 다른 파일 시스템을 사용하고 싶다면 http://www.linuxfromscratch.org/blfs/view/stable/postlfs/filesystems.html <--에서 찾아 보세요.

LFS 파티션에 ext2 파일 시스템을 만들려면 아래처럼 하세요. 
mke2fs /dev/xxx

xxx를 LFS 파티션 이름으로 바꾸세요.(예를들면 hda5)

새로운 스왑 파티션을 만들었다면 초기화해야 합니다. (사용법은 mke2fs를 참조..) 
mkswap /dev/yyy

yyy를 swap 파티션 이름으로 바꾸세요.

[edit]

1.4 새 파티션을 마운트하기


이제 우린 파일 시스템을 만들었고, 그 파티션을 사용하기 위해서 마운할 장소를 고르고, 마운트를 해야합니다.이 문서에서는 파일 시스템이 /mnt/lfs 에 마운트 되어 있다고 가정할 것이지만, 어떤 디렉토리를 선택하더라도 상관 없습니다.

마운트 할 곳을 선택하고 아래와 같이 실행하여 환경변수에 적용시키세요. 
export LFS=/mnt/lfs

마운트 할 디렉토리를 만들고 아래와 같이 실행하여 LFS 파일 시스템을 마운트 하세요: 
mkdir -p $LFS
mount /dev/xxx $LFS

xxx를 lfs파티션이름으로 바꾸세요.

lfs 시스템을 멀티 파티션으로 구성할 생각이라면(예를 들어 "/" 와 "/usr)"를 각기 다른 파티션으로 배정할 경우) 마운트는 다음과 같이 하세요. 
mkdir -p $LFS
mount /dev/xxx $LFS
mkdir $LFS/usr
mount /dev/yyy $LFS/usr

물론, xxx와 yyy는 적절한 이름으로 바꿔줍니다.

새로운 파티션을 마운트 할 때는 suid,dev,atime 같은 옵션을 사용하지 않고 마운트 합시다. LFS 파티션이 어떤 옵션을 가지고 마운트 되었는지 보기 위해서 파라미터없이 마운트 명령을 실행 시킬수 있습니다. 만약 suid, dev, atime 이 잘못되었다면 다시 마운트 해야합니다.

이제 우리는 작업할 공간을 만들었고, 패키지를 다운로드 받을 준비가 되었습니다.

[edit]

2 필요한 패키지와 패치들

[edit]

2.1 소 개


다음은 기본 리눅스 시스템을 설치하기 위해 다운로드를 받아야하는 패키지의 목록입니다.목차의 버전 번호는 이미 발표된 소프트웨어의 버전과 상응하고, 이 책은 그것들에 바탕을 두고 있습니다. LFS 설치를 많이 해 본 사람이 아니라면, 새로운 버전으로 시도하지 않기를 강력히 충고합니다. 또한 신버전은 아직 알려지지 않은 버그들이 있을 수 있으므로 사용하지 않는 것이 좋습니다.

모든 URL들이 사용 가능하면, 다음의 프로젝트 페이지를 추천합니다.http://www.freshmeat.net/. Freshment page는 프로젝트 웹 사이트, 메일링 리스트 , FAQ , changelogs 등 뿐만아니라 공식다운로드 사이트에 찾아가기 쉽도록 도와줍니다.

이런 다운로드 사이트들이 항상 이용가능하다고 보장할 수는 없습니다. 이 책이 발간된 후에 다운로드 사이트가 변경된 경우 google 을 이용해 찾아보기 바랍니다. 찾지 못한게 있을 경우, errata page(http://www.linuxfromscratch.org//lfs/print/) 에서 도움을 받거나 그래도 해결이 안되면 다음 웹사]이트의 다운로드 리스트들 중에서 하나를 참고하세요.http://www.linuxfromscratch.org//lfs/packages.html

당신은 패키지와 패치들은 설치 과정에서 편하게 이용할 수 있는 장소에 저장하는 걸 원할 것입니다. 또한 소스의 압축을 풀고 그것들을 컴파일하고 설치하는 작업디렉토리가 필요할 것입니다.$LFS/sources는 타르볼들과 패치들을 저장하고 작업할 장소로 써 사용될것입니다. 이런식으로 필요한 모든것들은 LFS파티션에 위치할 것이고, 모든 설치과정 동안 사용할 것입니다.

패키지와 패치들을 다운로드 하기 전에 root권한으로 다음 명령들을 실행하기 바랍니다. 
mkdir $LFS/sources

일반사용자 계정으로 다운로드 받으려면 일반사용자도 쓰기 가능하도록 권한을 주어야 합니다: 
chmod a+wt $LFS/sources
[edit]

2.2 모든 패키지들


다음 사이트들을 참조하여 다운로드 받으세요: (링크가 깨진 사이트도 있습니다)



Automake (1.8.2) - 623 KB: http://freshmeat.net/projects/automake/


Binutils (2.14) - 10,666 KB: http://freshmeat.net/projects/binutils/



Coreutils (5.0) - 3,860 KB: http://freshmeat.net/projects/coreutils/

DejaGnu (1.4.4) - 1,055 KB: http://freshmeat.net/projects/dejagnu/

Diffutils (2.8.1) - 762 KB: http://freshmeat.net/projects/diffutils/

E2fsprogs (1.34) - 3,003 KB: http://freshmeat.net/projects/e2fsprogs/


Expect (5.40.0) - 509 KB: http://freshmeat.net/projects/expect/

File (4.07) - 347 KB: -- (see Note 1 below) http://freshmeat.net/projects/file/

Findutils (4.1.20) - 760 KB: http://freshmeat.net/projects/findutils/

Flex (2.5.4a) - 372 KB: ftp://ftp.gnu.org/gnu/non-gnu/flex/


GCC (2.95.3) - 9,618 KB: http://freshmeat.net/projects/gcc/

GCC-core (3.3.2) - 10,994 KB: http://freshmeat.net/projects/gcc/

GCC-g++ (3.3.2) - 2,019 KB: http://freshmeat.net/projects/gcc/

GCC-testsuite (3.3.2) - 1,042 KB: http://freshmeat.net/projects/gcc/

Gettext (0.14.1) - 6,397 KB: http://freshmeat.net/projects/gettext/

Glibc (2.3.3) - 13,101 KB: -- (see Note 2 below) http://freshmeat.net/projects/glibc/


Groff (1.19) - 2,360 KB: http://freshmeat.net/projects/groff/


Gzip (1.3.5) - 324 KB: ftp://alpha.gnu.org/gnu/gzip/

Inetutils (1.4.2) - 1,019 KB: http://freshmeat.net/projects/inetutils/





Libtool (1.5.2) - 2,591 KB: http://freshmeat.net/projects/libtool/

Linux (2.4.24) - 29,138 KB: http://freshmeat.net/projects/linux/





Man-pages (1.65) - 1,752 KB: http://freshmeat.net/projects/man-pages/

Modutils (2.4.26) - 229 KB: http://freshmeat.net/projects/modutils/

Ncurses (5.4) - 2,019 KB: http://freshmeat.net/projects/ncurses/



Perl (5.8.3) - 11,721 KB: http://freshmeat.net/projects/perl/


Procps (3.1.15) - 260 KB: http://freshmeat.net/projects/procps/



Shadow (4.0.4.1) - 795 KB: http://freshmeat.net/projects/shadow/



Tar (1.13.25) - 1,281 KB: ftp://alpha.gnu.org/gnu/tar/


Texinfo (4.6) - 1,317 KB: http://freshmeat.net/projects/texinfo/

Util-linux (2.12) - 1,814 KB: http://freshmeat.net/projects/util-linux/



Total size of these packages: 134 MB

주석:1) 현재 File(4.07)팩키지는 사용할 수 없는 상태입니다. 이 다운로드 사이트의 주관리자는 새 버전이 나오면 구 버전은 삭제하는 것으로 알려져 있습니다. File섹션을 참고하여 다른 다운로드 사이트를 이용하세요.

주석:2) 현재, Glibc 메인테이너들은 새로운 릴리즈 타르볼을 다운로드 용으로 만들지 않기로 결정했습니다. 따라서, 맨처음의 원시 소스(역자주:첫버전)부터 현재 glibc 릴리즈를 얻을 수 있는 유일한 방법은 Glibc CVS 저장소로부터 가져오는 것 뿐입니다. 아래의 명령어들을 실행하면 새 버전을 다운로드하고 타르볼을 만들것입니다. ( - sunyzero 번역) 
cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc \
    export -d glibc-2.3.3-20031202 -D "2003-12-02 UTC" libc
tar jcvf glibc-2.3.3-20031202.tar.bz2 glibc-2.3.3-20031202

타르볼은 LFS mirror 사이트에서 다운로드 받아서 사용할 수 있습니다. Glibc 섹션에서 다운로드 링크를 참조하세요.

[edit]

2.3 필요한 패치들


팩키지들 뿐만 아니라 각종 패치들도 필요합니다. 팩키지를 우리가 원하는 대로 수정하거나 메인테이너가 버그를 해결하기 위해 만든 패치가 필요합니다. 다음 패치들을 다운로드 받으세요.




















현재 위 패치 리스트의 링크는 모두 깨진 상태입니다. http://www.linuxfromscratch.org/patches/lfs/5.1 을 이용해 주세요.

LFS 동호회에 가 보면 위에 나열된 패치외에 다른 많은 패치들이 존재합니다. 이런 패치들은 사소한 버그들을 해결해주거나, 부가적인 기능들을 추가해줍니다. http://www.linuxfromscratch.org/patches/ 에 위치한 패치 데이터베이스를 자유롭게 시험해보고, 사용하기를 원하는 패치들을 선택하세요.

[edit]

3 임시 시스템 구축하기

[edit]

3.1 소 개


이 장에서 우리는 리눅스 시스템 최소사양을 컴파일하고 설치 할 것입니다. 이 시스템은 다음 장에서 최종 LFS 시스템 설치를 시작할 수 있도록 하기 위한 충분한 도구들을 포함 할 것입니다

이런 최소사양의 설치는 두 단계를 걸칩니다. 최신 팩키지들과 독립적으로 작동되는 Toolchain(compiler,assembler, linker and libraries)을 설치하고, 그 다음 다른 필수적인 모든 도구들을 설치하기 위해 이것들을 사용합니다.

이 장에서 컴파일된 파일들은 $LFS/tools 디렉토리 밑에 설치 될 것입니다. 여기에서 컴파일된 패키지들은 이번 장에서만 쓰이기 때문에, 우리는 그것들이 최종 LFS시스템과 섞이는 것을 원하지 않습니다.

설치명령들은 bash shell을 사용한다고 가정합니다 또한 이미 소스팩키지의 압축을 풀었다고 가정하고,(lfs사용자로서 로그인된 동안 - 앞에서 간단히 설명했음 .) 설치명령을 사용하기 전에 팩키지의 소스 디렉토리로 들어가기위해 cd 명령을 사용합니다.

그 팩키지들의 일부는 컴파일전에 패치됩니다. 그 패치는 버그를 피하기 위해 필요로 합니다. 패치는 종종 이 장과 다음 장 둘다에서 필요하지만 그리 큰 문제는 아닙니다.그러므로 패치를 다운로드 하기 위한 설명을 볼 때 헷갈리더라도 너무 걱정하지 마세요. 패치를 적용할 때 경우에 따라 offset 이나 fuzz.에 관한 경고 메세지를 보게 될것입니다. 이런 경고들은 패치를 성공적으로 적용 하는데 있어서 전혀 걱정할 것이 없습니다.

대부분의 팩키지 설치과정동안 화면에서 모든 종류의 컴파일 경고를 볼 것입니다. 이 경고들은 정상적이므로 신경쓰지 않아도 좋습니다. C 언어의 표준은 많이 바뀌었는데, 일부 팩키지들은 옛 버전의 C에 맞추어져 있기 때문에 나오는 메세지입니다. 신경쓸 부분은 아닙니다.

잊지 말아 주세요. 불필요한 것 없이 공간을 절약하기 위해, 각 팩키지를 설치한 후에 소스와 설치 디렉소리를 삭제하는 것이 좋습니다.

작업을 진행하기전에 아래처럼 실행함으로써 LFS 환경변수를 적용 되었음을 확인할 수 있습니다. 
echo $LFS

LFS 파티션의 마운트된 곳의 경로를 출력결과로 확인 할 수 있습니다. 책의 내용을 따랐다면 "/mnt/lfs"을 볼 수 있을 겁니다.

[edit]

3.2 Toolchain technical notes


이 장에서는 세부적인 기술과 원리의 일부를, 뒤에서는 전체적인 설치방법을 설명 할 것입니다. 여기의 내용을 바로 이해하지 못해도 상관없습니다. 일단 한번 실제로 설치해보면 대부분 감이 올 것입니다. 나중에라도 언제든지 이곳을 참조하세요.

5장은 '/'를 임시로 바꿈으로써 6장에 서 LSF 시스템을 깔끔하고 문제없이 설치할 수 있는 환경을 제공하는 것을 목표로 합니다. 이런식으로 되도록 호스트 시스템으로 부터 우리의 시스템을 분리하기를 시도하고, 독립적으로 작동 할 수 있는 Toolchain을 설치합니다. 처음 접하는 사람들에게 위험부담을 최소화하고 교육효과는 최대화 되도록 설치과정이 고안되었습니다. 다시말해, 이 시스템을 설치해봄으로써 더 나은 기술을 얻을 수 있다는 말입니다.

주의사항 : 작업을 계속하기에 앞서, 자신의 플랫폼예를들면 i386이 무엇인지 알아두어야 합니다.대부분의 경우는 i686기반 리눅스에 적절할 것입니다. 간단한 방법으로 소스팩키지 속에 있는 config.guess 를 실행함으로써 자신의 플랫폼에 맞는 것을 선택할 수 있습니다. Binutils 소스의 압축을 풀고 ./config.guess를 실행해서 그 출력문을 메모하세요.

설치를 할 때 자신의 플랫폼에 맞는 dynamic linker 의 이름을 알아두어야 하고, 종종 dynamic loader 를 참조 할 때 Binutils 안에 들어있는 표준링커인 ld 와 혼동하지 말아야 합니다. The dynamic linker is provided by Glibc and has the job of finding and loading the shared libraries needed by a program, preparing the program to run and then running it. 전통적으로 dynamic linker 의 이름은 ld-linux.so.2를 사용합니다. ld.so.1이라는 이름은 잘 사용하지 않았고, 새로운 64비트 기반 플랫폼에서는 전혀 다른 이름을 사용합니다. 당신 시스템의 /lib 디렉토리에서 dynamic linker의 이름을 확인 할 수 있습니다. 가장 확실한 방법은 호스트의 불특정한 프로그램을 대상으로 readelf -l <name of binary> | grep interpreter 을 실행함으로써 확인을 해보는 것입니다. Glibc 소스 트리의 root에 있는 shlib-versions의 파일에 모든 플랫폼에 대한 정보가 들어있습니다.

5 장에서 설치작업을 할 때 아래 내용도 참조하세요.

  • 원칙적으로 크로스 컴파일은 같은 프리픽스안에 설치된 툴이 협력에서 작동하고 작은 GNU "magic"을 이용한다.
  • 프로그램이 연결되는 것을 보증하는 표준이 되는 링커의 라이브러리 탐색패스의 조작은 단지 우리가 선택한 라이브러리에 반대한다.
  • 동적인 링커를 타겟으로 하는 gcc 스펙파일의 주의깊게 사용해야 한다.

Binutils는 GCC와 Glibc이 그들의 각각의 수행 동안 어셈블러와 linker에 대한 다양한 특징 시험을 수행하기 때문에 첫번째 설치됩니다. Binutils는 GCC와 Glibc이 가능하게 하거나 무능하게 만드는 어떤 소프트웨어 특징을 결정하는 ./configure의 각각의 구동동안 어셈블러와 linker에 대해 다양한 기능 시험을 수행하기 때문에 첫번째 설치됩니다. 이것은 첫번째 인식한것보다 더 중요하다. 부정확하게 구성된 GCC와 Glibc는 결과적으로 미세하게 부숴진 그런 파손의 충격이 모든 분배의 빌드의 끝까지 보이면 안되는 Toolchain이 될 수 있습니다. 고맙게도, test suite 실패는 너무 많은 시간을 낭비하기 전에 보통 우리에게 경고 할 것이다.

Binutils는 /tools/bin 와 /tools/$TARGET_TRIPLET/bin의 안에 그것의 어셈블러와 링커를 인스톨합니다. 현실에서 한 위체에 있는 도구는 다른 몇몇에게 연결됩니다. 링커의 중요한 면은 그것의 라이브러리 탐색 순서입니다. 상세한 정보는 verbose flag를 지나가는 것에 의해 ld 로부터 얻어 질 수 있습니다. 예를 들면, ld verbose | grep SEARCH은 당신에게 그 현재의 탐색 패스와 그들의 순서를 보여줄 것입니다. 당신은 실제로 파일이 무엇인지 dummy 프로그램을 컴파일하고 verbose 교환을 링커에게 건넴으로써 ld에 의해 연결되는 것을 볼 수 있습니다. 예를 들면, gcc dummy.c -Wl,verbose 2>&1 | grep은 당신에게 성공적으로 그 연결동안 열린 모든 파일을 보여줄 것입니다.

설치된 다음의 패키지는 GCC입니다. GCC의 ./configure수행동안에 당신은 아래 예를 볼 것입니다. 
checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as
checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld

이것은 위에 언급된 이유때문에 중요합니다. 그것은 GCC의 설정 스크립트는 사용하는 tool을 발견하기 위해 $PATH 디렉토리를 를 탐색하지 않는것을 보여줍니다. 그러나 gcc의 실제 작동안 같은 탐색 패스는 필연적으로 사용되지 않습니다. 당신은 gcc -print-prog-name=ld의 구동에 의해 표준 링커 gcc를 찾아낼 수 있습니다. 상세한 정보는 컴파일하는 더미 프로그램동안의 -v flag를 패싱하는 것에 의해 gcc로부터 얻어질 수 있습니다. 예를 들면, gcc -v dummy.c의 탐색 패스와 그들의 순서를 포함함으로써 프리프로세서, 컴파일, 어셈브리한 스테이지에 대한 상세한 정보를 보여줄 것입니다.

설치된 다음의 패키지는 Glibc입니다.

Glibc을 빌드하는 것에 대한 가장 중요한 고려사항은 그 컴파일러, 바이너리 툴과 커널 헤더입니다. 컴파일러는 Glibc이 항상 $PATH 디렉토리에서 gcc를 발견하는데 항상 사용것이므로 일반적으로 아무런 문제가 없습니다. 바이러리 툴과 커널 헤더는 작고 더 까다로울 수 있습니다.그러므로 우리는 위험이 없고 올바른 선택을 강화하기위해 스위치 설정을 사용합니다. ./configure 후에 당신은 모든 중요한 세부사항을 위해 glibc-build 디렉토리에서 config.make 파일의 내요을 검사 할 수 있습니다. 당신은 바이너리 툴이 사용되는 제어에 CC="gcc -B/tools/bin/"의 사용과 같은 재미있는 아이템을 주목할 것이고, 또한 탐색 패스을 포함한 컴파일러의 제어에 -nostdinc and -isystem flags의 사용과 같은 재미있는 아이템을 주목할 것입니다. 이 아이템은 Glibc 패키지의 중요한 관점에 강조하는 것을 돕습니다. 이것은 그것의 빌드 장치에서 매우 독립적이고 일반적으로 toolcahin default를 믿지 않습니다.

Glibc 인스톨후 우리는 우리의 /tools frefix에서 탐색하는 것과 연것하는 것이 발생하는 것을 보증하는 조정을 만듭니다. 우리는 조정된 ld를 설치하는데 그것은 컴퓨터안의 탐색길은 /tools/lib까지 한정되게 합니다. 그리고 우리는 /tools/lib에 우리의 새로운 동적인 링커를 가리키기 위해 gcc의 스펙파일을 고칩니다. 이 마지막 단계는 모든 과정에 중요합니다. 위에 말한대로, 동적인 링커로의 컴퓨터내의 패스는 모든 공유된 실행가능한 ELF로 내장됩니다. 당신은 readelf -l <name of binary> | grep interpreter을 수행함으로써 이것을 점검할 수 있습니다. 수정된 gcc의 스펙 파일에 의해 우리는 이 장의 끝을 통해 여기로부터 컴파된 모든 프로그램이 /tools/lib에 우리들의 새로운 동적인 링커를 사용할 것을 보증하고 있습니다.

새로운 동적인 링커를 사용할 필요성은 GCC의 두번째 패스를 위해 스펙 패치를 적용하는 것이 이유입니다. 그렇게 하는 데 있어서의 실패는 결과적으로 그들안으로 내장된 호스트 시스템 /lib 디렉토리로부터 그들 스스로 동적인 링커의 이름을 가지고 있는 GCC 프로그램이 될 것입니다. 그런데 그것은 호스트로부터 물러가는 우리들의 목적을 좌절 시킬 것입니다.

Binutil의 두번째 패스동안에 우리는 --with-lib-path 패스를 이용할 수있습니다. ld의 라이브러리 탐색 패스를 관리하기 위해 스위치를 구성합니다. 전방으로 이 포인트로부터 코어 toolchain은 독립식이고 호스트입니다. 5장의 나머지는 /toos에 새로운 Glibc에 반대하는 모든 빌디를 패키지합니다. 모두 잘 있습니다. 6장에서 chroot환경에 들어가자마자, 우리가 언급한 그것의 독립식 때문에 우리가 첫번째 중요한 팩키지에서 인스톨한것은 Glibc이다.

[edit]

3.3 정적연결에 대한 주의


모든 프로그램은 그들의 특정한 테스크옆에서, 오히려 보통적이고 때때로 하찮은 많은 동작을 수행합니다. 할당하는 메모리, 디렉토리와 파일 쓰기, 파일 읽기 string 조작, 패터 매칭, 수학과 다른 많은 직무를 포합니다. Wheel을 재발명하기 위해 각각의 프로그램을 어쩔수 없이 하게 하는 대신에, GNU 시스템은 이미 만들어진 라이브러리에 있는 기본적인 이 기능을 제공합니다.

그 들을 사용하는 프로그램에 대한 라이브러리로부터의 기능을 연결하는 두 주요한 방법(정적, 동적 :statically 또는 dynamically)이 있습니다. 프로그램이 정적으로 링크되었을때, 결과적으로 더 부피가 큰 프로그램이 되면서 실행가능한 그 사용된 function의 코드는 포함됩니다. 프로그램이 동적으로 링크되었을때, 포함되는 것은 동적인 링커, 라이브러리의 이름, 그리고 그 function의 이름에 대한 참조입니다. 그런데 그것은 더 작은 많은것에서의 실행가능한 결과입니다. 세번째 방법은 동적인 링커의 프로그래밍 인터페이스를 사용하는 것입니다. 더 많은 정보는 dlopen manpage를 보세요.

D동적인 연결은 Linux에 default하고 정적인 연결에 대한 중요한 세가지 중요한 장점을 가지고 있습니다.

첫 번째, 그 같은 코드의 많은 복사를 프로그램의 모든 가지(bunch)안으로 포함되게 하는 대신에 하드디스크에서 실행가능한 라이브러리 코드의 단지 하나의 복사를 필요로 합니다. 그래서 디스크공간 절약됩니다.두번째, 여러개의 프로그램이 같은 라이브러스 펑션을 동시에 사용할 때, 펑션 코드의 단지 한 복사는 core에 요구됩니다. 그래서 메모리공간이 절약됩니다.세번째, 라이브러리 펑션이 버그를 고정되게 하거나 그렇지 않으면 개선될 때, 그 개선된 펑션을 이용하는 모든 프로그램을 다시 컴파일해야 하는 대신에 단지 이 한 라이브러리를 다시 컴파일 필요가 있습니다.

동적인 연결이 여러 장점을 가지고 있다면 왜? 우리는 이 장에서 첫번째 두 팩키지를 정적으로 연결할까요? 그 이유는 3부분입니다.- 역사적이고, 교육적이고, 기술적입니다(historical, educational, and technical). 역사적으로는, 더 일찍이 LFS의 버젼 이 장의 모든 프로그램에서 정적으로 연결되었기 때문입니다. 교육적으로는, 차이점을 아는것이 유용하기 때문입다. 기술적으로는, 우리가 그렇게 하는데 있어서 호스트로부터 독립적인 부분을 얻기 때문입니다. 의미는 프로그램이 호스트 시스템으로부터 독립적으로 사용되는 것입니다. 그러나 처음 두 패키지가 동적으로 빌드될 때, 전체의 성공적인 LFS 빌드는 여전히 성취할 수 있다는 것을 유의할 가치가 있습니다.

[edit]

3.4 $LFS/tools 디렉토리 만들기


이 장에서 컴파일된 모든 프로그램들은 다음 장에서 컴파일될 프로그램들과 분리하기 위해 $LFS/tools 아래 설치될 것입니다. $LFS/Tools 에서 컴파일된 프로그램들은 임시로 사용될 도구들이고, 최종 LFS시스템에서는 지울 것입니다.

임시도구들이 저장된 디렉토리를 쉽게 찾기위해 고유한 이름을 사용하기를 원할 것입니다. "Tools"이라는 이름 대신에 "tools-for-lfs"라는 이름을 사용할 수도 있습니다. 이책을 보는동안 "tools"라는 이름을 대신 다른 이름을 사용하는 것은 조심하기 바랍니다.

다음과 같은 디렉토리를 만드세요. 
mkdir $LFS/tools
다음 단계는 당신 시스템에 /tools란 심볼릭링크를 만드는 것입니다. 이것은 LFS파티션에서 만들어진 디렉토리를 가리킵니다. 
ln -s $LFS/tools /
참조: 위의 명령은 정확한 예입니다. 하지만, ln명령은 약간의 문법적 변화를 가질수 있습니다. 그러므로 에러가 발생하면 질문하기전에 info 페이지를 참고하기 바랍니다.

만들어진 심볼릭링크는 우리가 컴파일할 때 항상 /tools를 참조할 수 있게 해주고, compiler, assembler, linker 를 사용할 수 있도록 해 줍니다. 다음장에서도 사용하게 됩니다.

[edit]

3.5 "LFS" 계정 만들기


"ROOT"로 로그인한 상태에서는 작은 실수로도 데미지를 입거나 시스템이 망가질 수가 있습니다. 그러므로 이 장에서 팩키지 설치 작업을 할 때에는 일반 계정으로 할 것을 권합니다. 물론 자신만의 사용자 이름을 쓸수도 있지만 쉽고 깔끔한 작업 환경을 위해 "LFS" 라는 새로운 사용자를 만들고 설치 과정동안 사용할 겁니다.ROOT 상태에서 다음과 같은 명령을 실행하여 새로운 사용자를 추가합시다. 
useradd -s /bin/bash -m -k /dev/null lfs
옵션 설명:
  • -s /bin/bash: bash 를 lfs 계정의 기본 쉘로 사용합니다.
  • -m -k /dev/null: 이렇게 하면 /etc/skel 안의 화일들이 lfs 계정의 홈 디렉토리로 복사되는걸 방지합니다.(즉 어떤 환경 설정 화일도 자동으로 만들어지는 걸 방지한다는 말)

lfs 로 로그인 하기 위해선 Password 를 만들어야 합니다. 
passwd lfs
$LFS/tools 디렉토리의 소유권을 lfs 사용자에게 줌으로써 $LFS/tools를 사용할 수 있게 합니다. 
chown lfs $LFS/tools
만약 작업 디렉토리를 따로 만들어 주었다면 그 디렉토리의 소유권도 lfs유저로 바꾸어 주세요. 
chown lfs $LFS/sources
lfs 계정으로 로그인 하세요. 다음과 같이 입력하세요: 
su - lfs
"-" 옵션은 로그인 쉘로 시작하라는 뜻입니다.

[edit]

3.6 기본 환경 변수 설정하기


우리는 좀 더 편한 작업 환경을 위해 bash shell에서 사용하는 2개의 환경 설정 화일을 만들 겁니다.lfs 계정으로 로그인 한 후, 다음 명령을 수행하여 .bash_profile 화일을 만드세요. 
cat > ~/.bash_profile << "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
EOF

주의 : adduser 명령으로 lfs계정을 생성하면 .bash_profile 화일이 자동으로 생성될 겁니다. 위와 같이 해도 별 무리는 없지만 만약을 위해서 vi로 편집하는 것을 추천합니다.

일반적으로, lfs 계정으로 로그인하면, /etc/profile 화일을 읽어 shell을 초기화합니다.( 각종 셋팅 내용과 환경 변수들이 들어 있는) "exec env -i ... /bin/bash" 명령을 이용하면 "HOME,TERM,PS1" 환경 변수를 제외한 나머지 변수들은 모두 깨끗히 비운 상태로 로그인 하게 됩니다. 이것은 LFS 시스템을 설치하는 동안 만들어진 각종 환경 변수들이 현재 환경에 마음대로 영향을 끼치거나 나중에라도 어떤 영향을 끼치지 않게 해 줍니다.

non-login shell은 /etc/profile 이나 .bash_profile 파일 대신 .bashrc 파일을 읽습니다. 자 그럼. class="filename">.bashrc파일을 만들어 봅시다. 
cat > ~/.bashrc << "EOF"
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
PATH=/tools/bin:/bin:/usr/bin
export LFS LC_ALL PATH
EOF

주의 : adduser 명령으로 lfs계정을 생성하면 .bashrc 화일이 자동으로 생성될 겁니다. 위와 같이 해도 별 무리는 없지만 만약을 위해서 vi로 편집하는 것을 추천합니다.

set +h 명령은 bash의 hash function 기능을 꺼 줍니다.일반적으로 hashing 기능은 아주 유용합니다. bash는 실행화일을 찾고 실행하는 시간을 줄이기 위해 실행화일의 full pathname이 저장된 hash table 를 사용합니다. 그러나 우린 LFS 시스템 설치를 할 때, 기존의 tool을 사용하는 아니라, 새로 설치한(임시 tool들)을 사용하기 때문에 이 기능은 필요 없습니다. hashing 기능을 끄면, LFS 시스템을 설치하는 동안 우리가 새로 설치한 도구들을 사용할 수 있습니다.

Umask를 022로 설정해 놓으면 새로 만들어 지는 파일이나 디렉토리는 그것들의 소유자만 쓸 수 있고, 다른 사용자들은 읽거나 실행만 할 수 있습니다.

LFS 변수는 선택한 마운트 포인트로 하면 됩니다.

LC_ALL 환경 변수는 지역화를 설정해 주는 역활을 합니다. 이 변수를 지정해 주면, 각종 단위등이 각 국가에 맞게 조절됩니다. 만약 현재 사용하고 있는 Glibc가 2.2.4 버전보다 낮고 LC_ALL 환경 변수가 "POSIX"나 "C"가 아니라면 문제가 생길 가능성이 큽니다.(아마 그럴일은 없을 겁니다. 요즘은 Glibc 버전이 2.2.4보다 높습니다.) LC_ALL 환경 변수를 "POSIX"로 설정합시다.

/tools/bin을 PATH에 추가합시다.

마지막으로, 다음 명령을 실행하면 임시 도구들을 만들기 위한 환경이 완벽하게 준비됩니다. 
source ~/.bash_profile
[edit]

3.7 Binutils-2.14 - Pass 1 설치


Approximate build time: 1.0 SBU Required disk space: 194 MB

Bintutils(2.14) 공식 다운로드 사이트: ftp://ftp.gnu.org/gnu/binutils/

Binutils와 의존성 관계에 있는 프로그램들: Bash, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo.

[edit]

3.7.1 Binutils의 인스톨


binutils는 가장 먼저 컴파일 해야 합니다.

기본 최적화 플래그(including the -march and -mcpu options)들을 변경하는것은 그리 좋지 습관이 아닙니다. 그러므로 만약에 당신이 CFLAGS나 CXXFLAG 같은 이미 최적화 되어있는 환경변수들을 변경했을 경우에는 Glibc를 설치할 때 원상복귀 시켜주세요.

binutils 문서에서는 binutils를 설치할때 /tools 밖에서 설치하는것을 권장합니다: 
mkdir -p $LFS/build/binutils-build
cd $LFS/build/binutils-build
tar zxvf /mnt/source/binutils-2.14.tar.gz -C ./
Note: SBU를 제대로 측정하기 위해서는 한 팩키지를 설치할 때 필요한 총 시간을 계산할 수 있는 방법을 사용해야 합니다. 다음과 같이 하면 SBU를 제대로 구할 수 있습니다. time { ./configure ... && ... && ... && make install; }.

Binutils 컴파일 준비하기: 
cd $LFS/build/binutils-build/binutils-2.14
./configure --prefix=/tools --disable-nls

The meaning of the configure options:
  • --prefix=/tools: binutils프로그램들을 /tools로 설치하라는 옵션.
  • --disable-nls: 다국어 지원옵션을 끈다. 우리는 앞으로 프로그램을 정적으로 컴파일해서 사용할 건데 이와같은 옵션을 켜두면 나중에 문제가 생길수 있어서 사용하지 않는다.

이어서 컴파일을 계속 합시다.: 
make configure-host
make LDFLAGS="-all-static"

Make 파라메터의 의미:
  • configure-host: 정적으로 컴파일할 때 이 옵션없이는 실패할 것입니다. 그러므로 우리는 문제를 해결하기 위해 이 옵션을 사용해야 합니다.
  • LDFLAGS="-all-static": 모든 binutils 프로그램들은 정적으로 컴파일하라는 옵션입니다.

자, 이제 컴파일은 끝났습니다. test suite를 어디에서 실행할 것인지가 중요합니다. 아직 언급이 조금 이른 것이기에, 이 장에서는 test suites 를 실행하는것은 추천하지 않습니다.(for the temporary) GCC test suite를 실행하기를 원할지라도 아직 없기때문에 이 장에서 사용할 수 없습니다. 게다가 이번장에서 설치한 프로그램은 다음 설치과정에서 덮어쓰기 됩니다.

패키지 인스톨하기: 
make install

Glibc를 설치한 후에 보게 될 "locking in"부분을 위한 선행작업: 
make -C ld clean
make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib

make 파라미터의 의미:
  • -C ld clean: ld 디렉토리안의 모든 컴파일된 실행화일들을 지운다.
  • -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib: 이옵션은 ld 서브 디렉토리 안의 모든 프로그램들을 리빌드한다. LIB_PATH 변수에 "/tools/lib"를 지정하면 기본 셋팅되어 있는 디렉토리를 참조하는 것이 아니라 라이브러리 패스로 /tools/lib를 참조하게 된다. 이 변수는 링커의 경로를 지정하는 역할을 한다. 
주의

Binutils 와 소스 디렉토리를 지우지 마세요. 이 장의 뒷쪽에서 다시 사용하게 됩니다.

자세한 내용은 the Section called Contents of Binutils in Chapter 6을 참조하세요.
[edit]

3.8 GCC-3.3.2 - Pass 1 설치


Approximate build time: 4.4 SBU Required disk space: 300 MB

GCC (3.3.2) 공식 다운로드 사이트: ftp://ftp.gnu.org/pub/gnu/gcc/

GCC와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, Findutils, Gawk, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo.

[edit]

3.8.1 GCC 설치


C++ 은 필요하지 않으므로 GCC-core tarball의 압축을 풀어 주세요.

기본 최적화 플래그(including the -march and -mcpu options)들을 변경하는것은 그리 좋지 습관이 아닙니다. 그러므로 만약에 당신이 CFLAGS나 CXXFLAG 같은 이미 최적화 되어있는 환경변수들을 변경했을 경우에는 Glibc를 설치할 때 원상복귀 시켜주세요.

GCC 문서에서는 GCC를 설치할때 /tools 밖에서 설치하는것을 권장하고 있습니다. 
mkdir -p $LFS/build/gcc-build
cd $LFS/build/gcc-build
tar xvf /mnt/source/gcc-3.3.2.tar.gz -C ./
GCC를 컴파일 하기 위해 먼저 해야 하는 작업 
cd $LFS/build/gcc-build/gcc-3.3.2
./configure --prefix=/tools \
    --with-local-prefix=/tools \
    --disable-nls --enable-shared \
    --enable-languages=c

configure 옵션의 의미
  • --with-local-prefix=/tools: gcc include path가 /usr/local/include로 되어 있는 것을 /tools/로 바꾸어 주기 위서입니다. 이 옵션이 꼭 필요한 것은 아니지만 우리는 호스트 시스템에 영향을 최소화 하기를 원하기 때문에 이 옵션을 사용합니다.
  • --enable-shared: 처음에 보면 이 옵션에 무엇을 하는지 확실히 모를 것이다. 그러나 이것을 사용하면 libgcc_s.so.1, libgcc_eh.a 와 연결이 될 것입니다. 그리고, 이후에 컴파일할 Glibc 가 올바르게 컴파일 되므로 필요합니다. Gcc 바이너리들은 컴파일할 때 BOOT_LDFLAGS 플래그에 -static 값을 주므로써 정적으로 링크될 겁니다.
  • --enable-languages=c: 이 옵션은 설치시에 C 컴파일러를 사용하도록 지정합니다. 이 옵션은 GCC 타르볼을 다운로드 받아서 설치할때만 사용합니다.

패키지 컴파일하기. 
make BOOT_LDFLAGS="-static" bootstrap

make파라미터의 의미
  • BOOT_LDFLAGS="-static": GCC를 정적으로 컴파일 해준다.
  • bootstrap: This target doesn't just compile GCC, but compiles it several times. It uses the programs compiled in a first round to compile itself a second time, and then again a third time. It then compares these second and third compiles to make sure it can reproduce itself flawlessly, which most probably means that it was compiled correctly.

컴파일은 끝났습니다. test suite를 어디에서 실행할 것인지가 중요합니다. 아직은 그런걸 말하기엔 조금 이르기 때문에, 이 장에서는 test suites 를 실행하는것은 추천하지 않습니다. GCC test suite를 실행하기를 원할지라도 아직 없기 때문에 이 장에서 사용할 수 없습니다. 게다가 이번장에서 설치한 프로그램은 다음 설치 과정에서 덮어 쓰게 됩니다.

패키지 설치하기: 
make install
지금까지의 과정이 끝나면 /tools/bin/cc의 symlink를 만들것입니다. 많은 프로그램들과 스크립트들은 gcc 대신에 cc를 이용합니다. 이것은 프로그램의 속성을 유지하게 하고, 모든 종류의 유닉스 시스템에서 사용할 수 있게 해줍니다. 모든 종류의 유닉스 시스템에 GNU C 컴파일러가 설치되어 있는건 아닙니다. 이렇게 하면, 시스템에 어떤 종류의 C 컴파일러가 설치되어 있던간에 일일히 관리자 신경써줄 필요가 없기 때문에 편합니다. 심볼릭 링크의 장점이 바로 이런 것입니다. 
cd /tools/bin
ln -s gcc /tools/bin/cc
이 패키지에 대한 자세한 내용들은 the Section called Contents of GCC in Chapter 6에서 찾을수 있습니다.

[edit]

3.9 Linux-2.4.24 헤더들 설치


Approximate build time: 0.1 SBU Required disk space: 186 MB

[edit]

3.10 kernel 헤더 설치


일부 팩키지는 커널 헤더 파일을 참조합니다. 자, 이제 우린 커널의 압축을 풀고, 설치하고, 필요한 파일들을 gcc가 참조할 위치에 복사할겁니다.

헤더파일 설치 준비하기 
make mrproper
make mrproper를 실행함으로써 커널트리에 있는 불필요한 것들이 제거되었습니다. 리눅스 커널팀에서는 다른 여러 종류의 커널 컴파일전에 make mrproper을 실행하는 것을 추천합니다.

version.h 파일 생성하기 
make include/linux/version.h

include/asm의 심볼릭링크 만들기(LFS를 설치할 pc의 종류에 맞는 - 예를 들어 intel은 i386, power pc는 power pc로..) 
make symlinks

시스템 종류에 맞는 헤더파일 설치하기. 
mkdir /tools/include/asm
cp include/asm/* /tools/include/asm
cp -R include/asm-generic /tools/include

cross-platform 헤더파일 설치하기. 
cp -R include/linux /tools/include
일부 커널 헤더파일은 autoconf.h 헤더파일을 사용합니다. 아직 커널을 구성하지 않았기 때문에, 컴파일의 실패를 피하기 위한 파일을 만들 필요가 있습니다. 비어있는 autoconf.h 파일을 만들어 주세요. 
touch /tools/include/linux/autoconf.h
[edit]

3.11 Glibc-2.3.3 설치

[edit]

3.11.1 Glibc 설치

기본 최적화 플래그(including the -march and -mcpu options)들을 변경하는것은 그리 좋지 습관이 아닙니다. 그러므로 만약에 CFLAGS나 CXXFLAG 같은 이미 최적화 되어있는 환경변수들을 변경했을 경우에는 Glibc를 설치할 때 원상복귀 시켜주세요.

기본적으로, Glibc를 책에서 제시하는것이 아닌 다른 방법으로 컴파일하는것은 사용자의 시스템의 안정성을 해칠 수 있습니다.

Glibc문서는 전용디렉토리안에 소스디렉토리 밖에서 Glibc를 빌드하는것을 추천합니다: 
mkdir -p $LFS/build/glibc_build
cd $LFS/build/glibc_build
tar jxvf /mnt/source/glibc-2.3.3-20031202.tar.bz2 -C ./
Glibc 컴파일 준비: 
cd $LFS/build/glibc_build
./glibc-2.3.3-20031202/configure --prefix=/tools \
    --disable-profile --enable-add-ons=linuxthreads \
    --with-binutils=/tools/bin --with-headers=/tools/include \
    --without-gd --without-cvs

여기서 잠깐. Glibc를 컴파일 할 때는 절대! Glibc의 압축을 풀어 놓은 디렉토리에서 하면 안 됩니다. 위에서도 보면 알겠지만, 압축을 풀어 놓은 디렉토리가 아니라 상위 디렉토리에서 작업을 하고 있음을 알 수 있습니다. 만약 압축을 풀어 놓은 디렉토리에서 작업을 하게 되면 일단, Configure에서 에러가 발생하고 억지로 컴파일을 한다고 해도 컴파일 도중 에러가 발생합니다.

설정 옵션의 의미:
  • --disable-profile: 프로파일 정보 라이브러리들의 빌딩을 비활성화합니다. 당신이 프로파일을 만들 계획이라면 이 옵션을 빼세요.
  • --enable-add-ons=linuxthreads: threading라이브러리처럼 Linuxthreads add-on을 사용을 한다고 Glibc에게 알려줍니다.
  • --with-binutils=/tools/bin and --with-headers=/tools/include: 이 부분은 절대 건드리지 말고 그대로 하세요. 이 부분을 건드리면 컴파일 자체가 안 되거나 된다 하더라도 나중에 100% 문제가 발생합니다.
  • --without-gd: 이 스위치는 호스트 라이브러리들(libgd, libpng, libz, 등등)을 향해 링크되는 이상한 것들의 memusagestat프 로그램이 빌드되지 않도록 합니다.
  • --without-cvs: 이것은 CVS snapshot을 사용할때 자동으로 CVS위험을 시도하는것으로부터 Makefile들을 막는것을 의미합니다.(그리 신경쓸 필요는 없어요)

이 장을 하면서 보게되는 warning들: 
configure: WARNING:
*** These auxiliary programs are missing or incompatible versions: msgfmt
*** some features will be disabled.
*** Check the INSTALL file for required versions.
잃어버리거나 호환성이 없는 msgfmt프로그램은 일반적으로 필요 없습니다, 하지만 가끔 test suite를 실행할때 문제를 일으킵니다.

패키지 컴파일: 
make

컴파일은 이제 끝났습니다. 일찌기 말했던 것처럼, 우리는 이 장에서 임시 시스템을 위해 test suite들을 실행할것을 권하지 않습니다. 만약 당신이 Glibc test suite를 어떤 다른 방법으로 아직까지 실행하고 싶다면, 아래와 같이 실행하세요. 
make check

Glibc test suite는 특유한 커널인 호스트 시스템의 어떤 함수들과 높은 의존성을 가집니다. 부가적으로, 이 장의 어떤 테스트들은 호스트 시스템에 일어나는 환경들 또는 현존하는 툴들에 악영향을 미칠 수 있습니다. 물론, 6장의 chroot환경안에서 Glibc test suite를 실행할때는 문제가 되지 않습니다. 보통, Glibc test suite는 항상 문제없이 넘어갑니다. 하지만, 위에 언급한대로 어떤 문제들은 어떤 상황에서 문제를 일으키는 것을 피할수 없습니다. 다음은 이미 알려져 있는 대표적인 문제점들입니다.:
  • math테스트는 새 정품 Intel이나 믿을만한 AMD에 관한 CPU가 아닌 시스템에서 실행될때 에러 발생함.
  • gettext는 가끔 호스트 시스템문제로 인해 에러가 발생함.. 아직까지 왜 그런지 모릅니다.
  • atime테스트는 noatime으로 마운트된 LFS파티션이나 다른 파일 시스템 때문에 에러가 발생합니다. .
  • shm테스트는 호스트 시스템이 devfs파일 시스템에서 실행할때 에러가 발생합니다. 하지만 커널에서 tmpfs를 지원해서 /dev/shm에 마운트된 tmpfs파일 시스템은 괜찮습니다.
  • 옛날 느린 하드웨어에서 실행할때, 어떤 테스트들은 테스트 타임아웃으로 에러가 발생합니다.

이번에, 이 장에서 Glibc test suite의 실패들을 많이 보게 될것을 두려워 하지 마세요. 6장 Glibc는 그냥 넘기는 수준으로 할것입니다. 하지만 6장에서도 어떤 실패들은 발생할수 있다는 것은 항상 염두에 두세요. -- 예를들어 math테스트들. 실패를 경험한다면 make check를 하는것을 잊지마세요. 당신은 make -k check의 이행으로써 stop-start차례를 명령할수 있습니다. 그렇게 한다면 나중에 모든 실패 횟수와 설명들, 로그 파일을 살펴 볼 수 있습니다.

Glibc를 설치할 때, /tools/etc/ld.so.conf이 없다고 하소연 할것입니다. 이것은 쓸데없는 메세지입니다. 성가신 작은 warning이 발생하지 않도록 아래와 같이 합시다: 
mkdir /tools/etc
touch /tools/etc/ld.so.conf

이제 패키지 설치: 
make install

다른 나라들과 문화들은 그들이 대화하기위한 여러가지 풍습을 가집니다. 날짜와 시간의 표현 형식 처럼, 매우 간단한 것들로부터 이 풍습들의 범위는 말하는 언어처럼 매우 복잡한 것들까지 있습니다. GNU프로그램의 "internationalization"는 locales의 의미로서 작업합니다.

아래와 같이 하면 모든 로케일들이 설치가 됩니다.(대신 시간이 오래 걸립니다.) 
make localedata/install-locales

당신이 필요로 하는 로케일들만을 설치하려면 아래와 같이 하세요. 이것은 localedef명 령을 사용하면 됩니다. 이것에 대한 정보는 Glibc소스에 INSTALL파 일에서 찾을수 있다. 하지만, GCC로부터 그냥 지나치는 libstdc++테스트들은 미래 패키지들의 테스트들을 위한 특별한 많은 locale들이 있다. 위에 install-locales를 제외하고, 성공하기위한 최소한의 필요한 locale들을 설치할것이다, 아래 내용을 따라하라: 
mkdir -p /tools/lib/locale
localedef -i de_DE -f ISO-8859-1 de_DE
localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro
localedef -i en_HK -f ISO-8859-1 en_HK
localedef -i en_PH -f ISO-8859-1 en_PH
localedef -i en_US -f ISO-8859-1 en_US
localedef -i es_MX -f ISO-8859-1 es_MX
localedef -i fr_FR -f ISO-8859-1 fr_FR
localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro
localedef -i it_IT -f ISO-8859-1 it_IT
localedef -i ja_JP -f EUC-JP ja_JP

더 자세한 내용은 the Section called Contents of Glibc in Chapter 6에서 찾을 수 있습니다.

[edit]

3.12 "Locking in" Glibc


지금까지 임시 C 라이브러리들을 설치했고, 이 장의 나머지 부분에서 설치할 모든 도구들은 이 C 라이브러리와 상관없이 컴파일할 것입니다. 그러기위해서, 우리는 링커와 컴파일러 설정파일을 변경시켜야 합니다.

우선 binutils-build 디렉토리 안에서 다음과 같은 명령을 수행해서 라이브러리 독립적인 링커를 설치하세요. 
make -C ld install

링커는 binutils 설치의 first pass가 끝날때 원상복귀 됩니다. 여기서 요점은 앞으로 어떤것도 /tools/lib에 있는 라이브러리와 링크가 되지 않는다는 것입니다

알림: 첫 단계(first pass)에서 Binutils 소스와 build 디렉토리를 유지하기위한 사소한 경고들을 놓쳤거나 또는 우연히 그것들이 삭제되었다거나 읽을 수 없다고 해도 결코 걱정하지 마세요 그것은 사라진 것이 아닙니다. 이것은 이상적인(좋은 현상) 것은 아니지만, 그렇다고 중요한 문제도 아닙니다. Binutils 설치의 다음 단계(second pass)에서 똑같은 현상이 일어날 수 있습니다.

자, 이제 링커(adjusted linker)가 설치되었으니까, build된 binutils과 소스 디렉토리를 지우세요.

다음단계는 GCC가 다이나믹 링커를 가리키게 하기 위해 GCC 설정파일을 고치는 것입니다. 다음과 같이 간단한 sed 명령을 실행하면 GCC 설정파일이 고쳐질 것입니다. 
SPECFILE=/tools/lib/gcc-lib/*/*/specs &
sed -e 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \
    $SPECFILE > tempspecfile &
mv -f tempspecfile $SPECFILE &
unset SPECFILE

우리는 모든것을 일일이 손으로 입력하는 것(try-and-type) 보다는 붙여 넣기(cut-and-paste) 하는 것을 추천합니다.

Important: 다이나믹 링커의 이름이 ld-linux.so.2와는 다른 플랫폼에서 작업업중이라면, ld-linux.so.2라는 이름 대신에 플랫폼의 다이나믹 링커 이름으로 바꾸어 줘야 한다.더 많은 정보가 필요하다면 Toolchain technical notes를 참조하기 바란다.

마지막으로, 호스트 시스템의 GCC's private include dir에 각종 include file 들이 들어 있을 수 있습니다. GCC build 과정 중에 GCC "fixinclude" process 부분이 있는데, 그 부분이 실행될때 위와 같은 일이 일어날 수 있습니다. 앞으로 우리는 이 장에서 더 자세히 설명할 것입니다. 이제, 아래와 같이 실행함으로써 GCC's private include dir에 include file 들이 들어가는 경우를 방지할 수 있습니다. 
rm -f /tools/lib/gcc-lib/*/*/include/{pthread.h,bits/sigthread.h}
경고

새로운 toolchain의 기본기능(compiling and linking)을 설치하고 지우는 것이 중요한 일입니다. 다음과 같이 간단한 프로그램을 짜서 제대로 설치되었는지를 확인해 봅시다. 

echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'

지금까지 모든 작업을 잘 따라 했다면 에러는 없을 것이고, 다음과 메세지를 볼 수 있을 것입니다.

[ Requesting program interpreter: /tools/lib/ld-linux.so.2 ]

(다이나믹 링커 이름에 플랫폼의 특징이 나타나 있습니다.) 다이나믹 링커를 설치할 때 설치경로로써 /tools/lib 를 설정해 줘야 합니다.(prefix = /tools/lib) 위와 같은 메세지가 출력되지 않거나, 아무런 메세지가 없다면 어떤 것이 심각하게 잘못된 것입니다. 설치과정중에 어디에서 문제가 발생했는지 알아보고 조사하는것이 필요합니다. 설치과정이 완전히 종료되기 전까지는 위와 같은 상황이 발생해도 일일이 반응할 필요는 없습니다. 첫째, cc 대신에 gcc를 사용해서 sanity check를 반복해서 한다. 위와 같은 작업은 /tools/bin/cc의 symlink가 잘못 되어있다는 것을 의미합니다. GCC-3.3.2 - Pass 1 인스톨 에 다시 가서(참조해서) symlink를 수정해 주세요. 두번째, $PATH 환경변수가 제대로 지정되었는지 확인하자. $PATH 환경변수가 제대로 지정되었는지 확인하기 위해서 echo $PATH 를 입력해보자. echo $PATH를 입력했을때 나오는 리스트에 /tools/bin가 있으면 제대로 지정되었다고 볼 수 있다. 만약 $PATH환경변수가 잘못되었다면 lfs사용자로 로그인을 하지 않았거나 환경설정하기 장에서 무언가 실수를 했다는 의미이다. 세번째, 설정파일을 변경하고 나서 무엇가 문제가 생길 때도 있다. 그런경우에는 지난번에 추천한것처럼 cut-and-paste(원본에서 갖다붙이기)를 이용해서 설정파일을 다시 만들어라.

모든 작업이 만족스럽게 끝났다면, test files을 지우세요. 
rm dummy.c a.out
자, self-contained toolchain의 설치가 완벽하게 끝났고, 이것들은 나머지 임시도구들을 build 하는데 사용될 것이다.


[edit]

3.13 Expect-5.40.0 설치


Expect패키지는 다른 대화식 프로그램에서 대화를 스크립트하기위한 프로그램들을 포함합니다.

Approximate build time: 0.1 SBU Required disk space: 3.9 MB

Expect (5.40.0) 공식 다운로드 사이트: http://expect.nist.gov/src/

the Expect Spawn Patch를 받을 수 있는 사이트: http://www.linuxfromscratch.org/patches/lfs/cvs/expect-5.40.0-spawn.patch

Expect와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed, Tcl.

[edit]

3.13.1 Expect 설치


patch 적용하기:

patch -Np1 -i ../expect-5.40.0-spawn.patch


이 패치는 GCC test suite를 실행하는 도중에 bogus failures가 발생하는 문제를 해결 해 줍니다.

Expect 컴파일 준비하기: 
./configure --prefix=/tools --with-tcl=/tools/lib --with-x=no

configure options의 의미:
  • --with-tcl=/tools/lib: configure script가 Tcl이 설치된 임시디렉토리의 위치를 찾을 수 있게 지정해 줍니다.우리는 LFS시스템을 새로 구축하고 있기때문에 이미 호스트시템에 설치되어 있는 (배포판으로 설치해둔) Tcl을 찾는것을 원하지 않습니다.
  • --with-x=no: configure script가 TK(the Tcl GUI component)나 X Window System library를 호스트시스템(배포판으로 설치된)에서 찾지 않도록 해주는 역활을 합니다.

주의 : 특이한 경우이긴 하지만, Expect가 Tcl 헤더 파일을 찾아 내지 못하는 경우가 있습니다. 그럴 경우에는 ./configure....줄 마지막에 --with-tclinclude=/mnt/lfs/build/tcl_build/tcl8.4.5/generic(이건 제가 tcl의 소스를 풀어 놓은 경로입니다.) 같은 식으로 해서 Tcl의 위치를 지정해 주면 해결됩니다.

package 컴파일하기: 
make

이전에 말한 것처럼 이 장에서 우리는 임시도구들을 위한 test suits들을 실행하는 것을 추천하지 않습니다. 하지만, Tcl test suits를 실행하기를 원한다면, 아래와 같은 명령을 실행하세요. 그러나 호스트의 상태(설정)에 따라서(that are not fully understood)Tcl test suits가 실패하는 경우도 있다는 것을 알아야 합니다. 여기서 test suits실패해도 놀라진 마세요( 신중하게 고려할 필요는 없다.) 
make test

설치하기: 
make SCRIPTS="" install
make parameter의 의미:
  • SCRIPTS="": 이옵션은 expect scripts중에서 불필요한 것들을 설치하는 것을 방지해 줍니다.

자, 이제 Tcl과 Expect 소스 디렉토리를 삭제해도 됩니다.

[edit]

3.13.2 Expect 내용


설치된 프로그램: expect

설치된 라이브러리: libexpect5.39.a

[edit]

3.13.3 요약


expect "talks" to other interactive programs according to a script.

[edit]

3.14 DejaGnu-1.4.4 설치


DejaGnu패키지는 다른 프로그램들을 검증하기위한 framework를 포함합니다.

Approximate build time: 0.1 SBU Required disk space: 8.6 MB

DejaGnu (1.4.4) 공식 다운로드 사이트: ftp://ftp.gnu.org/gnu/dejagnu/

DejaGnu(1.4.4)와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

[edit]

3.14.1 DejaGnu 설치


DejaGnu 컴파일 준비하기: 
./configure --prefix=/tools

팩키지 빌드하고 설치하기: 
make install

[edit]

3.14.2 DejaGnu 내용


설치된 프로그램: runtest

[edit]

3.14.3 요약


runtest is the wrapper script that finds the proper expect shell and then runs DejaGnu.

[edit]

3.15 GCC-3.3.2 - Pass 2 설치


Approximate build time: 11.0 SBU Required disk space: 274 MB

GCC (3.3.2) 공식 다운로드 사이트: ftp://ftp.gnu.org/gnu/gcc/



GCC와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, Findutils, Gawk, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo.

[edit]

3.15.1 GCC의 재 인스톨


GCC 와 Binutils 을 테스트 하기 위한 tool 은 이미 인스톨 되어 있습니다. (Tcl, Expect 그리고 DejaGnu). 우리는 계속해서 GCC 와 Binutils 를 rebuild 할 수 있고, 새로운 Glibc 에 대비하여 그들을 링크할 수 있고, 그들을 적절히 테스트 할 수 있습니다 (만약 이 장에서 이들의 테스트를 실행한다면). 그러나 한가지 주의해야 할 점은 이들의 테스트는 아마도 당신의 호스트의 배포판이 제공하는 가상 터미널(PTYs)의 실행에 의존적일 것이라는 점이다. 요즘은, PTYs 는devpts 파일 시스템을 사용하는 것이 가장 일반적인 경우입니다. 만약 당신의 호스트 시스템이 간단한 테스트를 실행할 수 있는 상태로 셋업되어 있다면 당신은 신속히 확인할수 있을 것이다: 
expect -c "spawn ls"

만약 당신이 아래 메세지를 받았다면: 
The system has no more ptys.  Ask your system administrator to create more.
당신의 host distribution 은 적절한 PTY 의 동작을 위한 셋업이 되어 있지 않다는 뜻입니다. 이 경우에 당신이 해결책을 찾을 때 까지 GCC 와 Binutils 를 테스트 하기 위해 할 수 있는 것은 없습니다. 당신은 PTYs 동작에 관한 더 많은 정보를 얻을 수 있는 LFS Wiki 사이트 http://wiki.linuxfromscratch.org/에 서 참고할 수 있다.

이번에 우리는 C 와 C++ 컴파일러들을 build 할 것이며, 따라서 당신은 세가지(-core, -g++, 과 -testsuite)가 포함된 GCC tarball 을 같은 작업 디렉토리에 unpack 해야 할 것이다. 그들은 gcc-3.3.2/ 의 subdirectory 안에 들어가 있을 것이다.(gcc-3.3.2.tar.gz를 풀 경우 그 안에 필요한 모든 내용이 다 들어 있습니다.)

패치 하기: 
patch -Np1 -i ../gcc-3.3.3-no_fixincludes-1.patch
patch -Np1 -i ../gcc-3.3.3-specs-1.patch

첫번째 패치는 GCC "fixincludes" 스크립트를 무력하게 합니다. 우리는 이것을 전에 간단히 언급 했습니다, 그러나 fixinclude process 의 더 상세한 설명은 여기에 잘 나와 있습니다. 아래의 일반적인 상황에서, GCC fixincludes 스크립트는 고정될 필요가 있는 헤더 파일들을 당신의 시스템에서 검사한다. 그것은 당신의 host 시스템에서 고정된 필요가 있는 약간의 Glibc 헤더 파일을 찾을 것이고, 그들을 고정시키고, private 를 포함한 GCC 디렉토리 안에 그들을 둘 것이다. 그리고, 6장 후반부에서, 우리가 새로운 Glibc 를 인스톨한 후에, 이 private include directory 는 system include directory 전에 찾아질 것이며, host 시스템으로부터 고정된 헤더들을 찾아 GCC에서 결resulting in GCC finding the fixed headers from the host system, which would most likely not match the Glibc version actually used for the LFS system.

마지막 패치는 동적 링커의 GCC 의 기본 위치를 바꾼다 (일반적으로 ld-linux.so.2). 그것은 또한 GCC 의 include search path 로부터 /usr/include 를 제거한다. Patching now rather than adjusting the specs file after installation ensures that our new dynamic linker gets used during the actual build of GCC. That is, all the final (and temporary) binaries created during the build will link against the new Glibc.

중요점: The above patches are critical in ensuring a successful overall build. 그들을 적용시키는 것을 잊지마라.

소스를 풀 디렉토리를 만드세요. 
mkdir -p $LFS/build/gcc-build
cd $LFS/build/gcc-build
tar zxvf /mnt/source/gcc-3.3.2.tar.gz -C ./
GCC 를 build 하기전에, 기본적인 optimization flag 를 override 하는 어떠한 환경변수도 unset 하는 것을 기억하라.

컴파일 준비하기 : 
../gcc-3.3.2/configure --prefix=/tools \
    --with-local-prefix=/tools \
    --enable-clocale=gnu --enable-shared \
    --enable-threads=posix --enable-__cxa_atexit \
    --enable-languages=c,c++

새로운 설정 옵션의 의미:
  • --enable-threads=posix: multi-threaded code위한 handing을 제외한 C++을 가능하게 한다.
  • --enable-__cxa_atexit: 이 옵션은 atexit보다는 __cxa_atexit의 사용을 허락한다, to register C++ destructors for local statics and global objects and is essential for fully standards-compliant handling of destructors. It also affects the C++ ABI and therefore results in C++ shared libraries and C++ programs that are interoperable with other Linux distributions.
  • --enable-clocale=gnu: 이 옵션은 정확한 local model이 모든 상황에서 C++ 라이브러리를 위해 선택되어지도록 한다. 만약 설정 스크립트가 de_DE locale로 인스톨 된 것을 발견했다면, 그것은 gnu의 정확한 모델을 선택할 것이다. 그러나, de_DE locale로 인스톨하지 않았다면, run the risk of building ABI incompatible C++ libraries due to the wrong locale model of generic being selected.
  • --enable-languages=c,c++: 이 옵션은 C와 C++컴파일러 둘다 build되도록 할 때 필요하다.

package 컴파일: 
make

이제 bootstrap target을 사용할 필요가 없다 , as the compiler we're using to compile this GCC was built from the exact same version of the GCC sources we used earlier.

이제 편집이 완전히 끝났습니다다. 전에 말했던 것 처럼, 우리는 이 장에서 임시 tool을 이용하여 테스트하지 않을 것이다. 만약 당신이 여전히 GCC 테스트 하기를 원한다면, 다음 명령과 같이 하라. (거의 한 시간 가까이 소비 되므로 안 하는게 나을 듯 합니다.) 
make -k check

-k 플래그는 첫번째 실패에서 완료되거나 멈추지 않더라도 테스트되도록 한다. GCC 태스트 suite는 매우 포괄적이고 일반적으로 실수가 거의 없도록 한다. 태스트 suite 결과에 대한 요약을 얻기위해, 다음과 같이 하여라: 
../gcc-3.3.2/contrib/test_summary | more

당신은 gcc-testresults mailing list에서 유사한 설정을 당신의 결과와 비교할 수 있다. For an example of howGCC-3.3.2가 어떻게 되어 있는지의 예를 i686-pc-linux-gnu에서 볼 수 있다, http://gcc.gnu.org/ml/gcc-testresults/2004-01/msg00826.html.

결과에 주의를 기울여라:

  • 1 XPASS (unexpected pass) for g++
  • 1 FAIL (unexpected failure) for gcc
  • 24 XPASS's for libstdc++

g++의 pass가 예상되지 않은 결과를 보이는 까닭은 --enable-cxa_atexit를 사용했기 때문이다. 겉으로 보기에 모든 platform이 그들의 C 라이브러리안의 "cxa_atexit"를 제공하는 GCC를 지원하지 않고, 그래서 이 테스트는 항상 예상했던 pass는 아니다.

The 24 unexpected passes for libstdc++ are due to the use of --enable-clocale=gnu, which is the correct choice on Glibc-based systems of versions 2.2.5 and above. The underlying locale support in the GNU C library is superior to that of the otherwise selected "generic" model (which may be applicable if for instance you were using Newlibc, Sun-libc or whatever libc). The libstdc++ test suite is apparently expecting the "generic" model, hence those tests are not always expected to pass.

종종 예상되지 않은 failure를 피할 수 없다. GCC 개발자들은 보통 그것을 알고 있지만, 아직 그들을 고칠 방도를 찾지는 못했다. 한마디로 말해, unless your results are vastly different from those at the above URL, 그것은 계속해서 안전할 것 이다..

그리고 마지막으로 패키지를 인스톨 한다: 
make install

Note: 이때 이 장 전에 우리가 실행했던 sanity check를 반복하는 것이 좋다. Refer back to "Locking in" Glibc and repeat the check. 만약 결과가 잘못된 것이라면, then most likely you forgot to apply the above mentioned GCC Specs patch.

The details on this package are found in the Section called Contents of GCC in Chapter 6.

[edit]

3.16 Binutils-2.14 - Pass 2 설치


Approximate build time: 1.5 SBU Required disk space: 108 MB

Binutils (2.14) 공식 다운로드 사이트: ftp://ftp.gnu.org/gnu/binutils/

Binutils와 의존성 관계에 있는 프로그램들: Bash, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo.

[edit]

3.16.1 Binutils 재설치하기


build 디렉토리 만들기: 
mkdir -p $LFS/build/binutils-build
cd $LFS/build/binutils-build
tar zxvf /mnt/source/binutils-2.14.tar.gz -C ./
Binutils 컴파일 준비하기: 
../binutils-2.14/configure --prefix=/tools \
    --enable-shared --with-lib-path=/tools/lib

configure option의 의미:
  • --with-lib-path=/tools/lib: 이 옵션은 default 라이브러리를 찾는 경로를 지정해 줍니다. 우리는 Binutils를 설치할 때 호스트 시스템에 이미 설치되어있는 라이브러리 디렉토리를 찾는것을 원하지 않습니다.

Binutils build를 시작하기전에 이미 기본으로 최적화되어있는 환경변수를 변경했을 경우 원상복귀 시켜야 합니다.

팩키지 컴파일 하기: 
make

참고로 말하자면, configure를 실행하거나 컴파일을 할 때에는 소스를 풀어 놓은 디렉토리에서 하는 것보다 소스를 풀어 놓은 디렉토리보다 한 단계 상위 디렉토리에서 하는 것이 오류를 줄일수 있는 한 방법입니다. 저 같은 경우엔 binutils를 /mnt/lfs/build/binutils-2.14/에 풀었고 그 디렉토리에서 컴파일을 실행했을 때는 에러가 발생했지만, 상위 디렉토리인 /mnt/lfs/build에서 binutils-2.14/configure 이런식으로 했을 경우에는 별 무리 없이 성공했습니다.(Glibc때도 그랬습니다.)

자, 이제 컴파일이 끝났습니다. 이전에 말한 것처럼 이 장에서 우리는 임시도구들을 위한 test suits들을 실행하는 것을 추천하지 않습니다. 하지만, Binutils test suits를 실행하기를 원한다면, 아래와 같은 명령을 실행하세요. 
make check

예상치 못한 오류가 없었다면, 잘된 것입니다. 불행하게도, Binutils의 경우는 GCC팩키지를 설치할 때처럼 결과를 한번에 보여주는 쉬운 방법이 없습니다. 그러나, 여기서 오류가 발생해도 오류는 쉽게 찾아낼 수 있습니다. 오류메시지는 아래처럼 에러내용을 포함해서 보여줍니다.: 
make[1]: *** [check-binutils] Error 2
자, 그리고 팩키지를 설치합시다: 
make install

다음장에서 Toolchain의 재적용을 위해 Binutils를 준비합니다. 
make -C ld clean
make -C ld LIB_PATH=/usr/lib:/lib

주의

다음 팩키지에서 Binutils source를 사용하므로 Binutils의 소스디렉토리를 아직 지우지 마세요.

패키지에 포함된 프로그램에 대해선 the Section called Contents of Binutils in Chapter 6 를 참조하세요.

[edit]

3.17 Gawk-3.1.3 설치


Approximate build time: 0.2 SBU Required disk space: 17 MB

Gawk-3.1.3 공식 다운로드 사이트: ftp://ftp.gnu.org/pub/gnu/gawk/

Gawk-3.1.3과 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

[edit]

3.17.1 Gawk 설치


Gawk 컴파일 준비하기: 
./configure --prefix=/tools

package 컴파일하기: 
make

자, 이제 컴파일이 끝났습니다. 이전에 말한 것처럼 이 장에서 임시도구들을 위한 test suits들을 실행하는 것을 추천하지 않습니다. 하지만, Gawk test suits를 실행하기를 원한다면, 아래와 같은 명령을 실행하세요: 
make check

설치하기: 
make install

패키지에 포함된 프로그램에 대해선 6장 Gawk의 내용 를 참조하세요. .

[edit]

3.18 Coreutils-5.0 설치


Approximate build time: 0.9 SBU Required disk space: 69 MB

Coreutils-5.0 공식 다운로드 사이트: ftp://ftp.gnu.org/gnu/coreutils/

Coreutils 패치를 받을 수 있는 사이트: http://lfs.osuosl.org/patches/lfs/5.0/

참고. Coreutils-5.0 팩키지에 관한 많은 링크가 끊긴 상태입니다. 5.2를 받아서 하는 것도 좋은 방법이 될 것입니다.

Coreutils와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed.

[edit]

3.18.1 Coreutils 설치


Coreutils has an issue when compiled against Glibc-2.3.3. 패치를 안했을때, Coreutils utilities(head, tail, sort etc)중 일부 프로그램은 지난 30년동안 사용되어왔던 전통적인 문법과 충돌이 생길것입니다. 오래된 syntax들은 Coreutils가 여러장소에서 update될때 없어지지 않고, 새로운 버전에서도 지원이 되어왔습니다. 세부사항들은 패치명령을 보면 알 수 있습니다. Use of this patch is by no means compulsory but opting not to use it means you'll have deal with the consequences yourself, i.e. patch the many software packages that use the old syntax.

패치 적용하기: 
mkdir -p $LFS/build/coreutils_build
cd $LFS/build/coreutils_build
tar zxvf /mnt/source/coreutils-5.2.1.tar.gz -C ./
cd coreutils-5.2.1
patch -Np1 -i /mnt/source/coreutils-5.2.1-hostname-1.patch
patch -Np2 -i /mnt/source/coreutils-5.2.1-uname-1.patch
(전 5.2.1버전을 기준으로 준비했습니다.)

Coreutils 컴파일 준비하기: 
./configure --prefix=/tools

package 컴파일하기: 
make

자, 이제 컴파일이 끝났습니다. 이전에 말한 것처럼 이 장에서 우리는 임시도구들을 위한 test suits들을 실행하는 것을 추천하지 않습니다. 만약에 당신이 정 Coreutils test suits를 실행하기를 원한다면, 아래와 같은 명령을 실행하세요: 
make RUN_EXPENSIVE_TESTS=yes check

make parameter의 의미:
  • RUN_EXPENSIVE_TESTS=yes: This tells the test suite to run several additional tests that are considered relatively expensive on some platforms, 그렇지만 리눅스에서는 문제가 되지 않는다.

팩키지 설치하기: 
make install
패키지에 포함된 프로그램에 대해선 the Section called Contents of Coreutils in Chapter 6 를 참조하세요.

[edit]

3.19 Bzip2-1.0.2 설치


Approximate build time: 0.1 SBU Required disk space: 2.5 MB

Bzip2 (1.0.2) 공식 다운로드 사이트: ftp://sources.redhat.com/pub/bzip2/

GCC와 의존성 관계에 있는 프로그램들 : Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Make.

[edit]

3.19.1 Bzip2 설치


Bzip2팩키지는 configure script가 없습니다. option을 한줄로 써서 컴파일 하고 설치합니다. 
mkdir -p $LFS/build/bzip_build
cd $LFS/build/bzip_build
tar zxvf /mnt/source/bzip2-1.0.2.tar.gz -C ./
cd bzip2-1.0.2
make PREFIX=/tools install
패키지에 포함된 프로그램에 대해선 the Section called Contents of Bzip2 in Chapter 6 를 참조하세요.

[edit]

3.20 Gzip-1.3.5 설치


Approximate build time: 0.1 SBU Required disk space: 2.6 MB

Gzip (1.3.5)공식 다운로드 사이트:
ftp://alpha.gnu.org/gnu/gzip/

Gzip과 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

[edit]

3.20.1 Gzip 설치


Gzip 컴파일 준비하기: 
mkdir -p $LFS/build/gzip_build
cd $LFS/build/gzip_build
tar zxvf /mnt/source/gzip-1.3.5.tar.gz -C ./
cd gzip-1.3.5
./configure --prefix=/tools
package 컴파일하기: 
make

설치하기: 
make install

패키지에 포함된 프로그램에 대해선 the Section called Contents of Gzip in Chapter 6 를 참조하세요.

[edit]

3.21 Diffutils-2.8.1 설치


Approximate build time: 0.1 SBU Required disk space: 7.5 MB

Diffutils (2.8.1)공식 다운로드 사이트:
ftp://ftp.gnu.org/gnu/diffutils/

Diffutils와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.
[edit]

3.21.1 Diffutils 설치


Diffutils 컴파일 준비하기: 
mkdir -p $LFS/build/diffutils_build
cd $LFS/build/diffutils_build
tar zxvf /mnt/source/diffutils-2.8.1.tar.gz -C ./
cd diffutils-2.8.1
./configure --prefix=/tools
package 컴파일하기: 
make

설치하기: 
make install

패키지에 포함된 프로그램에 대해선 the Section called Contents of Diffutils in Chapter 6 를 참조하세요.

[edit]

3.22 Findutils-4.1.20 설치


Approximate build time: 0.2 SBU Required disk space: 7.6 MB

Findutils (4.1.20) 공식 다운로드 사이트: ftp://alpha.gnu.org/gnu/findutils/

Findutils와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

[edit]

3.22.1 Findutils 설치


Findutils 컴파일 준비하기: 
mkdir -p $LFS/build/findutils_build
cd $LFS/build/findutils_build
tar zxvf /mnt/source/findutils-4.1.20.tar.gz -C ./
cd findutils-4.1.20
./configure --prefix=/tools

package 컴파일하기: 
make

자, 이제 컴파일이 끝났습니다. 이전에 말한 것처럼 이 장에서 우리는 임시도구들을 위한 test suits들을 실행하는 것을 추천하지 않습니다. 만약에 정말 Findutils test suits를 실행하기를 원한다면, 아래와 같은 명령을 실행하세요: 
make check

설치하기: 
make install

패키지에 포함된 프로그램에 대해선 the Section called Contents of Findutils in Chapter 6 를 참조하세요.

[edit]

3.23 Make-3.80 설치


Approximate build time: 0.2 SBU Required disk space: 8.8 MB

Make (3.80) 공식 다운로드 사이트: ftp://ftp.gnu.org/gnu/make/

Make와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Sed.

[edit]

3.23.1 Make 설치


Make 컴파일 준비하기: 
mkdir -p $LFS/build/make_build
cd $LFS/build/make_build
tar zxvf /mnt/source/make-3.80.tar.gz -C ./
cd make-3.80
./configure --prefix=/tools
컴파일 하기: 
make

자, 이제 컴파일이 끝났습니다. 이전에 말한 것처럼 이 장에서 우리는 임시도구들을 위한 test suits들을 실행하는 것을 추천하지 않습니다. 만약에 당신이 정말 make test suits를 실행하기를 원한다면, 아래와 같은 명령을 실행하세요: 
make check

이 팩키지의 문서들과 프로그램 설치하기: 
make install

패키지에 포함된 프로그램에 대해선 the Section called Contents of Make in Chapter 6 를 참조하세요.

[edit]

3.24 Grep-2.5.1 설치


Approximate build time: 0.1 SBU Required disk space: 5.8 MB

Grep (2.5.1) 공식 다운로드 사이트: ftp://ftp.gnu.org/gnu/grep/

Grep와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Make, Sed, Texinfo.

[edit]

3.24.1 Grep 설치


Grep 컴파일 준비하기: 
mkdir -p $LFS/build/grep_build
cd $LFS/build/grep_build
tar zxvf /mnt/source/grep-2.5.tar.gz -C ./
cd grep-2.5
./configure --prefix=/tools \
    --disable-perl-regexp --with-included-regex
configure option의 의미:
  • --disable-perl-regexp: 이 옵션은 grep이 기존 호스트(배포판이 설치되어있는)에 설치되어있는 PCRE라이브러리와 링크하지 않도록 지정해줍니다.
  • --with-included-regex: 이 옵션은 grep이 grep에 내장된 표준형식 코드를 사용하는 것을 보장해줍니다. 이 옵션을 사용하지 않으면 Glibc의 코드를 사용하게 되는데 이 코드는 약간의 에러가 있습니다. 그래서 이 옵션을 줘야 합니다.

프로그램 컴파일하기: 
make

자, 이제 컴파일이 끝났습니다. 이전에 말한 것처럼 이 장에서 우리는 임시도구들을 위한 test suits들을 실행하는 것을 추천하지 않습니다. 만약에 당신이 정말 grep test suits를 실행하기를 원한다면, 아래와 같은 명령을 실행하세요: 
make check

이 팩키지의 문서들과 프로그램 설치하기: 
make install

패키지에 포함된 프로그램에 대해선 the Section called Contents of Grep in Chapter 6 를 참조하세요.

[edit]

3.25 Sed-4.0.9 설치


Approximate build time: 0.2 SBU Required disk space: 5.2 MB

Sed (4.0.9) 공식 다운로드 사이트: ftp://ftp.gnu.org/gnu/sed/

Sed와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Texinfo.

[edit]

3.25.1 Sed 설치


Sed 컴파일 준비하기: 
mkdir -p $LFS/build/sed_build
cd $LFS/build/sed_build
tar zxvf /mnt/source/sed-4.0.9.tar.gz -C ./
cd sed-4.0.9
./configure --prefix=/tools

패키지 컴파일하기: 
make

자, 이제 컴파일이 끝났습니다. 이전에 말한 것처럼 이 장에서 우리는 임시도구들을 위한 test suits들을 실행하는 것을 추천하지 않습니다. 만약에 당신이 정말 Sed test suits를 실행하기를 원한다면, 아래와 같은 명령을 실행하세요: 
make check

이 팩키지의 문서들과 프로그램 설치하기: 
make install

패키지에 포함된 프로그램에 대해선 the Section called Contents of Sed in Chapter 6 를 참조하세요.

[edit]

3.26 Gettext-0.14.1 설치


Approximate build time: 7.2 SBU Required disk space: 55 MB

Gettext (0.14.1) 공식 다운로드 사이트: ftp://ftp.gnu.org/gnu/gettext/

Gettext와 의존성 관계에 있는 프로그램들: Bash, Binutils, Bison, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

[edit]

3.26.1 Gettext 설치


Gettext 컴파일 준비하기: 
mkdir -p $LFS/build/gettext_build
cd $LFS/build/gettext_build
tar zxvf /mnt/source/gettext-0.14.1.tar.gz -C ./
cd gettext-0.14.1
./configure --prefix=/tools
컴파일 하기: 
make

자, 이제 컴파일이 끝났습니다. 이전에 말한 것처럼 이 장에서 우리는 임시도구들을 위한 test suits들을 실행하는 것을 추천하지 않습니다. 만약에 당신이 정말 Gettext test suits를 실행하기를 원한다면, 아래와 같은 명령을 실행하세요. 그러나, HOST 시스템의 상태에 따라 Gettext test suite가 실패할 수 있다는 것을 알아야 합니다. 예를 들어, Gettext 가 HOST 시스템에서 JAVA 컴파일러를 찾을 경우가 해당됩니다.(Note : an experimental patch to disable Jave is avillable from the patches project). Test를 할 때 시간이 오래 걸리더라도 너무 나쁘게 생각하지 말고 하길 바랍니다: 
make check

설치하기: 
make install

패키지에 포함된 프로그램에 대해선 the Section called Contents of Gettext in Chapter 6 를 참조하세요.

[edit]

3.27 Ncurses-5.4 설치


Approximate build time: 0.7 SBU Required disk space: 26 MB

Ncurses (5.4) 공식 다운로드 사이트: ftp://ftp.gnu.org/gnu/ncurses/

Ncurses와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

[edit]

3.27.1 Ncurses-5.4 설치


압축 풀기: 
mkdir -p $LFS/build/ncurses_build
cd $LFS/build/ncurses_build
tar zxvf /mnt/source/ncurses-5.4.tar.gz -C ./
Ncurses 컴파일 준비하기 
cd $LFS/build/ncurses_build/ncurses-5.4
./configure --prefix=/tools --with-shared \
    --without-debug --without-ada --enable-overwrite
Configure option의 의미:
  • --without-ada: 이렇게 하면, HOST 시스템에 Ada compiler가 이미 설치되어 있더라도 Ncurses를 컴파일 할 때, Ada bindings을 하지 않게 한다. 일단 우리가 chroot환경변수로 들어 갔을 때 HOST시스템에 설치된 Ada를 사용할 수 없기 때문에 이 옵션은 꼭 주어야 한다.
  • --enable-overwrite: 다른 팩키지들이 Ncurses헤더 파일들을 참조할 수 있도록 /toos/include/ncurses 대신 /tools/include로 설치하도록 지정해 주는 역활을 한다.

프로그램과 라이브러리들을 컴파일하기: 
make

Ncurses문서들과 프로그램들을 설치하기: 
make install

패키지에 포함된 프로그램에 대해선the Section called Contents of Ncurses in Chapter 6 를 참조하세요.

[edit]

3.28 Patch-2.5.4 설치


Approximate build time: 0.1 SBU Required disk space: 1.9 MB

Patch (2.5.4) 공식 다운로드 사이트: ftp://ftp.gnu.org/gnu/patch/

Patch와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

[edit]

3.28.1 Patch 설치


Patch 컴파일 준비하기: 
mkdir -p $LFS/build/patch_build
cd $LFS/build/patch_build
tar zxvf /mnt/source/patch-2.5.4.tar.gz -C ./
cd patch-2.5.4
CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools

전처리기 flag -D_GNU_SOURCE 는 Power PC 에서만 필요로 합니다. 다른 시스템에서는 필요없습니다.

컴파일하기: 
make

Patch 문서들과 프로그램들을 설치하기: 
make install

패키지에 포함된 프로그램에 대해선 the Section called Contents of Patch in Chapter 6 를 참조하세요.

[edit]

3.29 Tar-1.13.25 설치


Approximate build time: 0.2 SBU Required disk space: 10 MB

Tar (1.13.25) 공식 다운로드 사이트: ftp://alpha.gnu.org/gnu/tar/

Tar와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

[edit]

3.29.1 Tar 설치


Tar 컴파일 준비하기: 
mkdir -p $LFS/build/tar_build
cd $LFS/build/tar_build
tar zxvf /mnt/source/tar-1.13.25.tar.gz -C ./
cd tar-1.13.25
./configure --prefix=/tools
컴파일하기: 
make
자, 이제 컴파일이 끝났습니다. 이전에 말한 것처럼 이 장에서 우리는 임시도구들을 위한 test suits들을 실행하는 것을 추천하지 않습니다. 만약에 당신이 정말 Texinfo test suits를 실행하기를 원한다면, 아래와 같은 명령을 실행하세요: 
make check

Tar 문서들과 프로그램들을 설치하기: 
make install

패키지에 포함된 프로그램에 대해선 the Section called Contents of Tar in Chapter 6 를 참조하세요

[edit]

3.30 Texinfo-4.6 설치


Approximate build time: 0.2 SBU Required disk space: 16 MB

Texinfo (4.6) 공식 다운로드 사이트: ftp://ftp.gnu.org/gnu/texinfo/

Texinfo와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses, Sed.

[edit]

3.30.1 Texinfo 설치


Texinfo 컴파일 준비하기 : 
mkdir -p $LFS/build/texinfo_build
cd $LFS/build/texinfo_build
tar zxvf /mnt/soruce/texinfo-4.6.tar.gz -C ./
cd texinfo-4.6
./configure --prefix=/tools
컴파일 하기: 
make

자, 이제 컴파일이 끝났습니다. 이전에 말한 것처럼 이 장에서 우리는 임시도구들을 위한 test suits들을 실행하는 것을 추천하지 않습니다. 만약에 당신이 정말 Texinfo test suits를 실행하기를 원한다면, 아래와 같은 명령을 실행하세요: 
make check

Texinfo 문서들과 프로그램들을 설치하기: 
make install

패키지에 포함된 프로그램에 대해선 the Section called Contents of Texinfo in Chapter 6 를 참조하세요

[edit]

3.31 Bash-2.05b 설치


Approximate build time: 1.2 SBU Required disk space: 27 MB

Bash (2.05b)) 공식 다운로드 사이트: ftp://ftp.gnu.org/gnu/bash/


Bash와 의존성 관계에 있는 프로그램들: Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Ncurses, Sed.

[edit]

3.31.1 Bash 설치


압축풀기 
mkdir -p $LFS/build/bash_build
cd $LFS/build/bash_build
tar zxvf /mnt/source/bash-2.05b.tar.gz -C ./

Bash 는 몇가지 버그들이 존재합니다. 이 버그들을 고치기 위해서 다음과 같은 패치를 하세요: 
cd bash-2.05b
patch -Np1 -i ../bash-2.05b-2.patch
Bash 컴파일 준비하기: 
cd $LFS/build/bash_build/bash-2.05b
./configure --prefix=/tools
컴파일 하기: 
make

자, 이제 컴파일이 끝났습니다. 이전에 말한 것처럼 이 장에서 우리는 임시도구들을 위한 test suits들을 실행하는 것을 추천하지 않습니다. 만약에 당신이 정말 Bash test suits를 실행하기를 원한다면, 아래와 같은 명령을 실행하세요: 
make tests

Bash의 문서들과 프로그램 설치하기: 
make install

심볼릭 링크를 만들어 준다: 
ln -s bash /tools/bin/sh

패키지에 포함된 프로그램에 대해선 the Section called Contents of Bash in Chapter 6 를 참조하세요.

[edit]

3.32 Util-linux-2.12 설치


Approximate build time: 0.1 SBU Required disk space: 8 MB

Util-linux (2.12) 공식 다운로드 사이트: http://ftp.cwi.nl/aeb/util-linux/

Util-linux와 의존성 관계에 있는 프로그램들: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses, Sed, Zlib.

[