Installing GCC

GCC 설치하기

The latest version of this document is always available at http://gcc.gnu.org/install/.

이 문서의 가장 최신 버전은 항상 http://gcc.gnu.org/install/에서 언제나 볼 수 있습니다.

This document describes the generic installation procedure for GCC as well as detailing some target specific installation instructions.

이 문서는 GCC의 일반적인 철치과정 뿐만아니라 자세한 몇몇 종류의 타켓머신으로의 설치 인스트럭션까지 다루고 있습니다.

GCC includes several components that previously were separate distributions with their own installation instructions. This document supercedes all package specific installation instructions. We provide the component specific installation information in the source distribution for historical reference purposes only.

GCC는 그들 자신의 설치 인스트럭션과 함께 미리 분리된 배포물인 컴포넌트를 포함한다. 이 문서는 모든 패키지의 특정한 설치 인스트럭션을 대신한다. 우리는 단지 역사상의 레퍼런스 목적을 위해 소스 분배단계에서 컴포넌트에 특정한 설치 정보를 제공한다.

We recommend you read the entire generic installation instructions as well as any target specific installation instructions before you proceed to configure, build, test and install GCC.

우리는 당신이 configure, bulid, test, GCC 설치 이전에 타겟머신 특정의 설치 인스트럭션 뿐만아니라 일반적인 설치 인스트럭션에 대해서 읽어볼 것을 권장한다.

If something goes wrong in the configure, build, test or install procedures, first double check that you followed the generic and target specific installation instructions carefully. Then check the FAQ to see if your problem is covered before you file a bug report.

만약 당신이 configure, build, test, GCC 설치 과정중에 무언가 문제가 발생한다면 우선 일반적인 또는 타겟머신에 특정한 인스트럭션를 다시 주의깊게 보기를 바란다. 다음으로 버그 레포트를 쓰기 전에 당신의 문제를 해결하기 원한다면 FAQ 를 참고하기 바란다.

Before starting the build/install procedure please browse the host/target specific installation notes.

제발 설치 과정을 시작하기 전에 host/target specific installation notes를 보기 바란다.

The installation procedure is broken into five steps.

• downloading the source
• configure
• build
• test (optional)
• install

설치 과정을 다섯단계로 나누어 본다면

• 소스내려받기
• configure(환경설정)
• build(컴파일하기)
• test(실험) (optional)
• install(설치)

Please note that GCC does not support `make uninstall` and probably won't do so in the near future as this would open a can of worms. Instead, we suggest that you install GCC into a directory of its own and simply remove that directory when you do not need that specific version of GCC any longer.

GCC는 `make uninstall`을 지원하지 않는 것을 주의해라 그렇지 않으면 당혹스러운 문제가 발생할 것이다. 대신에 우리는 별도의(그 자기 자신의) 디렉토리에 설치를 하고 그 버전의 GCC가 더이상 필요하지 않을때 그 디렉토리를 간단히 지우는 방식을 제안한다.

Downloading GCC

GCC 다운받기

GCC is distributed via CVS and FTP tarballs compressed with gzip or bzip2. It is possible to download a full distribution or specific components.

GCC는 여러 CVS나 FTP에서 gzip이나 bzip2로 압축된 타르볼 형태로 분산되어 있다. 전체 설치 가능한 GCC로 아니면 특정한 컴포넌트들로 다운 받는 것이 가능하다

Please refer to our releases web page for information on how to obtain GCC.

GCC를 구하는 방법에 대한 정보는 우리의 releases web page에 자세히 나와있다.

The full distribution includes the C, C++, Objective-C, Fortran, Java, and Chill compilers. The full distribution also includes runtime libraries for C++, Objective-C and Fortran. In the future the GNU compiler testsuites will be included in the full distribution.

전체 패키지는 C, C++, Objective-C, Fortran, Java, Chill compilers를 포함하고 있다. 또한 전체 패키지는 runtime libraries for C++, Objective-C, Fortran도 포함하고 있다. 미래에 전체 패키지에 GNU compiler testsuites도 포함될 것이다.

If you choose to download specific components, you must download the core gcc distribution plus any language specific distributions you wish to use. The core distribution includes the C language front-end as well as the shared components. Each language has a tarball which includes the language front-end as well as the language runtime (when appropriate).

만약 당신이 어느 특정한 컴포넌트들을 선택한다면, 당신이 사용하기 원하는 특정 언어의 패키지에 추가로 핵심(core) gcc를 다운 받아야만 한다.핵심 페키지는 공유 컴포넌트 뿐만 아니라 프론트앤드 C언어를 포함한다 각각의 언어들은 적합한 언어 런타임뿐만 아니라 프론트앤드 언어를 포함한 타르볼을 가진다.

Unpack the core distribution as well as any language specific distributions in the same directory.

핵심 패키지와 특정 언어 패키지를 같은 디렉토리에 압축을 푼다.

