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 라이브러리는 다음 패턴들과 맞는 구성을 지원하고 있다.
지원되지 않은 구성들에서, 그들 몇 개를 위한 다른 이름을 편리하게 지원한다. (그들은 물론 다른 GNU 소프트웨어에서 동작한다. )
다음은 configure를 실행시킬 때 당신이 지정할 수 있는 몇 개의 옵션이다.
`--with-gnu-ld'
`--with-gnu-as'
`--nfp'
`--prefix=directory '
`--exec-prefix=directory '
configure를 실행하기 위한 가장 간단한 방법은 라이브러리 소스가 포함된 디렉토리에서 그것을 실행하는 것이다. 이것은 그 디렉토리 안에 라이브러리를 만들기 위해 준비한다.
당신은 configure를 실행하여 다른 디렉토리로 가서 그 다른 디렉토리에 라이브러리를 만들기 위한 준비를 할 수 있다.
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을 입력하라. 이것은 그들을 인스톨하기 전에 필요한 것들을 만들 것이다.
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'
라이브러리를 설치하는(build) 프로세스는 GNU make의 특별한 기능들을 어렵게 사용해서 만드는 Makefile들(makefiles)에 의해 조종된다. Makefile들은 매우 복잡하고, 당신은 아마도 그것을 이해하려 시도하기를 원하지 않을 것이다. 그러나 그들이 하는 일은 굉장히 간단한 것으로, 당신이 올바른 위치에 정의한 몇 개의 변수들만을 요구한다.
라이브러리소스는 주제(topic)에 따라서, 서브디렉토리로 나누어서 묶여져 있다. `string'서브디렉토리는 모든 문자열-처리 함수들을 가지고 있고, `stdio'는 모든 표준 I/O 함수들을 가진다.
각 서브디렉토리는 `Makefile'라고 불리는 간단한 Makefile을 가지고 있는데, 그 파일은 몇 개의 메이크 변수들을 정의하고 전역 Makefile `Rules'를 다음 라인과 함께 포함하고 있다.
서브디렉토리 Makefile을 정의하는 기본 변수들은 다음과 같다:
subdir
headers
routines, aux
tests
others
install-lib, install-data, install
distribute
generated
extra-objs
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' 는 다음을 포함한다:
`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'
`Subdirs'
`sysdeps'
`Dist'
`configure'
`configure. in'
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' 구성을 위해서 시도됐던 디렉토리들의 완전한 리스트가 있다.
다른 기계 구조들은 관습적으로 `sysdeps' 디렉토리 트리의 최고수준에 존재한다. 예를 들어, `sysdeps/sparc'와 `sysdeps/m68k'. 그들은 기계 구조에 대한 파일 명세를 포함하지만, 어느 특정 운영체제에 대한 명세는 아니다. `sysdeps/m68k/s8020' 처럼, 그 구조들의 한정을 위한 서브디렉토리들이 될 것이다. 특별한 기계에서 사용되는 플로팅-포인트 코프로세서에 대한 명세 코드는 `sysdeps/machin/fpu'에 들어가야 한다.
다음은 특정한 기계 구성들을 위한 것이 아닌 `sysdeps' 계층의 최고단계에 있는 몇 개의 디렉토리에 관한 것이다.
`generic', `stub'
`ieee754'
`posix'
`unix'
`unix/common'
`unix/inet'
`mach'
대부분의 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' 부분을 위한).
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.
갱신을 하거나, 또는 하지 않고 소스와 바이너리 파일들을 사용하고 재 배포하는 것은, 다음과 같은 상황하에서 공급됨이 허가된다.
이 소프트웨어는 "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으로부터 온 것이고, 다음과 같은 저작권 하에 있다.
`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로부터 획득된 것이다.
목차 이전 : B. 라이브러리 기능들의 요약 다음 : D. GNU LIBRARY GENERAL PUBLIC LICENSE