부록 C 라이브러리 유지보수

• C.1 어떻게 GNU C 라이브러리를 인스톨할것인가?
• C.2 버그들을 보고하기
• C.3 새로운 함수들을 더하기
• C.4 GNU C Library 포팅하기
• C.5 GNU C 라이브러리의 공헌자

C. 1 어떻게 GNU C 라이브러리를 인스톨할 것인가?

GNU C 라이브러리의 인스톨은 비교적 간단하다. 인스톨하려면 최근 버전의 GNU make가 필요하다. 다른 make 프로그램을 사용해서 GNU C 라이브러리를 갱신하는 것은 실로 어렵고 우리는 대신에 GNU make를 사용할 것을 권장한다.

당신의 시스템에 맞는 GNU C 라이브러리를 형성하기 위해서는, 쉘 스크립트 `configure' 와 함께 sh를 실행하라. 당신의 시스템 구성을 위한 관습적인 GNU 이름을 인수로 사용하라_예를 들어, `sparc-sun-sunos4. 1'은 Sunos 4. 1이 실행되는 Sun 4를 위한 것이다. 표준 GNU 구성 이름들의 완전한 명세를 보려면, GNU CC 사용과 포팅에 있는 "GNU CC 인스톨하기" 절을 참조하라. 만일 당신이 구성이름을 빠트리면, `configure'는 실행중인 시스템을 점검함으로써 짐작하려고 시도할 것이다. 짐작을 할 수 있거나, 없거나, 아니면 짐작이 틀리거나 할 것이다. `configure'는 진행하기 전에 선택된 구성의 정규이름을 알릴 것이다.

GNU C 라이브러리는 다음 패턴들과 맞는 구성을 지원하고 있다.

• alpha-dec-osf1
• i386-anything-bsd4. 3
• i386-anything-gnu
• i386-anything-sco3. 2
• i386-anything-sco3. 2v4
• i386-anything-sysv
• i386-anything-sysv4
• i386-sequent-bsd
• m68k-hp-bsd4. 3
• m68k-sony-newsos
• m68k-sun-sunos4. n
• mips-dec-ultrix4. n
• sparc-sun-solaris2. n
• sparc-sun-sunos4. n

 지원되지 않은 구성들에서, 그들 몇 개를 위한 다른 이름을 편리하게 지원한다. (그들은 물론 다른 GNU 소프트웨어에서 동작한다. )

• decstation
• hp320-bsd4. 3 hp300bsd
• i386-sco
• i386-sco3. 2v4
• i386-sequent-dynix
• i386-svr4
• news
• sun3-sunos4. n sun3
• sun4-solaris2. n sun4-sunos5. n
• sun4-sunos4. n sun4

다음은 configure를 실행시킬 때 당신이 지정할 수 있는 몇 개의 옵션이다.

`--with-gnu-ld'

만일 당신이 GNU C 라이브러리와 프로그램을 링크하기 위해서 GNU ld를 사용할 계획이라면 이 옵션을 사용하라. (우리는 강력하게 당신이 이것을 하도록 권장한다. )

`--with-gnu-as'

만일 당신이 GNU C 라이브러리를 만들 때, GNU 어셈블러 gas를 사용하려면 이 옵션을 사용하라. 어떤 시스템에서, 만일 당신이 gas를 사용하지 않는다면 그 라이브러리가 적당하게 만들어지지 않을 것이다.

`--nfp'

만일 당신의 컴퓨터가 하드웨어에서 플로팅 포인트를 지원하는 것이 부족하다면 이 옵션을 사용하라.

`--prefix=directory '

`directory'의 서브디렉토리들 안에 기계-독립적인 데이터 파일들을 인스톨하라. ( 당신은 또한 `configparms'로 이것을 설정할 수 있다; 밑을 보라. )

`--exec-prefix=directory '

`directory'의 서브디렉토리들 안에 라이브러리와 기계-독립적인 파일들을 인스톨하라. (당신은 또한 `configparms' 를 사용해서 이것을 설정할 수 있다; 밑을 보라. )

configure를 실행하기 위한 가장 간단한 방법은 라이브러리 소스가 포함된 디렉토리에서 그것을 실행하는 것이다. 이것은 그 디렉토리 안에 라이브러리를 만들기 위해 준비한다.

당신은 configure를 실행하여 다른 디렉토리로 가서 그 다른 디렉토리에 라이브러리를 만들기 위한 준비를 할 수 있다.

mkdir . . /hp320

cd . . /hp320

. . /src/configure hp320-bsd4. 3

configure는 당신이 정한 디렉토리가 무엇이던지 configure 그 자체를 찾기 위해서 소스들을 찾는다. 파일 시스템 안의 어디에 소스와 디렉토리들이 있는지에 상관없이 당신이 configure를 실행할 때 소스디렉토리를 정해주기만 하면, 당신은 적당한 결과를 얻을 수 있을 것이다.

이 기능은 다른 디렉토리에 소스와 바이너리 파일들을 달리 관리할 수 있고, 같은 소스를 가지고 여러 개의 다른 기계를 위한 라이브러리를 만들기 쉽게 한다. 각 목표 기계를 위한 라이브러리가 들어갈 디렉토리를 만들고, 그 디렉토리에서 목표 기계의 구성 이름을 정해서 configure를 실행하라.