If you also intend to build binutils (either to upgrade an existing installation or for use in place of the corresponding tools of your OS), unpack the binutils distribution either in the same directory or a separate one. In the latter case, add symbolic links to any components of the binutils you intend to build alongside the compiler (bfd, binutils, gas, gprof, ld, opcodes,...) to the directory containing the GCC sources.

만약 당신이 binutil들을 컴파일(build)하기를 의도한다면(또는 기존의 설치를 업그레이드 한다거나 당신의 운영체계에 부합하는 툴들의 장소안에서 사용하기를 원할때), binutil 패키지를 같은 디렉토리나 별개의 디렉토리에 압축을 풀면 된다. 후자의 경우에는 binutils의 어떤 컴포넌트에 심볼릭링크를 추가해야한다. you intend to build alongside the compiler (bfd, binutils, gas, gprof, ld, opcodes,...) to the directory containing the GCC sources.

Installing GCC: Configuration

GCC 설치하기 : 환경설정(Configuration)

Like most GNU software, GCC must be configured before it can be built. This document describes the recommended configuration procedure for both native and cross targets.

대부분의 GNU 소프트웨어와 같이,GCC는 컴파일(build)되기전에 반드시 환경설정되어야한다. 이 문서는 네이티브 또는 크로스 타겟을 위한 환경설정에 대한 것을 보여준다.

We use srcdir to refer to the toplevel source directory for GCC; we use objdir to refer to the toplevel build/object directory.

우리는 GCC의 탑레벨 소스 디렉토리를 srcdir로 나타낸다; 또한 탑레벨의 빌드/오브젝트 디렉토리를 나타내기 위해 objdir를 사용한다.

First, we highly recommend that GCC be built into a separate directory than the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn't get extensive testing; building where objdir is a subdirectory of srcdir is unsupported.

먼저, 우리는 소스 디렉토리가 아닌, 소스트리 안에 있지 않은 다른 별개의 디렉토리에 GCC를 만들기(build)를 권장한다. 이것은 우리가 GCC를 컴파일(build)하는 일반적인 방법이다; srcdir == objdir 곳에서 컴파일 하는 것은 광범위한 실험을 할 수 없게 한다; objdir가 srcdir의 서브 디렉토리가 되는 것은 지원하지 않는다.

Second, when configuring a native system, either "cc" or "gcc" must be in your path or you must set CC in your environment before running configure. Otherwise the configuration scripts may fail.

두번째로, 네이티브 시스템으로 컴파일할때 환경설정을 하기 이전에 "cc" 나 "gcc"가 당신의 실행가는 path에 존재하거나 당신의 컴퓨터 환경에 CC를 설정해야 한다. 그렇지 않으면 환경설정 스크립크는 실패하게 될 것이다.

To configure GCC:

% mkdir objdir
% cd objdir
% srcdir/configure [target] [options]

GCC를 설정하기 위해서:

% mkdir objdir
% cd objdir
% srcdir/configure [target] [options]

target specification

타겟 특정화(??)

• GCC has code to correctly determine the correct value for target for nearly all native systems. Therefore, we highly recommend you not provide a configure target when configuring a native compiler.
• GCC는 거의 모든 네이티브 시스템을 위해 target에 대한 바른 값을 결정할 수 있는 코드를 가지고 있다. 그러므로, 우리는 네이티브 컴파일러를 환경설절할때 target설정을 하지 않기를 권장한다.
• target must be specified as --target=target when configuring a cross compiler; examples of valid targets would be i960-rtems, m68k-coff, sh-elf, etc.
• 크로스 컴파일러로 설정할때 예를들면, i960-rtems, m68k-coff, sh-elf 등과 같은 것으로 설정할 때, target을 --target=target과 같이 함으로써 설정할 수 있다.
• Specifying just target instead of --target=target implies that the host defaults to target.
• --target=target하는 대신에 target을 특정화하는 것은 호스트를 디폴트 target 으로 하는 것을 의미한다.

options specification

옵션 설명(specification)

Use options to override several configure time options for GCC. A partial list of supported options:

GCC를 위한 여러가지 설정시 옵션을 사용하기 위해 options을 사용한다. 지원하는 options의 부분적인 리스트는 다음과 같다:

