GNU 라이브러리참조 안내서

[ 1장, 2장, 3장, 4장, 5장, 6장, 7장, 8장, 9장, 10장, 11장, 12장, 13장, 14장, 15장, 16장, 17장, 18장, 19장, 20장, 21장, 22장, 23장, 24장, 25장, 26장, 27장, 부록A, 부록B,C, 부록D, GNU C 라이브러리 목록 ]

이글은 하이텔 소프트웨어동호회의 소모임인 직장인을 위한 씨모임에서 장장 2년간의 대장정으로 번역되어진 문서입니다. 지금은 직씨장을 지내고 있는 김소영(flpigy)님과 조원봉(thirnine)님, 고석갑님(sukgab)의 공동번역입니다.

부록 B. 라이브러리 기능들의 요약

이 부록은 GNU C 라이브러리 안에서 공급되는 헤더파일안에 선언된 기능들의 완전한 리스트이다. 각 엔트리는 그 기능이 표준인지 아니면 다른것으로부터 왔는지를 표시하고, 그것을 어떻게 사용하 는지에 대한 정보를 이 매뉴얼의 어느 부분에서 찾을것인지를 알려준다.

-----------------------------------------------------------

### 잠깐만!!!

이 부록 B는 함수들의 리스트가 나와있습니다... 번역이 필요치 않아서 위의 한 문단만 번역하고 넘 어갑니다.

-----------------------------------------------------------

부록 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] 1 페이지 참조.)을 따르지 않는 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의 특별한 기능들을 어렵게 사용해서 만드는 메이크파일들(makefiles)에 의해 조종된다. 메이크파일들은 메우 복잡하고, 당신은 아마도 그것을 이 해하려 시도하기를 원하지 않을것이다. 그러나 그들이 하는일은 굉장히 간단한 것으로, 당신이 올바 른 위치에 정의한 몇 개의 변수들만을 요구한다.

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

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

include ../Rules

서브디렉토리 메이크파일을 정의하는 기본 변수들은 다음과 같다:

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] 469 페이지 참조.) 안에 `libdir'에 의해 정해진 디렉토리안에 인스톨된다. install-data 안에 목록이 있는 파일들은 `configparms' 또는 `Makeconfig' 에 있는 `datadir'에 의해 정해진 디렉토리안에 인스톨된다. install안에 목록이 있는 파일들은 `configparms' 또는 `Makeconfig' 안에 있는 `bindir' 에 의해서 정해진 디렉토리안에 인스톨된다.

distribute

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

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] 454 페이지 참조.)

`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] 11 페이지 참조.

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

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

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

`Makefile'

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

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

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

`Subdirs'

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

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

`Dist'

이 파일은 distribution 안에 포함될 파일들( 그것이 있는 `sysdeps'의 서브디렉토리에 관한)의 이름 을 포함한다. 같은 디렉토리의 `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] 456 페이지 를 참조하라.

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] 452 페이지 참조.), 모든 구성들이 다른것들 후에 사용하는 두 개의 서브디렉토리들이 있다.

`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] 456 페이지 참조. `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' 디렉토리를 위한 시스템-명세 메이크파일은 (그것은, 파일 `sysdeps/unix/Makefile') 당신이 라이브러리를 만들었던 (또는, 당신이 라이브러리를 만들 목표 시스템으로 가정하라.) Unix 시스템으 로부터 여러 파일들을 발생시키기 위한규칙들을 부여한다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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에게 허가할 것을 요청한다.

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

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

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

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

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

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

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

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

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

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

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