라이브러리는 특정한-목적의 구성 파라미터들을 위한 수를 가지고 있다. 그들은 `Makeconfig' 파일에 정의되어 있다; 자세한 것은 파일 안에 있는 설명을 참조하라. 그러나 당신이 `Makeconfig'파일을 편집해서는 안되고_대신에 당신이 라이브러리를 만들어놓은 디렉토리 안에 `configparms'라는 파일을 만들고, 당신이 지정하기를 원하는 파라미터들을 그 파일에 정의해놓으면 된다. `configparms'는 `Makeconfig'의 편집된 복사본이 되어서는 안된다; 오직 당신이 무시하기를 원하는 파라미터들만 지정하라.

특정 기계-의존적인 코드를 위해서는 GNU C 컴파일러에 있는 확장들을 사용하라, 그러므로 당신은 GCC로 라이브러리를 컴파일할 필요가 있을 것이다. (실제로, 현존하는 완전한 포트들은 모두 GCC를 필요로 한다. ) C 라이브러리의 현재 배포본은 컴파일러가 일반적으로 제공하는 헤더파일들을 포함하고 있다: `stddef. h', `stdarg. h' 그리고 `va-machine. h' 형식의 이름들을 가진 여러개의 파일들. GCC의 오래된 배포본으로 부터 온 그 파일의 다른 버전은 GNU C 라이브러리에서 올바르게 작동하지 않는다.

배포본 2. 2. 에 있는 `stddef. h' 파일과 GCC의 최근 것은 올바르게 작동한다. 만일 당신이 배포본 2. 2. 또는 최근의 GCC를 가지고 있다면, C 라이브러리에 있는 것 대신에 그 버전의 `stddef. h'의 파일을 사용하라. 그렇게 하려면, `configparms' 안에 `override stddef. h = '줄을 넣어라. 다른 파일들은 배포본 2. 3과 최근의 GCC에서 수정되었다. `configure'는 C 라이브러리와 호환성이 있는 인스톨되어 있는 `stdarg. h'와 `va-machine. h' 파일들을 검색하고 만일 그것들이 없다면 자신의 것을 사용한다.

배포본 2. 4의 이전에 있었던 GCC와 size_t 형은 문제를 포함하고 있다. ANSI C 는 size_t가 항상 unisgned 형이 될 것을 요구한다. 현존하는 시스템 헤더파일들과의 호환성을 위해서, GCC는 `sys/types. h'가 그것을 무엇으로 정의했는지에 따라서 `stddef. h'에 size_t를 정의한다. 대부분의 유닉스 시스템들은 `sys/types. h'에 size_t를 정의하고, signed 형이 되도록 한다. size_t가 unisgned 형으로 되어있는 것에 의존하는 라이브러리 안에 있는 어떤 코드들은, 만일 그것이 signed가 된다면 올바르게 동작하지 않을 것이다.

size_t가 unsigned로 예상되는 GNU C 라이브러코드는 올바르다. signed 형인 size_t 정의는 올바르지 않다. 버전 2. 4 와 최근의 GCC는 size_t를 항상 unsiged형으로 정의하고, GCC의 `fixincludes' 스크립트 메시지는 시스템의 `sys/types. h'의 비위를 맞추기 때문에 그것과 충돌하지 않는다. 그 동안, 우리는 GNU C 라이브러리를 컴파일할 때 size_t의 타입으로 unsigned 형을 사용할 것이라고 명백하게 GCC에게 알림으로써 작업한다. `configure'는 만일 필요하다면 size_t를 위해서 GCC가 무슨 형을 사용할 것인지 자동적으로 검출할 것이다.

라이브러리를 만들기 위해서, make lib를 입력하라. 이것은 make로부터 에러처럼 보이는 많은 양의 출력을 만들 것이다(에러는 아니다). make로부터 나온 에러메시지에서 `***'가 포함된 것을 찾아봐라. 그들 중 어떤 것은 실제로 에러메시지일 있다. 라이브러리의 기능들을 시험하기 위해서 어떤 테스트 프로그램을 만들고 실행하려면, make tests를 입력하라. 이것은 `program. out'과 같은 이름으로 여러개의 파일들을 만들 것이다.

GNU C 라이브러리 레퍼런스 매뉴얼을 프린팅하기 위한 형식으로 만들려면, make dvi를 입력하라. make info를 입력하면, Emacs 나 info 프로그램에서 C-h i로 라인을 읽을 수 있는 매뉴얼 형식으로 만들어준다.