• --prefix=dirname -- Specify the toplevel installation directory. This is the recommended way to install the tools into a directory other than the default. The toplevel installation directory defaults to /usr/local.
• --prefix=dirname -- 설치할 탑레벨 디렉토리를 정해준다. 디폴트 설치 디렉토리가 아닌 다른 디렉토리에 툴들을 설치하는 추천하는 방법이다. 디폴트로 설치되는 탑레벨 설치 디렉토리는 /usr/local이다.

  We highly recommend against prefix being the same or a subdirectory of objdir or vice versa.

  우리는 prefix를 objdir또는 다른 곳의 서브디렉토리나 같은디렉토리와 같게하는 것을 강력히 반대한다. (??)

  These additional options control where certain parts of the distribution are installed. Normally you should not need to use these options.

  여기에 추가적인 옵션들은 패키지의 일부분이 어디에 설치될지를 콘트롤하는 일을 한다. 보통 이러한 옵션은 사용할 필요가 없다.

  • --with-local-prefix=dirname -- Specify the installation directory for local include files. The default is /usr/local.
  • --with-local-prefix=dirname -- 로컬 인클루드 화일들을 위한 설치 디렉토리를 설정한다. 디폴트는 /usr/local 이다.
  • --with-gxx-include-dir=dirname -- Specify the installation directory for g++ header files. The default is /usr/local/include/g++.
  • --with-gxx-include-dir=dirname -- g++ 해더 화일들을 위한 설치 디렉토리를 설정한다. 디폴트는 /usr/local/include/g++이다.
• --enable-shared -- Build shared versions of the C++ runtime libraries if supported --disable-shared is the default.
• --enable-shared -- 만약 지원되는 --disable-shared이 디폴트라면 C++ 런타임 라이브러리의 공유버전을 만든다.
• --enable-haifa -- Enable the new Haifa instruction scheduler in the compiler; the new scheduler can significantly improve code on some targets.
  For EGCS 1.0.x releases --disable-haifa is the default on all platforms except the HPPA.
  For newer releases --disable-haifa is the default on all platforms except the alpha, hppa, powerpc, rs6000, SPARC and m32r.
• --enable-haifa -- 컴파일러에서 새로운 Haifa 인스트럭션 스케쥴러를 사용가능하게 한다; 새로운 스케쥴러는 같은 타겟머신위에서 눈에띄게 코드를 개선시킨다.
  EGCS 1.0.x releases위해서 HPPA를 제외한 모든 플랫폼에서는 --disable-haifa이 디폴트이다. 더 새로운 releases 위해서는 alpha, hppa, powerpc, rs6000, SPARC, m32r를 제외한 모든 플랫폼에서 --disable-haifa가 디폴트이다.
