Please read this document carefully before installing the GNU Compiler Collection on your machine.
당신의 컴퓨터에 GNU Compiler를 설치하기 전에 이 문서를 주의깊게 읽어주기 바란다.
We strongly recommend to upgrade to binutils 2.10 (or newer).
우리는 binutils 2.10 또는 그 이상의 버전으로 업그레이드 하기를 강력히 권장한다.
The following error:
Error: macro requires $at register while noat in effect
다음과 같은 에러는:
Error: macro requires $at register while noat in effect
indicates that you should upgrade to a newer version of the assembler, 2.9 or later. If you can not upgrade the assembler, the compiler option "-Wa,-m21164a" may work around this problem.
버전 2.9나 그 이상의 버전으로 어셈블러 버전을 업그레이드 해야함을 나타낸다. 만약 당신이 어셈블러를 업그레이드 할수 없다면 "-Wa,-m21164a"이라고 옵션을 주어서 문제를 해결할 수 있다.
If you install a shared libstdc++ and, when you link a non-trivial C++
program (for example, gcc/testsuite/g++.other/delete3.C),
the linker reports a couple of errors about multiply-defined symbols
(for example, nothrow, __throw and
terminate(void)), you've probably got a linker bug, for
which there's no known fix. The officially recommended work-around is
to remove the shared libstdc++.
만약 당신이 공유된(shared) libstdc++를 설치하기를 원하고 , 평범하지 않은(non-trivial) C++ 프로그램을 링크한다고 할때, (예를 들면, gcc/testsuite/g++.other/delete3.C), 다중으로 정의된 심볼(예를들면,
nothrow, __throw and terminate(void))에 관한 몇몇의 에러를 링커가 보고할 것이다.
이를 고치는 알려진 방법이 없기 때문에, 당신은 아마두 링커 버그를 가지게 될 것이다. 공식적으로 제안된 문제해결방법은 공유된(shared) libstdc++를 제거하는 것이다.
An alternative solution is to arrange that all symbols from
libgcc get copied to the shared libstdc++;
see detailed solution below. (Surprising as it may seem, this does
indeed fix the problem!) Beware that this may bring you
binary-compatibility problems in the future, if you don't use the same
work-around next time you build libstdc++: if programs
start to depend on libstdc++ to provide symbols that used
to be only in libgcc, you must arrange that
libstdc++ keeps providing them, otherwise the programs
will have to be relinked.
또 다른 해결책은 libgcc의 모든 심볼을 공유된 libstdc++에서 카피해서 수정하는 것이다. 자세한 해결방법을 아래를 참고해라.(놀라웁게도 보면, 이것은 실제로 문제를 해결한다.) 만약 당신이 libstdc++를 컴파일(build)하는 다음번에 같은 방법으로 하지 않으면 가까운 미래에 바이너리-호환성(binary-compatibility)문제를 야기할 것이다 : 만약 프로그램이 단지 libgcc안에서 사용되는 심볼들을 제공하기 위해서 libstdc++에 의지해서 시작되어 진다면, 당신은 libstdc++가 계속적으로 그것들을 제공하도록 수정해야하며, 뿐만아니라 프로그램을 재링크시켜야만 한다.
The magic spell is to add -Wl,-all,-lgcc,-none to the
definition of macro SHDEPS in
libstdc++/config/dec-osf.ml before
alpha*-dec-osf*/libstdc++/Makefile is created (a patch that does just that is
available). If the Makefile already exists, run
./config.status within directory
alpha*-dec-osf*/libstdc++ (and
alpha*-dec-osf*/ieee/libstdc++, if it also exists).
Remove any existing libstdc++.so* from such directories,
and run make all-target-libstdc++ in the top-level
directory, then make install-target-libstdc++.
alpha*-dec-osf*/libstdc++/Makefile이 만들어지기 전에 (막 사용가능한 patch
) libstdc++/config/dec-osf.ml에서 매크로 SHDEPS을 정의하기 위해서 -Wl,-all,-lgcc,-none를 추가시키는 것은 마술같은 해결책이다. 만약 Makefile이 이미 존재한다면, alpha*-dec-osf*/libstdc++디렉토리에서 (그리고 alpha*-dec-osf*/ieee/libstdc++이 또한 존재한다면) ./config.status을 실행한다. 그러한 디렉토리들에 존재하는 어떤 libstdc++.so*도 제거하라. 그리고 탑-레벨 디렉토리에서 make
all-target-libstdc++를 실행하고 이후에 make
install-target-libstdc++라고 실행한다.
If you have already removed the build tree, you may just remove
libstdc++.so.2.10.0 from the install tree and re-create
it with the command gcc -shared -o libstdc++.so.2.10.0
-Wl,-all,-lstdc++,-lgcc,-none -lm. If the ieee
sub-directory exists, repeat this command in it, with the additional
flag -mieee.
만약 당신이 이미 컴파일(build) 트리를 제거하였다면, 당신은 libstdc++.so.2.10.0를 제거해야하며, gcc -shared -o libstdc++.so.2.10.0 -Wl,-all,-lstdc++,-lgcc,-none
-lm라는 명령과 함께 그 트리를 다시 설치하고 다시 만들어야 할 것이다.ieee 서브 디렉토리가 존재한다면, 그 안에서 -mieee라는 추가적인 플래그와 함께 위와 같은 명령을 내려라.
Please have a look at our binaries page.
우리의 binaries page(바이너리 페이지)를 보세요.
We highly recommend using gas/binutils-2.8 or newer on all hppa platforms; you may encounter a variety of problems when using the HP assembler.
우리는 모든 hppa 플랫폼에서 gas/binutils-2.8이나 그 이상의 버전을 쓰기를 강력히 제안한다; 당신은 HP 어셈블러를 사용할때, 다양한 문제를 만날 수 있다.
If you wish to use pa-risc 2.0 architecture support, you must use either the HP assembler or a recent snapshot of gas.
만약 당신이 pa-risc 2.0 아키텍쳐 지원을 사용하고 싶다면, 당신은 HP 어셈블러나 또는 최근의 gas의 스냅샷을 사용해야만 한다.
More specific information to hppa*-hp-hpux* targets follows.
더 자세한 사항은 hppa*-hp-hpux* 타겟 머신을 참고하세요.
The HP assembler has major problems on this platform. We've tried to work around the worst of the problems. However, those workarounds may be causing linker crashes in some circumstances; the workarounds also probably prevent shared libraries from working. Use the GNU assembler to avoid these problems.
HP 어셈블러는 이 플랫폼에서 큰 문제를 가지고 있다. 우리는 이 문제들을 최소화하기 위해 노력해왔다. 그러나, 이러한 노력들은 몇몇의 환경에서 링커 깨짐(linker crashes) 현상들을 야기시킨다; 이러한 노력은 또한 작업으로부터 공유 라이브러리를 막는다. 이러한 문제를 피하기 위해서 GNU 어셈블러를 사용하라..
The configuration scripts for GCC will also trigger a bug in the hpux9 shell. To avoid this problem set CONFIG_SHELL to /bin/ksh and SHELL to /bin/ksh in your environment.
GCC를 위한 설정 스크립트는 hpux9 쉘에서 버그를 발생시킨다. 이러한 문제를 피하기 위해서 당신의 환경에서 CONFIG_SHELL을 /bin/ksh로 SHELL를 /bin/ksh로 설정해야한다.
For hpux10.20, we highly recommend you pick up the latest sed
patch PHCO_19798 from HP. HP has two sites which provide patches free of charge:
hpux10.20를 위해서, 우리는 HP로부터 가장 최근의 sed patch, PHCO_19798를 가져오기를 강력히 권장한다. HP는 무료의 패치를 두개의 사이트에서 제공한다:
The HP assembler on these systems is much better than the hpux9 assembler,
but still has some problems. Most notably the assembler inserts timestamps
into each object file it creates, causing the 3-stage comparison test to fail
during a `make bootstrap'. You should be able to continue by
saying `make all' after getting the failure from `make
bootstrap'.
이러한 시스템에서의 HP 어셈블러는 hpux9 에셈블러보다 훨씬 낫다. 그러나 몇몇 문제점을 가진다. 그중에 가장 두드러진 것은 그것이 만든 각각의 오브젝트 화일안에 타임스템프를 삽입한다는 것이다. 이것은 `make bootstrap'시에 3단계 비교테스트(the 3-stage comparison test)가 실패하도록 만든다. 당신은 `make
bootstrap'로 부터 실패를 얻은 후에 `make all'라고 함으로써 계속진행해야 한다.
GCC 2.95.2 does not support HP-UX 11, and it cannot generate 64-bit object files. Current (as of late 2000) snapshots and GCC 3.0 do support HP-UX 11.
GCC 2.95.2는 HP-UX 11를 지원하지 않는다. 그리고, 그것은 64-bit오브젝트 화일을 만들지 못한다. 현재의 스냅샷(2000년 말)과 GCC 3.0은 HP-UX 11를 지원한다.
If you use glibc 2.2 (or 2.1.9x), GCC 2.95.2 won't install out-of-the-box. You'll get compile errors while building libstdc++. The patch glibc-2.2.patch, that is to be applied in the GCC source tree, fixes the compatibility problems.
만약 당신이 glibc 2.2 (or 2.1.9x)를 사용한다면, GCC 2.95.2는 out-of-the-box를 설치할 수 없을 것이다. 당신은 libstdc++를 컴파일(build)하는 과정에서 에러들을 얻게 될 것이다. 패치 glibc-2.2.patch를 GCC 소스 트리에 적용시키면, 호환성문제는 없어질 것이다.
You will need binutils-2.9.1.0.15 or newer for exception handling to work.
당신은 작업에서 예외 처리를 하기 위해서 binutils-2.9.1.0.15이나 그 이상버전이 필요할 것이다.
If you receive Signal 11 errors when building on GNU/Linux, then it is possible you have a hardware problem. Further information on this can be found on www.bitwizard.nl.
GNU/Linux에서 컴파일(build)하고 있는중에 시그널 11 에러를 받는다면, 그것은 하드웨어 문제를 가지고 있음을 이야기한다. 더 자세한 정보는 http://www.bitwizard.nl/sig11/에서 얻을 수 있다
If you are building languages other than C, you must follow the instructions
about invoking `make bootstrap' because the native OpenServer
compiler will build a cc1plus that will not correctly parse many
valid C++ programs including those in libgcc.a. You must do a `make bootstrap' if you are building with the native compiler.
만약 당신이 C보다 나은 언어를 만드는 중이라면, 원래의 오픈서버 컴파일러가 libgcc.a에서 그것들을 포함한 매우 다양한 C++프로그램들을 옳게 파싱하지 못하는 cc1plus를 만들 것이기 때문에 당신은 `make bootstrap'를 호출하는 것에 관해서 인스트럭션들을 따라야한다. 만약 당신이 네이티브 컴파일러와 함께 만드는 중이라면 `make bootstrap'를 꼭 사용해야 한다.
Use of the `-march-pentiumpro' flag can result in
unrecognized opcodes when using the native assembler. While
it's rather rare to see these emitted by GCC yet, errors of the basic form:
/usr/tmp/ccaNlqBc.s:22:unknown instruction: fcomip /usr/tmp/ccaNlqBc.s:50:unknown instruction: fucomip
`-march-pentiumpro' 플래그의 사용은 네이티브 어셈블러를 사용할 때 인식되지 않는 opcode들로 결과를 낼수 있다. GCC에 의해 생략된 이러한 것들을 보는 것은 거의 쉬운 일이 아니지만, 기본 에러의 폼은 다음과 같다:
/usr/tmp/ccaNlqBc.s:22:unknown instruction: fcomip /usr/tmp/ccaNlqBc.s:50:unknown instruction: fucomip
are symptoms of this problem. You may work around this by not building affected files with that flag or by using the GNU assembler. Users of GNU assembler should see the note below for hazards on doing so.
은 이러한 문제의 증상이다. GNU 어셈블러를 사용함으로써 또는 이러한 플래그와 함께 영향을 받는 파일들을 컴파일(build)하지 않음으러써 당신은 이 문제를 해결할 수 있다. GNU 어셈블러 유저들은 이러한 위험을 위해서 아래와 같은 주의를 보아야 한다.
If you choose to configure with --enable-shared you should also
specify --with-gnu-as --disable-multilib even if you are not
using the GNU assembler. In doing so you will give up the ability
to generate COFF executables as described below. This combination
of flags is necessary to suppress negative interactions with multilibing.
만약 당신이 --enable-shared와 함께 환경설정(configuration)을 한하면, 당신은 비록 GNU 어셈블러를 사용하지 않는다 할지라도 --with-gnu-as --disable-multilib를 써주어야 한다. 그렇게 함으로써 아래에 기술된 대로 실행되는 COFF를 만들 수 있는 능력을 포기하게 될 것이다. 이러한 플래그의 조화는 다중 바인딩으로 인한 부정적인 상호작용을 억제하기 위해서 필요하다
The native SCO assembler that is provided with the OS at no charge
is normally required. If, however, you must be able to use the GNU
assembler you may configure this package using the flags --with-gnu-as.
You must use a recent version of GNU binutils; version 2.9.1 seems to work well.
If you select this option, you will be unable to reliably build COFF
images. In general, the --with-gnu-as option isn't as well tested as the native assembler.
OS함게 무료로 제공되는 네이티브 SCO어셈블러는 보통 필요하다. 그러나 만약 당신이 GNU 어셈블러를 사용할 수 있어야만 한다면, --with-gnu-as 플래그를 사용함으로써 이 패키지를 설정할 수 있다. 당신은 GNU binutils의 가장 최신 버전을 사용해야만 한다; 버전 2.9.1에서 잘 작동한다. 만약 당신이 이 옵션을 사용한다면, 당신은 믿을 수 있게 COFF 이미지를 만들 수 없을 것이다. 일반적으로, --with-gnu-as 옵션은 네이티브 어셈블러로써 테스트 되어질 수 없다.
Unlike various prereleases of GCC that used -belf and
defaulted to COFF, you must now use the -melf and
-mcoff flags to toggle between the two object file formats.
ELF is now the default.
사용되는 -belf과 COFF를 디폴트로 사용하는 미래의 버전의 GCC와는 다르게, 우리는 두개의 오프젝트 파일 포맷 사이를 매어주기(toggle) 위해서는 현재 -melf 플래그와 -mcoff 플래그를 사용해야한다. ELF는 디폴트이다
Look in gcc/config/i386/sco5.h (search for "messy") for additional OpenServer-specific flags.
추가적인 OpenServer-specific 플래그를 위해서 gcc/config/i386/sco5.h ("messy" 찾아보기) 를 살펴보기 바란다.
Systems based on OpenServer before 5.0.4 (`uname -X' will
tell you what you're running) require TLS597 from ftp.sco.com/TLS for
C++ constructors and destructors to work right.
Systems based on OpenServer before 5.0.4 버전(`uname -X' 는 당신에게 무엇이 돌아가고 있는지 말해줄것이다)이전의 OpenServer를 기반으로한 시스템은 올바르게 움직이는 C++ 컨스트럭터와 디컨스트럭터를 위해서 ftp.sco.com/TLS에 있는 TLS597을 필요로 한다.
The system linker in (at least) 5.0.4 and 5.0.5 will sometimes do the wrong thing for a construct that GCC will emit for PIC code. This can be seen as execution testsuite failures when using -fPIC on 921215-1.c, 931002-1.c, nestfunc-1.c, and gcov-1.c. For 5.0.5, an updated linker that will cure this problem is available. You must install both ftp://ftp.sco.com/Supplements/rs505a/ and OSS499A.
버전 5.0.4와 5.0.5에 있는 시스템 링커는 GCC가 PIC code를 위해 만드는 컨스트럭트 부분에서 때때로 이상하게 작동하는 것을 볼 수 있다. 이것은 921215-1.c, 931002-1.c, nestfunc-1.c, and gcov-1.c위에서 -fPIC을 사용할 때 실행 테스트슈트 실패로써 보여질 수 있다. 5.0.5에 있어서, 이러한 문제를 고친 것을 사용할 수 있다. 당신은 ftp://ftp.sco.com/Supplements/rs505a/ 과 OSS499A에서 받아 이것을 설치해야한다.
The dynamic linker in OpenServer 5.0.5 (earlier versions may show
the same problem) aborts on certain g77-compiled programs. It's particularly
likely to be triggered by building Fortran code with the -fPIC
flag.
Although it's conceivable that the error could be triggered by other
code, only G77-compiled code has been observed to cause this abort.
If you are getting core dumps immediately upon execution of your
g77 program - and especially if it's compiled with -fPIC - try applying
`sco_osr5_g77.patch' to your libf2c and
rebuilding
GCC. Affected faults, when analyzed in a debugger, will show a stack
backtrace with a fault occurring in rtld() and the program
running as /usr/lib/ld.so.1. This problem has been reported to SCO engineering
and will hopefully be addressed in later releases.
OpenServer 5.0.5(이전버전에서는 같은 문제를 볼 수 있을 것이다)에서 동적 링커는 어떤 g77에서 컴파일된 프로그램에서 실패했다. 그것은 특별히 -fPIC 플래그와 함께 사용되는 Fortran 코드를 컴파일(build)함으로 야기되기 쉽다. 비록 다른 코드로인해 에러가 야기되는 것으로 생각할 수 있지만, 오직 G77에서 컴파일된 코드에서 이러한 실패를 가져오는 것을 관찰할 수 있었다. 만약 당신이 g77 프로그램의 실행위에 즉시 코어 덤프를 얻게 된다면, 그리고 특별하게 그것이 -fPIC - try과 함께 libf2c와 GCC의 재컴파일을 위해서 `sco_osr5_g77.patch'을 적용하여 컴파일 되었다면, 영향받은 잘못이 디버거에서 분석했을때 /usr/lib/ld.so.1로써 프로그램을 돌릴때와 rtld()에서 폴트와 함께 일어나는 스택 백트레이스를 볼 것이다. 이 프로그램은 SCO 엔지니어링에 리포트되어 있고 후에 릴리즈에서 언급되어질 것이다.
GCC 2.95.2, when configured to use the GNU assembler, would invoke
it with the -s switch, that GNU as up to 2.9.5.0.12 does
not support. If you'd rather not use a newer GNU as nor the native
assembler, you'll need the patch `x86-sol2-gas.patch'.
GNU 어셈블러를 사용하기 위한 설정으로 GCC 2.95.2는 -s 스위치와 함께 그것을 부를수 있다. 2.9.5.0.12버전 GNU에서는 지원하지 않는다. 만약 당신이 더 새로운 GNU를 사용하지 않거나 네이티브 어셈블러를 사용하지 않는다면 패치 `x86-sol2-gas.patch'를 할 필요가 있다.
This target emulates the SCO Universal Development Kit and requires that
package be installed. (If it is installed, you will have a /udk/usr/ccs/bin/cc file present.) It's very much like the i?86-*-unixware7* target
but is meant to be used when hosting on a system where UDK isn't the
default compiler such as OpenServer 5 or Unixware 2. This target will
generate binaries that will run on OpenServer, Unixware 2, or Unixware 7,
with the same warnings and caveats as the SCO UDK.
이 타겟 머신에서는 SCO Universal Development Kit을 에뮬레이트하고 설치된 패키지를 요구한다.
(만약 그것이 설치되어있다면, 당신은 /udk/usr/ccs/bin/cc 화일을 가지고 있을 것이다.)
이것은 i?86-*-unixware7*을 매우 비슷하지만 OpenServer 5 또는 Unixware 2과 같이
UDK가 디폴트 컴파일러가 아닌 시스템에 호스팅할때 사용하지 않으면 안된다. 이 타겟머신은 SCO UDK로써의 같은 경고(same warnings and caveats)와 함께
OpenServer, Unixware 2, 또는 Unixware 7에서 실행되는 바이너리를 만들어낼 것이다.
You can stage1 with either your native compiler or with UDK. If you don't do a full bootstrap when initially building with your native compiler you will have an utterly unusable pile of bits as your reward.
당신은 네이티브 컴파일러나 UDK를 가지고 스테이지1을 할 수 있다. 만약 초기에 자신의 네이티브 컴파일러와 함께 컴파일(build)할때 풀 부트스트랩하지 않는다면, 결과로써 전혀 사용할 수 없는 비트의 더미를 가지게 될 것이다.
This target is a little tricky to build because we have to distinguish it from the native tools (so it gets headers, startups, and libraries from the right place) while making the tools not think we're actually building a cross compiler. The easiest way to do this is with a configure command like this:
CC=/udk/usr/ccs/bin/cc /your/path/to/gcc/configure --host=i686-pc-udk --target=i686-pc-udk --program-prefix=udk-번역이 잘 안되는 부분이네요 ^^;
This target is a little tricky to build because we have to distinguish it from the native tools (so it gets headers, startups, and libraries from the right place) while making the tools not think we're actually building a cross compiler. The easiest way to do this is with a configure command like this:
CC=/udk/usr/ccs/bin/cc /your/path/to/gcc/configure --host=i686-pc-udk --target=i686-pc-udk --program-prefix=udk-
You should substitute 'i686' in the above command with the appropriate processor for your host.
당신의 호스트를 위해 적절한 프로세서와 함께 위에 커맨드에 'i686'을 써어 넣어야 한다.
You should follow this with a `make bootstrap' then
`make install'. You can then access the UDK-targeted GCC
tools by adding udk- before the commonly known name. For example, to invoke the C compiler, you would use `udk-gcc'. They will coexist peacefully with any native-target GCC tools you may have installed.
`make bootstrap' 그 후에 `make
install'라는 명령을 해야한다. 보통 알려진 이름전에 udk-을 추가함으로써
UDK 타겟의 GCC 툴들을 액세스할 수 있다. 예를 들면, C 컴파일러를 호출하기 위해서 당신은 `udk-gcc'을 사용할 것이다.
그것들은 당신이 설치했을 어떤 네이티브와 타겟(native-target) GCC가 함께 평화적으로 존재할 것이다.
AIX Make frequently has problems with GCC makefiles. GNU Make 3.76 or newer is recommended to build on this platform.
AIX Make는 GCC 메이크화일과 함께 빈번히 문제를 일으킨다. GNU Make 3.76 또는 더 새로운 버전은 이 플랫폼에서 만들것을 권장한다.
Errors involving "alloca" when building GCC generally are due to an incorrect definition of CC in the Makefile or mixing files compiled with the native C compiler and GCC. During the stage1 phase of the build, the native AIX compiler must be invoked as "cc" (not "xlc"). Once configure has been informed of "xlc", one needs to use "make distclean" to remove the configure cache files and ensure that $CC environment variable does not provide a definition that will confuse configure. If this error occurs during stage2 or later, then the problem most likely is the version of Make (see above).
일반적이로 GCC 컴파일(build)할때 "alloca"를 포함하는 에러들은 Makefile에서 CC의 잘못된 정의때문이거나 네이티브 C 컴파일러와 GCC와 함께 컴파일된 혼합된 파일들때문이다. build의 스테이지1 과정동안에, 네이티브 AIX 컴파일러는 반드시 "xlc"가 아니라 "cc"로써 호출되어야한다. 단지 configure는 "xls"에 의해 통지를 받기 때문에, 환경설정(configure) 캐쉬 파일제거하기 위해서 그리고 $CC 환경변수가 configure시에 혼란을 일으키는 정의를 제공하지 않기 위해서 "make distclean"를 사용해야 한다. 만약 이 에러가 스테이지 2 나 그 후에 발생한다면, 문제는 대부분 Make 버전때문일 것이다.
Some versions of the AIX binder (linker) can fail with a relocation overflow severe error when the -bbigtoc option is used to link GCC-produced object files into an executable that overflows the TOC. A fix for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is available from IBM Customer Support and from its service.boulder.ibm.com website as PTF U455193.
TOC을 넘치게하는(overflow) 실행할 수 있는 것속으로 GCC가 만든 오브젝트 화일들을 링크하기 위해서 -bbigtoc 옵션을 사용할때, AIX 바인더(링커)의 몇몇 버전은 리로케이션(relocation)과 함께 실패할 수 있다. APAR IX75823(GCC와 -BBIGTOC를 사용할 때, 링크하는 동안의 오버플로우)를 위한 고침은 그것의 service.boulder.ibm.com 웹 사이트에서 PTF U455193으로써 사용가능하며 IBM 소비자 지원에서 사용가능하다.
Binutils does not support AIX 4.3 (at least through release 2.9). GNU as and GNU ld will not work properly and one should not configure GCC to use those GNU utilities. Use the native AIX tools which do interoperate with GCC.
Binutils은 (적어도 2.0 release 이하에서) AIX 4.3을 지원하지 않는다. GNU와 GNU ld는 적절히 작동하지 않을 것이며 GNU 유틸들을 사용하기 위해 GCC configure를 할수없다. GCC와 상호작용하는 네이티브 AIX 툴들을 사용하여야 한다.
AIX 4.3 utilizes a new "large format" archive to support both 32-bit and 64-bit object modules. The routines provided in AIX 4.3.0 and AIX 4.3.1 to parse archive libraries did not handle the new format correctly. These routines are used by GCC and result in error messages during linking such as "not a COFF file". The version of the routines shipped with AIX 4.3.1 should work for a 32-bit environment. The -g option of the archive command may be used to create archives of 32-bit objects using the original "small format". A correct version of the routines is shipped with AIX 4.3.2.
AIX 4.3는 32-bit와 64-bit 오브젝트 모듈을 다 지원하기 위해서 새로운 "큰 포맷(large format)"을 이용한다. 아카이브 라이브러리를 파싱하기 위해서 AIX 4.3.0과 AIX 4.3.1에서 제공하는 루틴은 올바르게 새로운 포맷을 핸들링하기 못했다. 이러한 루틴들은 GCC에 의해 사용되며 링킹동안에 "not a COFF file"와 같은 에러 메세지들을 결과로 얻게 된다. AIX 4.3.1 과 함께 나오는 버전의 루틴들은 32-bit 환경을 위해서만 사용되어야한다. 아카이브 커맨드중에 -g옵션은 원래의 "small format"을 사용하는 32-bit 오브젝트의 아카이브를 만드는데 주로 사용되어진다. 바른 버전의 루틴들은 AIX 4.3.2에 들어있다.
The initial assembler shipped with AIX 4.3.0 generates incorrect object files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS TO ASSEMBLE/BIND) is available from IBM Customer Support and from its service.boulder.ibm.com website as PTF U453956. This fix is incorporated in AIX 4.3.1 and above.
AIX 4.3.0에 들어있는 초기의 어셈블러는 잘못된 오브젝트 화일들을 만들어낸다. APAR IX74254를 위한 수정(64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS TO ASSEMBLE/BIND)은 IBM 고객지원이나 그것의 service.boulder.ibm.com 웹사이트에서 PTF U453956로써 받을 수 있다. 이 수정은 AIX 4.3.1이나 그 이상의 것과 상호작용(??)되어 지지 않는다.
The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core with a segmentation fault when invoked by any version of GCC. A fix for APAR IX87327 is available from IBM Customer Support and from its service.boulder.ibm.com website as PTF U461879. This fix is incorporated in AIX 4.3.3 and above.
AIX 4.3.2.1 링커(bos.rte.bind_cmds Level 4.3.2.1)는 어떤 버전의 GCC에서 호출되어질때 세그먼트 오류와 함께 코어덤프(core dump)가 일어날 것이다. APAR IX87327를 위한 수정은 IBM 고객지원이나 그것의 service.boulder.ibm.com 웹사이트에서 PTF U461879로써 받을 수 있다. 이 수정은 AIX 4.3.3 이나 그 이상의 것과 상호작용되어 지지 않는다.
You absolutely must use GNU sed and GNU make on this platform.
당신은 이 플랫폼에서 GNU sed와 GNU make를 절대적으로 사용해야만 한다.
On NEXTSTEP 3.x where x < 3 the build of GCC will abort during stage1 with an error message like this:
_eh /usr/tmp/ccbbsZ0U.s:987:Unknown pseudo-op: .section /usr/tmp/ccbbsZ0U.s:987:Rest of line ignored. 1st junk character valued 95 (_).
NEXTSTEP 3.x 위에서 where x < 3 the build of GCC will abort during stage1 with an error message like this:
_eh /usr/tmp/ccbbsZ0U.s:987:Unknown pseudo-op: .section /usr/tmp/ccbbsZ0U.s:987:Rest of line ignored. 1st junk character valued 95 (_).
The reason for this is the fact that NeXT's assembler for these versions of the operating system does not support the .section pseudo op that's needed for full C++ exception functionality.
이와 같은 이유는 이버전의 운영체계를 위한 NeXT의 어셈블러가 전체의 C++ 예외처리 함수들을 위해 필요한 .section pseudo op를 지원하지 않기 때문이다.
As NeXT's assembler is a derived work from GNU as, a free replacement that does can be obtained at ftp://ftp.next.peak.org:/next-ftp/next/apps/devtools/as.3.3.NIHS.s.tar.gz.
NeXT's 어셈블러는 GNU로부터 파생된 작업이기 때문에, 사용할수 있는 무료 대체(replacement)는 ftp://ftp.next.peak.org:/next-ftp/next/apps/devtools/as.3.3.NIHS.s.tar.gz 로부터 얻을 수 있다.
If you try to build the integrated C++ & C++ runtime libraries on this system you will run into trouble with include files. The way to get around this is to use the following sequence. Note you must have write permission to the directory prefix you specified in the configuration process of GCC for this sequence to work.
cd bld-gcc make all-texinfo all-bison all-byacc all-binutils all-gas all-ld cd gcc make bootstrap make install-headers-tar cd .. make bootstrap3
만약 이 시스템에서 통합된 C++ & C++ 런타임 라이브러리를 만들고 싶다면 인클루드(include) 화일들과 함께 문제에 봉착하게 될 것이다. 이러한 문제를 해결하는 방법은 다음과 같이 따라하는 것이다. 이러한 순차적 작업을 위해서 GCC 환경설정(configuration) 과정에서 가르키는 prefix디렉토리에 대한 퍼미션을 가지고 있어야함을 주의해라.
cd bld-gcc make all-texinfo all-bison all-byacc all-binutils all-gas all-ld cd gcc make bootstrap make install-headers-tar cd .. make bootstrap3
It is reported that you may need the GNU assembler on this platform.
이 플랫폼에서의 GNU어셈블러가 필요하다고 보고되고 있다.
You must use GAS on these platforms, as the native assembler can not handle the code for exception handling support. Either of these messages indicates that you are using the MIPS assembler when instead you should be using GAS:
as0: Error: ./libgcc2.c, line 1:Badly delimited numeric literal .4byte $LECIE1-$LSCIE1 as0: Error: ./libgcc2.c, line 1:malformed statement
네이티브 어셈블러가 예외처리 지원을 위한 코드를 다루지 못하기 때문에 이 플랫폼에서는 GAS를 반드시 사용해야한다. GAS를 사용하지 않을때 이러한 메세지는 당신이 MIPS 어셈블러를 사용하고 있다는 것을 의미한다:
as0: Error: ./libgcc2.c, line 1:Badly delimited numeric literal .4byte $LECIE1-$LSCIE1 as0: Error: ./libgcc2.c, line 1:malformed statement
or:
as0: Error: /src/bld-gcc/gcc/libgcc2.c, line 1:undefined symbol in expression .word $LECIE1-$LSCIE1
또는:
as0: Error: /src/bld-gcc/gcc/libgcc2.c, line 1:undefined symbol in expression .word $LECIE1-$LSCIE1
These systems don't have ranlib, which various components in GCC need; you should be able to avoid this problem by installing GNU binutils, which includes a functional ranlib for this system.
이 시스템은 ranlib를 가지고 있지 않다. ranlib는 GCC의 여러가지 컴포넌트들이 필요로 하는 것이다: 당신은 이 시스템을 위한 기능적인 ranlib를 포함하고 있는 GNU binutil들을 설치함으로써 이러한 문제를 해결할 수 있어야 한다.
You may get the following warning on irix4 platforms, it can be safely ignored.
warning: foo.o does not have gp tables for all its sections.
irix4 플랫폼에서 당신은 안전하게 무시될 수 있는 다음과 같은 경고를 받게 될 것이다.
warning: foo.o does not have gp tables for all its sections.
When building GCC, the build process loops rebuilding cc1 over and
over again. This happens on mips-sgi-irix5.2, and possibly other platforms.
It has been reported that this is a known bug in the make shipped with
IRIX 5.2. We recommend you use GNU make instead of the vendor supplied
make program; however, you may have success with "smake" on IRIX 5.2 if
you do not have GNU make available.
GCC를 컴파일(building)할 때, 컴파일 과정은 cc1을 다시 컴파일 하는 것을 계속반복한다.
GCC, mips-sgi-irix5.2 시스템에서 이 과정은 일어나며, 다른 플랫폼에서도 일어날 수 있다.
이버그는 IRIX 5.2에 들어있는 메이크(make)의 알려진 버그라고 보고되어 있다.
우리는 다른 밴더의 make 프로그램을 사용하는 대신 GNU make를 사용하기를 요구한다.
그러나 만약 당신이 사용가능한 GNU make를 가지고 있지 않다면 IRIX 5.2에 있는 "smake"를
사용하여 성공할 수도 있을 것이다.
See http://reality.sgi.com/ariel/freeware for more information about using GCC on IRIX platforms.
IRIX 플랫폼에서의 GCC 사용에 대한 더 많은 정보가 필요하다면 http://reality.sgi.com/ariel/freeware/을 보면된다.
You must not use GAS on irix6 platforms; doing so will only cause problems.
당신은 irix6 플랫폼에서 GAS를 사용해야만 하지 않아야한다; 그렇게 함으로 문제를 일으키게 될 것이다.
These systems don't have ranlib, which various components in GCC need; you should be able to avoid this problem by making a dummy script called ranlib which just exits with zero status and placing it in your path.
이 시스템은 GCC에서의 여러가지 컴포넌트들이 필요로 하는 ranlib를 가지고 있지 않다; 당신은 영과 함께 죽는(exit) ranlib를 호출하는 더미 스크립트를 만들고 이를 당신의 path에 위치시킴으로써 문제를 해결할 수 있어야한다.
If you are using Irix cc as your bootstrap compiler, you must
ensure that the N32 ABI is in use. To test this, compile a simple C
file with cc and then run file on the
resulting object file. The output should look like:
test.o: ELF N32 MSB ...
test.o: ELF 32-bit MSB
cc uses the O32 ABI default. You
should set the environment variable CC to 'cc -n32'
before configuring GCC.
만약 당신의 부트스트랩 컴파일러로써 irix cc를 쓰고 있는 중이라면, N32 ABI의 사용을 보장해야만 한다.
이것을 테스트 해보기 위해서, cc를 이용하여 간단한 C 화일을 컴파일하고, 결과로 나온 오브젝트 화일을
실행해보라. 출력이 다음과 같아야 한다:
test.o: ELF N32 MSB ...
test.o: ELF 32-bit MSB
cc의 버전이 기본적으로 O32 ABI를 사용하고 있다는 것이다. 당신은 GCC를 설정하기 전에
환경변수 CC를 'cc -n32'로 설정해야만 한다.
GCC does not currently support generating O32 ABI binaries in the mips-sgi-irix6 configurations. It used to be possible to create a GCC with O32 ABI only support by configuring it for the mips-sgi-irix5 target. See the link below for details.
mips-sgi-irix6설정에서 GCC는 O32 ABI를 만드는 것을 현재 지원하지 않고 있다. 타겟을 mips-sgi-irix5로 설정함으로써 O32 ABI지원과 함께 GCC를 만드는 것을 가능하게 할 수 있다. 자세한 내용은 아래 링크를 참조하세요.
GCC does not correctly pass/return structures which are smaller than 16 bytes and which are not 8 bytes. The problem is very involved and difficult to fix. It affects a number of other targets also, but IRIX 6 is affected the most, because it is a 64 bit target, and 4 byte structures are common. The exact problem is that structures are being padded at the wrong end, e.g. a 4 byte structure is loaded into the lower 4 bytes of the register when it should be loaded into the upper 4 bytes of the register.
GCC는 16 byte보다 작거나 8 byte가 아닌 구조체를 올바르게 패스(pass)하거나 리턴(return)할 수 없다. 이 문제는 매우 복잡하며 해결하기 어렵다. 이 문제는 많은 다른 플랫폼에서도 영향을 미친다. IRIX 6에서는 대체로 문제를 일으킨다. IRIX 6이 64bit 타겟이며, 4 byte 구조체를 사용하기 때문이다. 정확한 문제는 구조체에 잘못된 끝부분에 패딩(padding)되어지기 때문이다. 예를 들면, 4 byte의 구조체가 레지스터의 상위 4byte에 로딩되어야 할때, 레지스터의 하위 4byte에 로딩이 된다는 것이다.
GCC is consistent with itself, but not consistent with the SGI C compiler (and the SGI supplied runtime libraries), so the only failures that can happen are when there are library functions that take/return such structures. There are very few such library functions. I can only recall seeing two of them: inet_ntoa, and semctl.
GCC는 스스로 일관성을 가지지만, SGI C 컴파일러(그리고 SGI를 지원하는 런타임 라이브러리들)과 함께 일관성을 가지지는 못한다. 그래서, 그런 구조체를 가져오거나 돌려놓는 라이브러리 함수들이 있을때 단지 이런 문제가 일어난다. 그런 라이브러리가 아주 적다. 나는 단지 아래중의 두개만 봤던 것을 기억할 수 있다: inet_ntoa, and semctl.
See http://reality.sgi.com/ariel/freeware for more information about using GCC on IRIX platforms.
IRIX 플랫폼에서 GCC 사용에 관한 더 많은 정보는 http://reality.sgi.com/ariel/freeware/에서 얻을 수 있다.
You will need binutils-2.9.4.0.8 or newer for a working GCC. It is strongly recommended to recompile binutils if you initially built it with gcc-2.7.2.x.
GCC 작업을 위해서 binutils-2.9.4.0.8나 그 이상의 버전이 필요하게 될 것이다. 만약 초기에 gcc-2.7.2.x.과 함께 그것을 컴파일(build)했다면, 다시 binutil들을 재컴파일하기를 강하게 권장한다.
Starting with Solaris, Sun does not ship a C compiler any more. To bootstrap and install GCC you first have to install a pre-built compiler, see our binaries page for details.
Solaris로 시작할때, Sun은 더 이상 C 컴파일러를 포함하지 않는다. GCC를 부트스트랩하고 설치하기 위해서 먼저 여벌컴파일(pre-build)된 컴파일러를 설치 해야만 한다. 자세한 내용은 binaries page를 참고하라.
Sun as 4.X is broken in that it cannot cope with long symbol names. A typical error message might look similar to the following:
/usr/ccs/bin/as: "/var/tmp/ccMsw135.s", line 11041: error: can't compute
value of an expression involving an external symbol.
Sun 4.X는 긴 심볼이름에 대처할 수 없게 되어있다. 전형적인 에러 메세지는 다음과 비슷할 것이다:
/usr/ccs/bin/as: "/var/tmp/ccMsw135.s", line 11041: error:
can't compute value of an expression involving an external symbol.
See the How to work around too long C++ symbol names? FAQ entry for further information.
더 많은 정보를 위해 How to work around too long C++ symbol names? FAQ 엔트리에서 볼 수 있다.
Sun make in all known Solaris 1 (SunOS 4) and Solaris 2 releases has a broken VPATH mechanism, which means you must either:
Solaris 1 (SunOS 4) 과 Solaris 2 releases에서의 Sun make는 깨진 VPATH 매커니즘을 가지고 있다, 이것은 다음 중에 하나를 의미한다:
binutils 2.9.1 has known bugs on this platform. We recommend to use the vendor tools (Sun as, Sun ld) until these have been fixed. Unfortunately, C++ shared libraries, including libstdc++, won't work properly if assembled with Sun as: the linker will complain about relocations in read-only sections, in the definition of virtual tables. Some possible work-arounds: use some development release of binutils, wait for the next stable binutils release or refrain from creating C++ shared libraries.
이 플랫폼에서 binutils 2.9.1은 버그가 있다고 알려져 있다. 이 버그가 고쳐지기 전까지 밴더 툴(Sun as, Sun ld)들을 사용하기를 권장한다. 불행하게도, Sun에서 어셈블한다면 libstdc++를 포함한 C++ 공유 라이브러리가 바르게 동작하지 않을 것이다: 링커는 읽기전용 공간, 가상 테이블 정의에서의 리로케이션에 관해 문제를 일으킬 것이다. 몇몇 가능한 방법: 몇몇의 binutil들의 개발 버전을 사용하거나, 다음 안정적인 binutil을 기다리면 된다, 또는 만들어진 C++공유 라이브러리들을 사용하지 않으면 된다.
Sun patch 107058-01 (1999-01-13) for SPARC Solaris 7 triggers a bug in the dynamic linker. This problem (Sun bug 4210064) affects GCC 2.8 and later, including all EGCS releases. Sun formerly recommended 107058-01 for all Solaris 7 users, but around 1999-09-01 it started to recommend it only for people who use Sun's compilers.
SPARC Solaris 7을 위한 Sun patch 107058-01(1999-01-13)는 동적링커에서 버그를 일으킨다. 이 문제(Sun bug 4210064)는 GCC 2.8 나 모든 EGCS release를 포함하여 그 이후에 버전의 GCC에 영향을 미친다. Sun은 모든 Solaris 7 사용자들을 위해 107058-01를 권장한다. 그러나 , 1999-09-01정도에 Sun의 컴파일러를 사용하고 있는 사람들을 위해 권장되기 시작했다.
Here are some workarounds to this problem:
이 문제를 해결하는 방법에는 몇가지가 있다:
/usr/ccs/bin/as into
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/as,
adjusting the latter name to fit your local conventions and software
version numbers./usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/as에서 /usr/ccs/bin/as로
패치되지 않은 Solaris 7을 복사해라. 당신의 습관들이나 소프트웨어 버전에 따라 후자의 이름을 변경해서 해야한다.A bug in the SunOS4 linker will cause it to crash when linking -fPIC compiled objects (and will therefore not allow you to build shared libraries).
SunOS4 링커에서의 버그는 -fPIC로 링킹되어 컴파일된 오브젝트에서 충돌을 야기시킨다 (그리고 공유메모리 만드는 것을 허용하지 않게된다).
To fix this problem you can either use the most recent version of binutils or get the latest SunOS4 linker patch (patch ID 100170-10) from Sun's patch site.
이 문제의 해결을 위해서 당신은 가장 최신 버전의 binutil들을 사용하거나 Sun의 패치 사이트로부터 최근의 SunOS4 linker patch (patch ID 100170-10)를 가져와서 사용해야 한다
It has been reported that you might need binutils-2.8.1.0.23 for this platform, too.
이 플랫폼에서도 사용하기 위해 binutils-2.8.1.0.23이 역시 필요하다고 보고 되었다.
GCC version 2.95 is not able to compile code correctly for
sparc64 targets. Users of the Linux kernel, at least,
can use the sparc32 program to start up a new shell
invocation with an environment that causes configure to
recognize (via uname -a) the system as
sparc-*-* instead.
GCC 버전 2.95는 sparc64 타겟으로 바르게 코드를 컴파일 할 수 없다.
적어도 리눅스 커널의 사용자들은 sparc32 프로그램을 사용할 수 있다.
sparc32 프로그램은 (via uname -a) 대신에 sparc-*-*로써
시스템을 인식시키기 위해 configure가 작동하게 하는 환경과 새로운 쉘 호출을 시작시키기 위해
사용된다.
GCC does not currently support Windows, either natively or with the cygwin32 dll, but there are some links on our binaries page.
GCC는 현재 Windows뿐만 아니라 the cygwin32 dll을 지원하지 않는다. 그러나, 몇몇 링크들을 이 binaries page에서 볼 수 있다.
GCC does not currently support OS/2. However, Andrew Zabolotny has been working on a generic os/2 port with pgcc. The current code code can be found at http://www.goof.com/pcg/os2/.
GCC는 현재 OS/2를 지원하지 않는다. 그러나, Andrew Zabolotny는 pgcc를 가진 일반적인 os/2 port에서 작업하고 있다. 현재 코드는 http://www.goof.com/pcg/os2/ 에서 볼 수 있다.
C++ support is significantly better on ELF targets if you use the GNU linker; duplicate copies of inlines, vtables and template instantiations will be discarded automatically.
만약 GNU링커를 사용하고 있다면 C++ 지원은 다른 플랫폼에서 두드러지게 나아지고 있다; duplicate copies of inlines, vtables,template instantiations 이 자동적으로 없어지고 있다.