라이브러리와 그 헤더파일들을 인스톨하고, info 프로그램을 위한 매뉴얼 형식을 만들려면, `configparms'에서 인스톨 디렉토리들을 설정한 후에, make install을 입력하라. 이것은 그들을 인스톨하기 전에 필요한 것들을 만들 것이다.

C. 2 버그들을 보고하기

GNU C 라이브러리 안에는 아마도 버그들이 있고, 이 매뉴얼 안에도 잘못된 점과 생략된 것이 있을 것이다. 만일 당신이 그들을 보고한다면, 그들은 고쳐질 것이다. 당신이 그렇게 하지않는다면, 아무도 그들에 대해서 알지 못할 것이고 그들은 영원토록 틀린 상태로 있게 될 것이다.

버그를 보고하기 위해서, 첫째로 당신은 그것을 발견해야만 한다. 다행스럽게도 버그를 발견하는 것은 쉬운 일이 아닐 것이다. 일단 당신이 버그를 발견했다면, 그것이 실제로 버그인지를 확실히 밝혀라. 이것을 알아내기 위한 좋은 방법은 다른 C 라이브러리에 있는 같은 기능을 동작시켜보고 GNU C 라이브러리의 것과 비교해보는 것이다. 그들이 같은 동작을 하면, 아마도 당신이 틀리고 라이브러리가 맞을 것이다. 만일 그렇지 않다면, 라이브러리 중에 하나가 틀린 것이다.

그런 과정을 통해서 일단 당신이 발견한 것이 버그임이 확실해지면, 그 문제를 일으키는 경우의 범위를 좁히도록 시도하라. C 라이브러리의 경우에, 만일 가능하다면, 당신은 실제로 한 개의 라이브러리 함수 호출로 그 범위를 좁힐 필요가 있다. 이것이 그리 어렵지는 않을 것이다.

당신이 할 수 있는 가장 간단한 테스트 케이스(case)를 가질 때 마지막 단계로써 버그를 보고하다. 버그를 보고할 때, 당신의 시스템 타입과, 당신이 사용하는 GNU C 라이브러리 버전, 그리고 당신이 생각하는 문제는 무엇인지, 테스트 프로그램을 통해서 당신이 예상했던 결과와, 그리고 당신이 얻었던 결과를 테스트 프로그램과 함께 보내라. 또한 `configure'를 실행함으로써 만들어지는 `config. status'와 `config. make' 파일들도 같이 보내라; 그들은 당신이 현재 무슨 디렉토리에서 `configure'를 실행시켰는지에 대한 것이다.

만일 당신이 ANSI 와 POSIX 표준들 (1. 2절 [Standards and Portability] 참조. )을 따르지 않는 GNU C 라이브러리에 있는 어떤 것을 발견했다면, 그것은 명확히 버그이다. 그것을 보고하라! 버그 보고서를 보낼 인터넷 주소는 `bug-glibc@prep. ai. mit. edu' 또는 UUCP 경로 `mit-eddie!prep. ai. mit. edu!bug-glibc'이다. 만일 당신이 인스톨과정이나 사용하는데 다른 문제들을 발견하게 된다면, 그것 또한 보고하라.

만일 당신이 어떤 함수가 어떻게 동작하는지 확실히 알 수 없고, 이 매뉴얼이 그것에 대해서 말하지 않는다면 이 매뉴얼에 문제가 있는 것이다. 그것 또한 보고하라! 만일 함수의 동작이 매뉴얼과 다르다면, 라이브러리나 매뉴얼 중에 하나가 문제가 있는 것이므로 그것을 보고하라. 만일 당신이 매뉴얼에서 잘못된 점이나 생략된 것을 발견했다면 다음 인터넷주소로 그들을 보고해달라.

'bug-glibc-manual@prep. ai. mit. edu' or UUCP 경로 'mit-eddie!prep. ai. mit. edu!bug-glibc-manual'

C. 3 새로운 함수들을 더하기

라이브러리를 설치하는(build) 프로세스는 GNU make의 특별한 기능들을 어렵게 사용해서 만드는 Makefile들(makefiles)에 의해 조종된다. Makefile들은 매우 복잡하고, 당신은 아마도 그것을 이해하려 시도하기를 원하지 않을 것이다. 그러나 그들이 하는 일은 굉장히 간단한 것으로, 당신이 올바른 위치에 정의한 몇 개의 변수들만을 요구한다.

라이브러리소스는 주제(topic)에 따라서, 서브디렉토리로 나누어서 묶여져 있다. `string'서브디렉토리는 모든 문자열-처리 함수들을 가지고 있고, `stdio'는 모든 표준 I/O 함수들을 가진다.

각 서브디렉토리는 `Makefile'라고 불리는 간단한 Makefile을 가지고 있는데, 그 파일은 몇 개의 메이크 변수들을 정의하고 전역 Makefile `Rules'를 다음 라인과 함께 포함하고 있다.

include . . /Rules

서브디렉토리 Makefile을 정의하는 기본 변수들은 다음과 같다:

subdir

`stdio'와 같은 서브디렉토리의 이름. 이 변수는 반드시 정의되어야만 한다.

headers

`stdio. h'처럼, 라이브러리의 한 부분을 이루는 헤더파일의 이름.

routines, aux

라이브러리의 한 부분을 이루는 모듈들의 이름(소스 파일들) 그들은 `strlen'과 같은 간단한 이름이다 ( `strlen. c'와 같은 파일 이름보다는 간단하다는 말). 라이브러리 안에 함수를 정의하는 모듈들을 위해서 routines를 사용하고, 데이터 정의와 같은 것들을 포함하고 있는 보조 모듈들을 위해서는 aux를 사용하라. 그러나 routines 와 aux의 값들은 단지 연결된 것이고, 실제로 아무런 실제적인 차이는 없다.

tests

라이브러리를 구성하고 있는 테스트 프로그램의 이름. 그들은 `tester'와 같은 간단한 이름이다 ( `tester. c'와 같은 완전한 파일 이름보다는 짧다는 말. ) `make tests'는 테스트 프로그램을 설치하고 실행할 것이다. 만일 입력을 필요로 하는 테스트 프로그램이라면, `test-program. input' 이라 불리는 파일 안에 테스트 데이터 입력하라; 그것은 표준 입력상에서 테스트 프로그램으로 입력될 것이다. 만일 테스트 프로그램에 인수를 넣어서 실행하길 원한다면, `test-program. args'라고 불리는 파일 안에 인수들(단일한 라인으로)을 넣어라.

others