• --with-gnu-as -- Specify that the compiler should assume the GNU assembler (aka gas) is available.
• --with-gnu-as -- 컴파일러가 GNU 어셈블러(aka gas)가 사용가능하다고 생각하게할지를 설정한다.
• --with-gnu-ld -- Specify that the compiler should assume the GNU linker (aka gld) is available.
• --with-gnu-ld -- 컴파일러가 GNU 링커(aka gld)가 사용가능하다고 생각하게할지를 설정한다.
• --with-stabs -- Specify that stabs debugging information should be used instead of whatever format the host normally uses. Normally GCC uses the same debug format as the host system.
• --with-stabs -- stabs 디버깅 인포메이션이 호스트에서 보통 사용하는 포맷 대신에 사용되어야 함을 설정한다. 보통 GCC는 호스트에 있는 같은 디버깅 포맷을 사용한다.
• --enable-multilib -- Specify that multiple target libraries should be built to support different target variants, calling conventions, etc. This is the default.
• --enable-multilib -- 여러 다른 타겟머신과 convention 호출등을 지원하기위한 다중 타겟머신 라이브러리들을 만들지를 설정한다. 이 설정은 디폴트로 되어있다.
• --enable-threads -- Specify that the target supports threads. This affects the Objective-C compiler and runtime library, and exception handling for other languages like C++ and Java.
• --enable-threads -- 타겟이 쓰레드를 지원할지를 설정한다. 이것은 C++과 Java와 같은 다른 언어들을 위한 Objective-C 컴파일러, 런타임 라이브러리, 예외 처리들에 영향을 미친다.
• --enable-threads=lib -- Specify that lib is the thread support library. This affects the Objective-C compiler and runtime library, and exception handling for other languages like C++ and Java.
• --enable-threads=lib -- lib가 쓰레드를 지원하는 라이브러임을 나타낸다. 이것은 C++과 Java와 같은 다른 언어들을 위한 Objective-C 컴파일러, 런타임 라이브러리, 예외 처리들에 영향을 미친다.
• --with-cpu=cpu -- Specify which cpu variant the compiler should generate code for by default. This is currently only supported on the some ports, specifically arm, powerpc, and SPARC. If configure does not recognize the model name (e.g. arm700, 603e, or ultrasparc) you provide, please check the configure script for a complete list of supported models.
• --with-cpu=cpu -- 컴파일러가 어떤 cpu를 대상으로 코드를 만들어낼지를 설정한다. 이것은 현재 현재 단지 몇몇 ports 그리고 특별하게 arm, powerpc, SPARC를 지원하고 있다. 만약 제공되는 모델이름(예를들면, arm700, 603e, or ultrasparc )을 인식하지 않도록 하기 위해서는, 부디 지원하는 모델의 완전한 리스트에서 환경설정 스크립트를 체크해보기 바란다. (??)
• --enable-target-optspace -- Specify that target libraries should be optimized for code space instead of code speed. This is the default for the m32r platform.
• --enable-target-optspace -- 코드의 속도 대신에 코드의 공간 측면에서 타겟 라이브러리들을 최적화할지를 설정한다. m32r 플랫폼에서는 이것이 디폴트이다.
• --enable-cpp -- Specify that a shell script which emulates traditional cpp functionality should be installed.
• --enable-cpp -- 전통적인 cpp 기능(functionality)을 에뮬레이트하는 쉘 스크립트를 인스톨할지를 설정한다.
• --enable-cpplib -- Specify that the functionality of CPP should be integrated into the compiler itself. This is still under development, but may be useful in limited situations. This option is never enabled by default.
• --enable-cpplib -- CPP의 기능(functionality)들이 컴파일러 그 자체에 합쳐질지를 설정한다. 이것은 여전히 개발중것이지만, 제한된 상황에서는 유용하게 사용될 것이다. 이 옵션은 디폴트로 결코 사용되지 않는다.
• --without-fast-fixincludes -- Specify that the old, slower method of fixing the system header files should be used. EGCS 1.1.x and older releases default to the slow version. GCC 2.95 and newer releases will default to the fast version.
• --without-fast-fixincludes -- 시스템 해더 화일들을 수정하는 오래된 느린 함수(method)를 사용할지를 설정한다. EGCS 1.1.x 과 더 오래된 버전은 느린 버전을 디폴트로 하고 있다. GCC 2.95 와 그 이후 버전은 빠른 버전을 디폴트로 하고 있다.
• --enable-version-specific-runtime-libs -- Specify that runtime libraries should be installed in the compiler specific subdirectory (${libsubdir}) rather than the usual places. In addition, libstdc++'s include files will be installed in ${libsubdir}/include/g++ unless you overruled it by using --with-gxx-include-dir=dirname. Using this option is particularly useful if you intend to use several versions of GCC in parallel. This is currently supported by libf2c and libstdc++.
• --enable-version-specific-runtime-libs -- 런타임 라이브러리들이 보통의 장소보다 컴파일러 특정의 서브디렉토리 (${libsubdir})에 설치되어야함을 설정한다. 게다가, 만약 --with-gxx-include-dir=dirname를 사용함으로 그것을 뒤엎지 않는다면 ${libsubdir}/include/g++에 libstdc++'의 인클루드 화일들이 설치될 것이다. 만약 당신이 병렬적으로 여러 버전의 GCC를 사용하기로 했다면, 이 옵션을 사용한다는 것은 매우 유용한 일이다. 이것은 현재 libf2c와 libstdc++에 의해 지원되고 있다.
• --enable-languages=lang1,lang2,... -- Specify that only a particular subset of compilers and their runtime libraries should be built. For a list of valid values for langx you can issue the following command in the gcc directory of your GCC source tree:
  grep language= */config-lang.in
  Currently, you can use any of the following: CHILL, c++, f77, java and objc. Please note, that this switch does not work with EGCS 1.1.2 or older versions of egcs. It is supported in GCC 2.95 and newer versions.
  If you do not pass this flag, all languages available in the gcc sub-tree will be configured. Re-defining LANGUAGES when calling make bootstrap *does not* work anymore, as those language sub-directories might not have been configured!
• --enable-languages=lang1,lang2,... -- 컴파일러나 그들의 런타임 라이브러리들의 특별한 부분만이 빌드되어야 할지를 설정한다. langx에 사용가능한 값들의 목록에서 당신의 GCC 소스트리에서의 gcc 디렉토리안에서 다음과 같은 커맨드를 실행할 수 있다:
  grep language= */config-lang.in
  현재, 당신은 다음과 같은 것을 사용할 수 있다: CHILL, c++, f77, java and objc. 이 스위치(switch)는 EGCS 1.1.2나 그 이상의 버전에서는 작동하지 않음을 주지하기 바란다.
  만약 당신이 이 플래그를 지나치지 않는다면, gcc 서브트리에 있는 모든 언어들을 사용가능하도록 설정할 것이다. make bootstrap를 호출할때 다시 정의한 언어들(LANGUAGES)은 더 이상 작동하지 *않을 것이다.* 그들의 언어 서브디렉토리들은 설정되어지지 않을 것이다!
• --with-dwarf2 -- Specify that the compiler should use DWARF2 debugging information as the default.
• --with-dwarf2 -- 컴파일러가 디폴트로 DWARF2 디버깅 정보를 사용할지를 설정한다.

Some options which only apply to building cross compilers:

몇몇 옵션들은 크로스 컴파일러를 만들때 단지 사용된다:

• --with-headers=dir -- Specifies a directory which has target include files. This options is required when building a cross compiler, if ${prefix}/${target}/sys-include doesn't pre-exist. These include files will be copied into the gcc install directory. Fixincludes will be run on these files to make them compatible with gcc.
• --with-headers=dir -- 타겟 인클루드 화일들을 가지고 있는 디렉토리의 위치를 설정한다. ${prefix}/${target}/sys-include이 미리 존재하지 않는다면, 크로스 컴파일러를 만들시에 이 옵션은 반드시 필요하다. 이 인클루드 화일들은 gcc 설치 디렉토리로 복사되어질 것이다. 수정된 인클루드들은 gcc와 함께 호환되도록 만들기 위해 이 화일들과 함께 실행되어질 것이다.
• --with-libs="dir1 dir2 ... dirN" -- Specifies a list of directories which contain the target runtime libraries. These libraries will be copied into the gcc install directory.
• --with-libs="dir1 dir2 ... dirN" -- 타겟 런타임 라이브러리들을 포함하고 있는 디렉토리들을 설정한다. 이 라이브러리들은 gcc 설치 디렉토리에 복사되어질 것이다.
• --with-newlib -- Specifies that "newlib" is being used as the target C library. This causes __eprintf to be omitted from libgcc.a on the assumption that it will be provided by newlib.
• --with-newlib -- 타겟 C 라이브러리로써 사용되어지는 "newlib"를 설정한다. 이옵션은 newlib에 의해 제공되어 질 것이라는 가정하에 libgcc.o로 부터 __eprintf를 생략하게 만든다.

Note that each --enable option has a corresponding --disable option and that each --with option has a corresponding --without option.

각각의 --enable옵션은 각각에 대응하는 --disable 옵션을 가지고 있다. 각각의 --with옵션은 각각에 대응하는 --without 옵션을 가지고 있다.

Installing GCC: Building

GCC 설치하기: 컴파일(Building)

Now that GCC is configured, you are ready to build the compiler and runtime libraries.

지금은 GCC가 환경설정이 되었다면, 당신은 컴파일러와 런타임 라이브러리들을 만들 준비가 다 된 것이다.

We highly recommend that GCC be built using GNU make; other versions may work, then again they might not.

우리는 GNU make를 사용하여 GCC를 컴파일(bulid)하기를 강력히 추천한다; 다른 버전은 작동할 수도 있고 다시 작동하지 않을 수도 있다.

(For example, many broken versions of make will fail if you use the recommended setup where objdir is different from srcdir.)

(예를들면, 많은 make의 깨진 버전들을 이용하면 권장하는 설정인 srcdir와 다른 곳으로 objdir를 설정하였을시에 실패하게 될 것이다.)

Building a native compiler

네이티브 컴파일러 만들기

For a native build issue the command `make bootstrap'. This will build the entire GCC system, which includes the following steps:

네이티브를 위해서 'make bootstrap'라는 명령을 사용한다. 이것은 전체의 GCC 시스템을 만들 것이다. 그 단계는 다음과 같다:

• Build host tools necessary to build the compiler such as texinfo, bison, gperf.
• 컴파일러를 만들기 위해서 필요한 texinfo, bison, gperf와 같은 호스트 툴들을 만든다
• Build target tools for use by the compiler such as binutils (bfd, binutils, gas, gprof, ld, and opcodes)
  if they have been individually linked or moved into the top level GCC source tree before configuring.
• 컴파일러에 의해 사용될 binutils(bfd, binutils, gas, gprof, ld, and opcodes)과 같은 타겟 툴들을 만든다.
  만약 환경설정 전에 그들을 개별적으로 탑레벨의 GCC 소스 트리속으로 옮기거나 링크하려고 한다면
• Perform a 3-stage bootstrap of the compiler.
• 컴파일러의 3-stage bootstrap을 수행한다.
• Perform a comparison test of the stage2 and stage3 compilers.
• stage2 컴파일러와 stage3 컴파일러의 바교 테스트를 수행한다.
• Build runtime libraries using the stage3 compiler from the previous step.
• 이전 단계로부터 stage3 컴파일러가 사용하는 런타임 라이브러리를 만든다.

If you are short on disk space you might consider `make bootstrap-lean' instead. This is identical to `make bootstrap' except that object files from the stage1 and stage2 of the 3-stage bootstrap of the compiler are deleted as soon as they are no longer needed.

만약 당신이 가지고 있는 디스크 공간이 적다면 `make bootstrap-lean'를 대신 사용하는 것을 고려해봐야한다. 이것은 3-stage 부트스트랩에서의 stage1, stage2로부터 나온 오브젝트 화일들을 그것들이 더이상 필요없게 되자마자 삭제한다는 것을 빼곤 `make bootstrap'과 동일하다.

If you want to save additional space during the bootstrap and in the final installation as well, you can build the compiler binaries without debugging information with "make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap". This will save roughly 40% of disk space both for the bootstrap and the final installation. (Libraries will still contain debugging information.)