라이브러리를 구성부분과 연관된 "others" 프로그램들의 이름들이다. 그들은 se에 대하여 테스트가 없는 프로그램들이지만, 라이브러리와 함께 포함된 작은 프로그램을 말한다. 그들은 `make others'에 의해서 만들어진다.

install-lib, install-data, install

`make install'에 의해 인스톨되는 파일들. `install-lib' 안에 목록이 있는 파일들은 `configparms' 또는 `Makeconfig' (C. 1절 [Installation] 참조. ) 안에 `libdir'에 의해 정해진 디렉토리 안에 인스톨된다. install-data 안에 목록이 있는 파일들은 `configparms' 또는 `Makeconfig' 에 있는 `datadir'에 의해 정해진 디렉토리 안에 인스톨된다. install안에 목록이 있는 파일들은 `configparms' 또는 `Makeconfig' 안에 있는 `bindir' 에 의해서 정해진 디렉토리 안에 인스톨된다.

distribute

결점이 있는 파일 안에 넣게될 서브디렉토리에 있는 파일들. 당신은 Makefile 자체나 소스 그리고 다른 표준 변수들로 등록된 헤더파일들은 이곳에 넣을 수 없다. 오직 비정상적인 방법으로 사용되는 파일들만 이곳에 정의된다.

generated

이 서브디렉토리 안에서 `Makefile'에 의해 발생되는 파일들. 그 파일들은 `make clean'에 의해서 제거되고, 그들은 결코 비정상적인 파일 안에 들어갈 수 없다.

extra-objs

이 서브디렉토리 안에서 `Makefile'에 의해서 만들어지는 여분의 오브젝트 파일들. 이것은 `foo. o'와 같은 파일이름의 리스트가 될 것이다; 그 파일들은 오브젝트 파일들이 만들어진 디렉토리 어느 곳에서나 발견될 것이다. 그 파일들은 `make clean' 에 의해서 제거될 것이다. 이 변수는 others 나 tests 를 만들기 위해서 필요한 부차적인 오브젝트 파일들을 위해서 사용된다.

C. 4 GNU C Library 포팅하기

GNU C 라이브러리는 다양한 기계들과 운영체제들에 쉽게 이식될 수 있도록 만들어졌다. 기계와 운영체제에 의존적인 함수들은 새로운 기계나 운영체제를 위해서 기능을 더하기 쉽게 만들도록 잘 분리되었다. 이 절은 라이브러리 소스 트리(tree)의 배치를 설명하고 기계 의존적인 코드를 선택하기 위해서 사용되는 메커니즘에 대해서 설명하고 있다.

라이브러리 안에 있는 모든 기계-와 운영체제-의존적인 파일들은 최고-단계의 라이브러리 소스 디렉토리 밑에 `sysdeps'라는 서브디렉토리에 있다. 이 디렉토리는 계층적인 서브디렉토리들로 구성되어 있다. (C. 4. 1절 [Hierarchy Conventions] 참조. )

`sysdeps'의 각 서브디렉토리는 특정한 기계나 운영체제, 또는 기계나 운영체제의 부류(예를 들어, 특정한 공급자에 의한 시스템이나, IEEE 754 플로팅-포인트 형식을 사용하는 모든 기계들)를 위한 소스 파일들을 포함하고 있다. 구성도는 그 서브디렉토리들의 순서 리스트를 정한다. 각 서브디렉토리들은 리스트에서 부모 디렉토리 밑에 붙여진다. 예를 들어, `unix/bsd/vax'라고 정해진 리스트는 `unix/bsd/vax unix/bsd unix' 리스트와 동일하다.

서브디렉토리는 디렉토리 계층도에서 직접적으로 위에 없는 다른 서브디렉토리들을 내포하도록 정할 수 있다. 만일 `Implies'파일이 서브디렉토리 안에 존재한다면, `sysdeps'의 다른 서브디렉토리들의 리스트들은 `Implies' 파일이 포함된 서브디렉토리의 리스트를 만든 후에, 그 리스트에 덧붙인다. `#' 문자로 시작하는 `Implies'파일 안에 문자는 주석문으로 무시된다. 예를 들어, `unix/bsd/Implies' 는 다음을 포함한다:

# BSD has Internet-related things.

unix/inet

그리고 `unix/Implies'는 다음을 포함한다:

posix

그래서 최종적인 리스트는 `unix/bsd/vax unix/bsd unix/inet unix posix'가 된다.

`sysdeps'는 두 개의 "특별한" 서브디렉토리를 가지는데, 그것은 `generic' 과 `stub'이다. 그 두 개는 서브디렉토리들의 리스트에 항상 명확히 덧붙여지므로, 당신이 `Implies' 파일 안에 그들을 넣을 필요가 없고, 당신이 그 디렉토리 밑에 다른 서브디렉토리를 만들어서는 안된다. `generic'은 다른 C 라이브러리에 있는 기계-독립 함수들을 사용하여, 기계-독립 C에서 구현될 수 있는 것들을 위한 것이다. `stub'는 특정한 기계나 운영체제에서 이행될 수 없는 함수들의 토막 버전들이다. 그 토막 함수들은 항상 에러를 리턴하고, errno를 ENOSYS로 설정한다(함수가 이행되지 않는다. ). 2장 [Error Reporting] 참조.

소스 파일은 `generic'나 `stub'에 소스 파일의 개정판(version)을 가짐으로써 시스템-독립적이 되도록 알려진다; 모든 시스템-독립 함수는 generic이나 stub의 기능중 하나를 가져야 한다 ( 그 둘을 모두 가져도 아무런 문제가 없다. )

만일 당신이 메인 소스 디렉토리(main source directories)들 중의 하나에 있는 어떤 파일에 대해서, 그것을 기계- 또는 운영체제-독립적으로 만들기를 원한다면, 그 파일을 `sysdeps/generic'으로 옮기고 적당한 시스템-지정 서브디렉토리에 있는 새로운 함수를 사용해서 파일을 수정하라. 만일 어떤 파일이 시스템-독립적이 되었다면 그것을 기록해서, 그것이 메인 소스 디렉토리들 중의 어떤 것에도 나타나서는 안된다.

다음은 `sysdeps'의 각 서브디렉토리에 존재할 수 있는 몇 개의 특별한 파일들이다.

`Makefile'

기계나 운영체제, 또는 기계나 운영체제의 부류를 위한 Makefile. 이 파일은 최고단계에 있는 Makefile과 서브디렉토리에 있는 Makefile들에 의해서 사용되는 라이브러리 Makefile `Makerules'에 의해서 인클루드된다. 포함된 Makefile의 변수 설정을 변경하거나 새로운 규칙 을 더할 수 있다. 라이브러리의 다른 부분을 위해서 변수들과 규칙들의 다른 설정을 선택하려면 (위를 보라) 변수 `subdir'에 기초한 조건적인 지시로 GNU make를 사용할 수 있다. 그것은 또한 라이브러리에 포함될 여분의 모듈들을 정하기 위해서 make 변수 `sysdep-routines'를 설정할 수 있다. 당신은 `routines'가 메인 소스 트리(main source tree) 각 서브디렉토리에 무엇을 공급할 것인지를 결정하는데 사용되기 때문에 `routines'에 모듈들을 더하기보다는 `sysdep-routines'를 사용할 것이다.

찾기 쉽도록 서브디렉토리들을 순서대로 리스트를 만든 서브디렉토리 안의 각 Makefile은 순서대로 인클루드된다. 여러 시스템-의존 Makefile들이 인클루드되면, 각각은 그것을 간단히 설정하기보다는 `sysdep-routines'에 덧붙여 질 것이다:

sysdep-routines : = $(sysdep-routines) foobar

`Subdirs'

이 파일은 이 시스템을 위해 인클루드되어질 최고-단계의 라이브러리 소스 트리밑에 있는 전체의 서브디렉토리들에 에 대한 이름들을 갖고 있다. 그 서브디렉토리들은 `stdio' 와 `math'처럼, 라이브러리 소스 트리안에 있는 시스템-독립 서브디렉토리들처럼 취급된다.

`sysdeps'

도구들의 이 서브디렉토리 시스템을 위한 라이브러리 안에 넣을 함수들과 헤더파일들을 완전히 새롭게 설정하고자 할 때 이것을 사용하라. 예를 들어, `sysdeps/unix/inet/Subdirs'는 `inet'를 포함한다; `inet' 디렉토리는 인터넷을 지원하는 시스템상에서 라이브러리에 넣을만한 다양한 네트웍-지향 명령들을 포함한다.

`Dist'