만약 당신이 마지막 설치 과정 뿐만 아니라 부트스트랩과정중에 추가적인 공간을 절약하기를 원한다면, "make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap"함으로써 디버깅 정보를 없애고 컴파일러 바이너리를 만들 수 있다. 이것은 부트스트랩 그리고 마지막 인스톨과정에서 거의 40%의 디스크 공간 절약을 가져오게된다. (라이브러리들은 디버깅 정보를 여전히 포함하게 될 것이다.)

If you used the flag --enable-languages=... to restrict the compilers to be built, only those you've actually enabled will be built. This will of course only build those runtime libraries, for which the particular compiler has been built. Please note, that re-defining LANGUAGES when calling `make bootstrap' *does not* work anymore!

컴파일러를 만들시에 제악을 위해서 --enable-languages=... 플래그를 사용한다면, 실제적으로 사용할 것들로 만들게 될 것이다. 이것은 특별한 컴파일러로 만들기 위해서 그 언어들의 런타임 라이브러리를 만들것이다. `make bootstrap' 호출시에 재정의된 언어들은 더 이상 작동하지 않을 것이다.

Building a cross compiler

크로스 컴파일러 만들기

We recommend reading the crossgcc FAQ for information about building cross compilers.

크로스 컴파일러를 만드는 것에 대한 정보들은 crossgcc FAQ에서 얻어서 읽어보기를 권한다.

When building a cross compiler, it is not generally possible to do a 3-stage bootstrap of the compiler. This makes for an interesting problem as parts of GCC can only be built with GCC.

크로스 컴파일러를 만들시에, 일반적으로 컴파일러의 3-stage 부트스트랩을 하는 것은 가능하지 않다 이것은 GCC의 부분으로써 관심있는 문제를 위해 단지 GCC와 함께 만들어진다. (??)

To build a cross compiler, we first recommend building and installing a native compiler. You can then use the native GCC compiler to build the cross compiler.

크로스 컴파일러를 만들기 위해서, 우리는 우선 네이티브 컴파일러를 만들고 설치하기를 권장한다. 당신은 크로스 컴파일러를 만들기 위해서 네이티브 컴파일러를 사용할 수 있을 것이다.

Assuming you have already installed a native copy of GCC and configured your cross compiler, issue the command "make", which performs the following steps:

당신이 이미 네이티브 컴파일러를 가지고 있으며 크로스 컴파일러를 위한 설정을 마쳤다고 가정한다면, "make" 명령을 실행하라. 이것은 다음과 같은 작업들을 수행한다:

• Build host tools necessary to build the compiler such as texinfo, bison, gperf.
• texinfo, bison, gper와 같이 컴파일러를 만들기 위해 필요한 호스트 툴들을 만든다.
• Build target tools for use by the compiler such as binutils (bfd, binutils, gas, gprof, ld, and opcodes)
  if they have been individually linked or moved into the top level GCC source tree before configuring.
• binutils (bfd, binutils, gas, gprof, ld, and opcodes)과 같이 컴파일러에 의해 사용되는 타겟 툴들을 만든다
  만약 환경설정 전에 그들을 개별적으로 탑레벨의 GCC 소스 트리속으로 옮기거나 링크하려고 한다면
• Build the compiler (single stage only).
• 컴파일러를 만든다 (오직 single stage ).
• Build runtime libraries using the compiler from the previous step.
• 이전 단계로부터 컴파일러에서 사용하는 런타임 라이브러리를 만든다.

Note that if an error occurs in any step the make process will exit.

만약 어떤 단계에서라두 에러가 발생하면 make 작업은 멈추게 될 것이다.

Building in parallel

병렬적으로 만들기

If you have a multiprocessor system you can use `make bootstrap MAKE="make -j 2" -j 2' or just `make -j 2 bootstrap' for GNU Make 3.79 and above instead of just `make bootstrap' when building GCC. You can use a bigger number instead of two if you like. In most cases, it won't help to use a number bigger than the number of processors in your machine.

만약 당신이 멀티프로세서 시스템을 가지고 있다면, GCC를 만들시에 위에 있는 `make bootstrap' 대신에 `make bootstrap MAKE="make -j 2" -j 2'나 GNU Make 3.79 에서 `make -j 2 bootstrap' 를 사용할 수 있다. 당신이 좋다면 2보다 더 큰 수를 사용할 수도 있다. 대부분의 경우에, 당신의 머신의 프로세서의 수보다 큰 수를 사용하는 것은 별 도움이 되지 않을 것이다.

Installing GCC: Testing

GCC 설치하기: 테스팅

Please note that this is only applicable to current development versions of GCC and GCC 3.0 or later. GCC 2.95.x does not come with a testsuite.

이것은 현재의 개발 버전의 GCC나 GCC 3.0 또는 그 이후의 버전의 GCC에서 사용가능하다는 것을 주의하라.GCC 2.95.x은 testsuite와 함께 올수 없다.

Before you install GCC, you might wish to run the testsuite. This step is optional and may require you to download additional software.

GCC를 설치하기 전에, 당신은 테스트슈트들을 실행해 보기를 원할 것이다. 이 과정은 옵션이며 추가적으로 소프트웨어를 다운받아야할 필요가 있다.

First, you must have downloaded the testsuites. The full distribution contains testsuites; only if you downloaded the "core" compiler plus any front ends, you do not have the testsuites.

우선 당신은 downloaded the testsuites에서 다운받아야한다. 전체 패키지는 테스트슈트를 포함하고 있다; 만약 당신이 프론트 앤드에 추가로 핵심 컴파일러만을 다운받았다면, 테스트슈트를 가지고 있지 않을 것이다.

Second, you must have a new version of dejagnu on your system; dejagnu 1.3 will not work. We have made dejagnu snapshots available at ftp://gcc.gnu.org/pub/gcc/infrastructure until a new version of dejagnu has been released.

다음으로, 당신의 시스템의 새로운 버전의 dejagnu을 가지고 있어야한다; dejagnu 1.3은 동작하지 않을것이다. 새로운 버전의 dejagnu가 나올때까지 ftp://gcc.gnu.org/pub/gcc/infrastructure 에서 dejagnu 스냅샷을 사용가능 하도록 만들어 놓았다.

Finally, you can run the testsuite (which may take a long time):

cd objdir; make -k check

마지막으로, 당신은 테스트슈트를 (비록 시간이 오래걸리겠지만) 실행시킬 수 있다:

cd objdir; make -k check

The testing process will try to test as many components in the GCC distribution as possible, including the C, C++ and Fortran compilers as well as the C++ runtime libraries.

테스트 과정은 C++ 런타임 라이브러리 뿐만아니라 C, C++, Fortan 컴파일러를 포함한 GCC 전체 패키지에서 많은 컴포넌트들을 테스트해보려고 할 것이다.

How can I run the test suite on selected tests?

선택된 테스트에서 어떻게 테스트 슈트를 실행시킬 것이가?

As a first possibility to cut down the number of tests that are run it is possible to use `make check-gcc` or `make check-g++` in the gcc subdirectory of the object directory. To further cut down the tests the following is possible:

make check-gcc RUNTESTFLAGS="execute.exp <other options>"

실행하는 테스트의 수를 줄일 수 있는 가능성으로써 오브젝트 디렉토리의 gcc 서브디렉토리에서 `make check-gcc` 나 `make check-g++` 명령을 수행시킬 수 있다. 다음과 같이 함으로써 테스트의 수를 더 줄일 수 있다:

make check-gcc RUNTESTFLAGS="execute.exp <other options>"

This will run all gcc execute tests in the testsuite.

make check-g++ RUNTESTFLAGS="old-deja.exp=9805* <other options>"

이 명령은 테스트슈트에서 실행가능한 gcc 테스트를 모두 실행하게 할 것이다.

make check-g++ RUNTESTFLAGS="old-deja.exp=9805* <other options>"

This will run the g++ "old-deja" tests in the testsuite where the filename matches 9805*.

이것은 화일명이 9805*로 일치하는 테스트슈트에서 g++ "old-deja" 테스트를 수행한다.

The *.exp files are located in the testsuite directories of the GCC source, the most important ones being compile.exp, execute.exp, dg.exp and old-deja.exp. To get a list of the possible *.exp files, pipe the output of `make check` into a file and look at the "Running ... .exp" lines.

*.exp 화일들은 GCC 소스의 테스트슈트 디렉토리에 위치한다. 대부분 중요한 것은 compile.exp, execute.exp, dg.exp and old-deja.exp이다. 가능한한 *.exp 화일들의 목록을 얻기 위해서, `make check`의 결과를 파이프를 이용해 화일에 저장하고 "Running ... .exp" 라인들을 찾아보면 된다.

How to interpret test results

테스트 결과를 해석하기

After the testsuite has run you'll find various *.sum and *.log files in the testsuite subdirectories. The *.log files contain a detailed log of the compiler invocations and the corresponding results, the *.sum files summarize the results. These summaries list all the tests that have been run with a corresponding status code:

테스트슈트를 실행시킨 뒤에 테스트슈트의 서브디렉토리에서 여러개의 *.sum 과 *.log 화일들을 찾아볼 수 있을 것이다. *.log 화일들은 컴파일러의 호출(invocations)들에 대한 자세한 기록들을 포함한다. *.sum 화일들은 결과를 요약해 놓은 것이다. 이 요약들은 다음과 같은 상태 코드와 함께 수행되는 모든 테스트들을 나열해 놓은 것이다:

• PASS: the test passed as expected
• PASS: 예상되는 대로 지나간 테스트
• FAIL: the test unexpectedly failed
• FAIL: 예상치 못하게 실패한 테스트
• XFAIL: the test failed as expected
• XFAIL: 예상한 대로 실패한 테스트
• UNSUPPORTED: the test is not supported on this platform
• UNSUPPORTED: 이 플렛폼에서 지원하지 않는 테스트
• ERROR: the testsuite detected an error
• ERROR: 에러를 발견한 테스트슈트
• WARNING: the testsuite detected a possible problem
• WARNING: 가능한 문제들을 발견한 테스트슈트

It is normal for some tests to report unexpected failures. At the current time our testing harness does not allow fine grained control over whether or not a test is expected to fail. We expect to fix this problem in future releases.

몇몇의 테스트에서 예상치 못한 실패들을 보고하는 것은 자주 있는 일이다. 현재 우리 테스트의 어려움은 테스트가 실패할지 그렇지 않을지에 대한 통제를 허용하지 않는 것이다.(??) 우리는 미래의 릴리즈에서 이런 문제가 해결되기를 바란다.

Submitting test results

테스트 결과들을 제출하기

If you want to report the results to the GCC project, use the contrib/test_summary shell script. Start it in the objdir with

srcdir/contrib/test_summary -p your_commentary.txt -m gcc-testresults@gcc.gnu.org |sh

만약 당신이 GCC 프로젝트에 결과들을 보고하기 원한다면, contrib/test_summary 쉘 스크립트를 사용하면 된다. objdir에서 실행하면된다:

srcdir/contrib/test_summary -p your_commentary.txt -m gcc-testresults@gcc.gnu.org |sh

This script uses the Mail program to send the results, so make sure it is in your PATH. The file your_commentary.txt is prepended to the testsuite summary and should contain any special remarks you have on your results or your build environment. Please do not edit the testsuite result block or the subject line, as these messages are automatically parsed and presented at the GCC testresults web page. Here you can also gather information on how specific tests behave on different platforms and compare them with your results. A few failing testcases are possible even on released versions and you should look here first if you think your results are unreasonable.

이 스크립트가 결과를 보내기 위해 Mail 프로그램을 사용한다. 그래서 당신의 경로(path)에 그것이 존재하도록 만들어야 한다. your_commentary.txt라는 당신의 화일이 테스트슈트의 요약을 담고있고 당신의 컴파일(build) 환경이나 당신의 테스트결과에서 주목할 만한 내용들을 포함해야만 한다. 제발 subject 라인이나 테스트슈트 결과 블럭을 수정하지 말기를 바란다. 이러한 메세지들은 자동으로 파싱되어지며, GCC testresults 웹 페이지에 나타나게 된다. 여기에서 당신은 다른 플랫폼에서 어떻게 특정하게 테스트 되었는지에 대한 정보나 당신의 결과를 다른 것과 비교할 수 있을 것이다. 약간의 테스트 실패가 릴리즈 버전에서 있을 수 있다. 만약 당신의 결과가 이상하다고 생각이되면 먼저 여기를 살펴보기를 바란다.

Installing GCC: Final installation

GCC 설치하기: 마지막 설치

Now that GCC has been built and tested, you can install it with `cd objdir; make install' for a native compiler or `cd objdir; make install LANGUAGES="c c++"' for a cross compiler (note installing cross compilers will be easier in the next release!).

이제 GCC는 만들어졌고(build) 테스트까지 마친 상태이다. 네이티브 컴파일러를 위해 `cd objdir; make install' 라고 수행하거나 크로스 컴파일러를 위해 `cd objdir; make install LANGUAGES="c c++"'라고 수행하면 된다.(다음 릴리즈에서 크로스 컴파일러 설치는 더 쉬어질 것이다!).

That step completes the installation of GCC; user level binaries can be found in prefix/bin where prefix is the value you specified with the --prefix to configure (or /usr/local by default).

이 단계는 GCC의 설치를 마무리하는 과정이다; 유저가 사용가능한 바이너리들이 prefix/bin에 위치할 것이다. prefix는 환경설정시에 --prefix라는 옵션을 이용하여 설정한 디렉토리의 위치이다.(또는 디폴트로는 /usr/local 이다).

If you don't mind, please quickly review the build status page. If your system is not listed, send a note to gcc@gcc.gnu.org indicating that you successfully built and installed GCC. Include the output from running srcdir/config.guess. (Do not send us the config.guess file itself, just the output from running it!)

만약 기억나지 않는다면, 재빠르게 build status page를 다시 보기 바란다. 만약 당신의 시스템이 목록에 있지 않는데 성공적으로 build하고 설치했다면, gcc@gcc.gnu.org로 당신의 srcdir/config.guess의 실행 결과물을 포함해서 보내주기 바란다. (우리에게 config.guess 화일 자체를 보내지 말구 그것을 실행시킨 결과물을 보내도록!)

If you find a bug, please report it following our bug reporting guidelines.

만약 당신이 버그를 발견한다면, bug reporting guidelines에 그것을 보고해주기를 바란다.