이 파일은 distribution 안에 포함될 파일들( 그것이 있는 `sysdeps'의 서브디렉토리에 관한)의 이름을 포함한다. 같은 디렉토리의 `Makefile'에 있는 규칙들에 의해 쓰여지는 새로운 파일들이나, 또는 그 디렉토리의 소스 파일들에 의해서 사용되는 헤더파일들에 대한 목록이다. 당신은 메인 소스 트리에 있는 기계-독립 Makefile들에서 이름이 부여된 routines의 구현인 파일들을 목록화할 필요가 없다.

`configure'

이 파일은 구성시(configuration time)에 실행되는 쉘 스크립트 부속이다. `configure' 스크립트는 순서대로, 선택된 각 시스템-의존 디렉토리에서 `configure' 파일을 읽기 위해서 shell . command를 사용한다. `configure' 파일들은 Autoconf를 사용하는 파일들 `configure. in'로부터 발생 된다.

시스템-의존적 `configure' 스크립트는 쉘 변수 `DEFS'와 `config_vars'에 더할 것이다; 자세한 것은 최고-수준 `configure' 스크립트를 참조하라. 그 스크립트는 최고-수준 `configure'에 넣을 `--with-package' 옵션들을 위해서 체크 할 수 있다. `--with-package=value' 옵션에서, `configure' 는 값으로 쉘 변수 `with_package'(package안의 대쉬는 언더스코어로 변환된다)를 설정한다; 만일 옵션이 단지 `--with-package'로 되어있다면(인수가 없이), 그것은 `yes'로 `with_package'를 설정한다.

`configure. in'

이 파일은 서브디렉토리의 `configure'파일 안에서 처리되기 위한 Autoconf 입력 부분이다. Autoconf안에 있는 "Introduction"을 참조하라: Autoconf의 명세는 Generating Automatic Configuration Scripts. 당신은 `configure' 또는 `configure. in'을 사용할 수 있지만, 그 둘을 함께 사용해서는 안된다. `configure. in'의 첫 번째 줄은 m4 macro인 `GLIBC_PROVIDES'를 호출하여야한다. 이 매크로는 최고-수준 `configure' 스크립트에서 사용되는 Autoconf 매크로들을 위해서 여러 `AC_PROVIDE'를 호출한다; 이것이 없이는, 그 매크로들은 Autoconf에 의해서 쓸모 없이 다시 호출될 것이다.

그것은 어떻게 시스템-의존적인 것들을 고립시킬 것인지에 대한 일반적인 시스템이다. 다음절은 `sysdeps'에 무슨 디렉토리를 사용할 것인지를 어떻게 결정하는지 설명한다. 다양한 유닉스 시스템에 따라서 라이브러리를 포팅(porting)하는 팁에 대한 정보는 C. 4. 2절 [Porting to Unix] 를 참조하라.

C. 4. 1 `sysdeps' 디렉토리 계층의 배치

GNU 구성 이름은 세부분으로 되어있다: CPU 타입, 제작자의 이름, 그리고 운영체제. `configure'는 시스템-의존 디렉토리들의 리스트를 고르기 위해서 그들을 살펴보는데 사용한다. 만일 `--nfp' 옵션이 `configure'에 주어지지 않았다면, `machine/fpu' 디렉토리가 또한 사용된다.

운영체제는 기본 운영 체제를 갖는다; 예를 들면 만일 운영체제가 `sunos4. 1' 이라면, 기본 운영체제는 `unix/bsd'가 된다. 디렉토리의 리스트를 고르는데 사용되는 알고리즘은 간단하다: `configure'는 기본 운영체제, 제작자, CPU 그리고 운영체제의 리스트를 순서대로 만든다. 그것은 디렉토리 이름을 만들어서, 서로 슬래쉬로 구분되어 연결되어 있다: 예를 들면, `sparc-sun-sunos4. 1'은 `unix/bsd/sun/sparc/sunos4. 1'에 있다. `configure' 는 리스트의 각 요소를 제거하려 시도하는데, `unix/bsd/sparc' 와 `sun/sparc' 또한 다른 것 사이에서, 시도된다. 운영체제의 정밀한 버전 번호는 그다지 중요하지 않고, 그것은 매우 불편하다. 예를 들어, `sunos4. 1. 1'와 `sunos4. 1. 2' 디렉토리를 구분하는 것은 불편하기 때문에 `configure'는 점(period)으로 시작되는 접미사를 제거함으로써 덜 결정적인 운영 시스템 이름들을 시도한다.

예를 들어, `sparc-sun-sunos4. 1' 구성을 위해서 시도됐던 디렉토리들의 완전한 리스트가 있다.  

• sparc/fpu
• unix/bsd/sun/sunos4. 1/sparc
• unix/bsd/sun/sunos4. 1
• unix/bsd/sun/sunos4/sparc
• unix/bsd/sun/sunos4
• unix/bsd/sun/sunos/sparc
• unix/bsd/sun/sunos
• unix/bsd/sun/sparc
• unix/bsd/sun
• unix/bsd/sunos4. 1/sparc
• unix/bsd/sunos4. 1
• unix/bsd/sunos4/sparc
• unix/bsd/sunos4
• unix/bsd/sunos/sparc
• unix/bsd/sunos
• unix/bsd/sparc
• unix/bsd
• unix/sun/sunos4. 1/sparc
• unix/sun/sunos4. 1
• unix/sun/sunos4/sparc
• unix/sun/sunos4
• unix/sun/sunos/sparc
• unix/sun/sunos
• unix/sun/sparc
• unix/sun
• unix/sunos4. 1/sparc
• unix/sunos4. 1
• unix/sunos4/sparc
• unix/sunos4
• unix/sunos/sparc
• unix/sunos
• unix/sparc
• unix
• sun/sunos4. 1/sparc
• sun/sunos4. 1
• sun/sunos4/sparc
• sun/sunos4
• sun/sunos/sparc
• sun/sunos
• sun/sparc
• sun
• sunos4. 1/sparc
• sunos4. 1
• sunos4/sparc
• sunos4
• sunos/sparc
• sunos
• sparc

다른 기계 구조들은 관습적으로 `sysdeps' 디렉토리 트리의 최고수준에 존재한다. 예를 들어, `sysdeps/sparc'와 `sysdeps/m68k'. 그들은 기계 구조에 대한 파일 명세를 포함하지만, 어느 특정 운영체제에 대한 명세는 아니다. `sysdeps/m68k/s8020' 처럼, 그 구조들의 한정을 위한 서브디렉토리들이 될 것이다. 특별한 기계에서 사용되는 플로팅-포인트 코프로세서에 대한 명세 코드는 `sysdeps/machin/fpu'에 들어가야 한다.

다음은 특정한 기계 구성들을 위한 것이 아닌 `sysdeps' 계층의 최고단계에 있는 몇 개의 디렉토리에 관한 것이다.

`generic', `stub'

위에 설명된 것처럼 (C. 4절 [Proting] 참조. ), 모든 구성들이 다른 것들 후에 사용하는 두 개의 서브디렉토리들이 있다.

`ieee754'

이것은 C 타입 float가 IEEE 754 단정도 형식과, double가 IEEE 754 배정도 형식인 곳에서, 사용되는 IEEE 754 플로팅-포인트 형식 코드를 위한 디렉토리이다. 보통 이 디렉토리는 `m68k/Implies'와 같은, 기계 구조-명세 디렉토리에 있는 `Implies'파일에서 참조된다.

`posix'

이 디렉토리는 POSIX. 1 함수들을 위해서 라이브러리를 구현해 놓은 것들을 포함한다. 이것은 POSIX. 1 함수들 중 어떤 것을 포함한다. 물론, POSIX. 1은 그 자체만으로 완전히 구현될 수 없기 때문에, 단지 `poisx'를 사용하는 구성은 완전할 수 없다.

`unix'

이것은 Unix와 같은 것들을 위한 디렉토리이다. C. 4. 2절 [Porting to Unix] 참조. `unix'는 `posix'를 내포한다. 다음은 `unix'의 특별한-목적을 위한 서브디렉토리이다.

`unix/common'

이 디렉토리는 BSD와 시스템 V 릴리즈 4 이 둘의 common을 위한 것이다. `unix/bsd'와 `unix/sysv/sysv4' 둘은 `unix/common'을 내포한다.

`unix/inet'

이 디렉토리는 소켓과 Unix 시스템상의 해당 함수들을 위한 것이다. `inet' 최고 단계 서브디렉토리는 `unix/inet/Subdirs'에 의해 가능해진다. `unix/common'은 `unix/inet'를 내포한다.

`mach'

이것은 CMU로부터(GNU 운영체제가 포함된) 마하(Mach) 마이크로 커널에 기초한 것들을 위한 디렉토리이다. 다른 기본운영시스템들(예를 들어, VMS)은 `sysdeps' 계층의 최고 단계에 있는, `unix'와 `mach'와 유사한, 그들 자신만의 디렉토리들을 가지고 있다.

C. 4. 2 GNU C 라이브러리를 Unix 시스템들로 포팅하기

대부분의 Unix 시스템들은 기본적으로 매우 유사하다. 커널에 제공되는 기능들과 여러 기계들 사이에 차이점이 있다. 하지만 운영체제와의 인터페이스는 대부분에서, 단일하고 간단하다.

Unix 시스템들을 위한 코드는 `sysdeps'계층의 최고단계에 있는 `unix'디렉토리에 있다. 이 디렉토리는 다양한 Unix 변형을 위한 서브디렉토리 (그리고 서브디렉토리 트리)들을 포함한다.

대부분 Unix 시스템에서 시스템 호출 함수들은 `sysdeps/unix'안에 있는 파일들에 어셈블리 코드로 구현되어 있다. 그 파일들은 `. S'의 접미사로 끝나는 이름을 가지고 있다; 예를 들면, `__open. S'. `. S'로 이름이 끝나는 파일들은 어셈블러에게 주어지기 전에 C 프리프로세서를 통해서 실행된다.

그 파일들은 모두 `sysdep. h'에 정의된 매크로들의 설정을 사용한다. `sysdeps/unix'에 있는 `sysdep. h' 파일은 특별하게 그들을 정의한다; 다른 디렉토리 안에 있는 `sysdep. h'파일은 특정한 기계와 운영체제의 변형을 위해서 그들을 정의하는 것을 끝내야만 한다. 무슨 매크로들이 있고 그들이 무엇을 하는지 알기 위해서는 `sysdeps/unix/sysdep. h'와 기계-명세 `sysdep. h' 를 참조하라.

`unix' 디렉토리를 위한 시스템-명세 Makefile은 (그것은, 파일 `sysdeps/unix/Makefile') 당신이 라이브러리를 만들었던 (또는, 당신이 라이브러리를 만들 목표 시스템으로 가정하라. ) Unix 시스템으로부터 여러 파일들을 발생시키기 위한 규칙들을 부여한다.

모든 발생된 파일들은 오브젝트 파일들이 관리되고 있는 디렉토리 안에 들어간다; 그들 자체는 소스 트리에 영향을 미치지 않아야 한다. 발생된 파일들은 `icctl. h', `errnos. h', `sys/param. h' 그리고 `errlist. c'이다 ( 라이브러리에 있는 `stdio' 부분을 위한).

C. 5 GNU C 라이브러리의 공헌자

GNU C 라이브러리는 지금 그것을 유지보수하고 있는 Roland McGrath에 의해 거의 만들어졌다. 라이브러리의 어떤 부분은 다른 사람들에 의해서 작업되었거나 공헌한바 있다.

getopt 함수와 그와 연관된 코드는 Richard Stallman, David J. MacKenzie, 그리고 Roland McGrath에 의해 만들어졌다.

대부분의 수학함수들은 4. 4 BSD로부터 따온 것이다; 그들은 GNU C 라이브러리로 작업하기 위해서 완전히 갱신되었다. 인터넷-관련 코드 ( 대부분 `inet' 서브디렉토리에 있는)와 여러 다른 잡다한 함수들과 헤더파일은 조금 또는 갱신 없이 포함되었다.

4. 4 BSD 로부터 합병된 모든 코드들은 다음과 같은 저작권 하에 있다.

Copyright Oc 1991 Regents of the University of California All rights reserved.

갱신을 하거나, 또는 하지 않고 소스와 바이너리 파일들을 사용하고 재 배포하는 것은, 다음과 같은 상황하에서 공급됨이 허가된다.

1. 소스코드의 재배포는 위의 저작권, 조건의 목록과 다음의 거부 경우를 숙지해야만 한다.

2. 바이너리 형식 파일의 재배포는 원래 공급된 것들과 and/or 시킨 문서를 통해서 위의 저작권, 조건의 목록과 거부의 경우를 다시 만들어야만 한다.

3. 언급되는 기능들이나 이 소프트웨어를 사용하여 광고되는 것에는 다음을 표시해야만 한다. 이 산물은 캘리포니아 대학의, Berkeley와 그 공헌자들에 의해서 개발된 소프트웨어를 포함하고 있다.

4. 대학의 이름이나 공헌자의 이름은 사용 권한에 우선하여 이 소프트웨어로부터 만들어진 산물을 후원하고 뒷받침하기 위해서 사용될 것이다.

이 소프트웨어는 "as is"인 협의회나 공헌자들에 공급되고 아무런 제한은 없지만, 상업적으로 사용되는 것에 대한 경고와 특정한 목적에 맞추어 줄 수 없음 등에 대한 경고들을 포함하거나 표시되어 공급된다. 협의회나 공헌자들이 어떠한 손해도 보상할 책임은 없다. 그리고 그와같은 손해의 가능성에 대해서 조언을 했을지라도, 이 소프트웨어를 사용할 때는 알지 못하는 손해를 입을 가능성을 포함하고 있다.

랜덤 수를 발생시키는 random, srandom, ststate, 그리고 initstate 함수는 rand 와 srand를 기초로 하여, 캘리포이나에 있는 버클리 대학의 Earl T. Cohen에 의해 만들어졌고, 캘리포니아 대학의 협의회(regents)가 저작권을 갖고 있다. 그들은 GNU C 라이브러리와 ANSI C 표준과 맞추기 위해서 작은 변화가 있었지만, 그 함수적인 코드는 버클리에 있다.

합병 정렬 함수 qsort는 Michael J. Haertel에 의해 만들어졌다.

qosrt 함수에 대체되는 퀵 정렬 함수는 Douglas C. Schmidt에 의해 만들어졌다.

메모리 할당 함수 malloc, realloc 그리고 free와 그에 해당되는 코드는 Michael J. Haertel에 의해 만들어졌다.

문자열 함수들의 대부분을 빠르게 구현한 함수들은(memcpy, strlen, 등) Torbj"orn Granlund에 의해 만들어졌다.

마하를 위해 지원하는 코드 중에 어떤 것은 CMU에 의한 마하 3. 0으로부터 온 것이고, 다음과 같은 저작권 하에 있다.

Mach Operatin System Copyright Oc 1991, 19901989 Carnegie Mellon University All Right Reserved.

이 소프트웨어와 문서들을 사용하고, 복사하고, 갱신하고 공급하기 위한 권한은 그들의 일부라도 버전을 갱신하거나, 작업을 파생시키는 경우라 할지라도 모든 복사물에 저작권과 권한에 대한 고지가 나타나야하고, 또한 저작권과 권한 고지는 지원되는 문서에도 나타나야 한다.

carnegie mellon은 "as is" 상황하에서 이 소프트웨어의 자유로운 사용을 허용하고 있다. carnegie mellon은 이 소프트웨어의 사용으로 초래되는 어떠한 손해도 책임을 부인한다.

Carneige Mellon은 개선된 것이나 확장된 것이 있다면

`Software. Distribution@CS. DMU. EDU' 또는 Software Distribution Coordiantor School of Computer Science Carnegie Mellon University Pittsburgh PA 1521303890

어로 보내주고, 이 변경된 것에 대한 재분배 권한을 Carneigie Mellon에게 허가할 것을 요청한다.

`tar. h' 헤더파일은 David J. Mackenzie에 의해서 만들어졌다.

Ultrix 4에서 실행되는 MIPS DECStation으로 포팅은 Brendan Kehoe 와 Ian Lance Taylor에 의해서 공헌되었다.

DES 암호화 함수 crypt와 그와 연관된 함수들은 Michael Glad에 의해서 공헌되었다.

몇 개의 함수는 Ian Lance Taylor에 의해서 공헌되었다.

SunOs 공유 라이브러리들을 지원하는 코드는 Tom Quinn에 의해서 공헌되었다.

mktime 함수는 Noel Cragg에 의해서 공헌되었다.

Dynin version 3에서 실행되는 Sequent Summetry로의 포팅은 Jason Merrill에 의해서 공헌되었다.

timezone 지원 코드는 Arthur David Olson에 의한 공공-도메인 타임죤(timezone) 어로 부터 온 것이다.

인터넷 해결자 코드(Internet resolver code)는 위와 같은 버클리 저작권 하에 있는 BIND 4. 9. 1에서 직접 획득한 것이다.

Portions Copyright Oc 1993 by Digital Equipment Corporation. 이 소프트웨어를 사용하고 복사하고 갱신하고 공급하기 위한 권한은 Digital Equipment 회사의 이름이 광고나 사용의 목적으로 사용되지 않는 곳에서, 위의 저작권과 권한에 대한 공지가 모든 복제물에 나타난다면 제한 없이 사용할 것을 허가한다. digital equipment사는 이 소프트웨어에 대한 모든 권한을 포기하였다. 그리므로 digital equipmint 사가 이 소프트웨어를 사용함으로써 발생되는 손해에 책임지지 않는다.

OSF/1 (alpha-dec-osf1)에서 실행되는 DEC Alpha로의 포팅은 Roland McGrath에 의해서 만들어졌던 어떤 코드를 사용해서, Brendan Kehoe에 의해서 공헌되었다.

printf 와 friends 함수에의해서 사용되는 플리팅-포인트 출력 함수는 Roland McGrath 와 Torbj"orn Granlund에 의해서 만들어졌다. 그 함수에서 사용되는 다-정도(multi-precion) 정수 함수들은 Torbj"orn Granlund 에 의해서 공헌된, GNU MP로부터 획득된 것이다.