Upgrading GCC/ko

이 문서는 사용자를 GCC 업그레이드 과정으로 안내합니다.

도입부
GCC "업그레이드"에 대한 내용입니다. GCC를 다운그레이드 하면 원치 않는 부작용이 생길 수 있습니다. 일반적으로 보고된 문제에 대한 문제 해결 섹션을 참고하십시오.

다음 섹션에서는 GCC 업그레이드(그리고 이게 얼마나 쉬운가!)에 대한 간단한 핵심 내용을 전달하겠습니다. GCC 업그레이드 전에 장황한 핑계(?)를 읽어보려 한다면, 자세한 내용의 GCC 업그레이드편으로 계속 진행하십시오.

간단한 버전
GCC를 업그레이드 한다면 컴파일러 버전을 바꾸고 libtool을 다시 빌드하는것 이외에는 필요한 일이 없습니다:

3.4.0 이전(3.x 버전대) 또는 4.1 버전대의 GCC 버전을 업그레이드 한다면, 업그레이드 후 를 실행해야 합니다:

Check the current version and uninstall the old version:

다 됐습니다. 컴파일러 자아알~ 쓰세요!

도입부
GCC upgrading has always been mystified, with suggestions ranging from "You do not need to do anything" up to "You will need to rebuild your entire system twice". Most of this fear, uncertainty and doubt comes from the confusion surrounding ABI incompatibility. But first a quick pointer towards.

libtool과 fix_libtool_files.sh
Earlier installments of GCC on Gentoo required you to run a specific command called. Some time ago, the execution of this command has been integrated in the package deployments itself (through the toolchain eclass) so there is no need for users to call this themselves anymore.

버전을 업그레이드 한 후 libtool을 다시 빌드해야 하는 이유는 주된 이유 하나 때문입니다. libtool은 공유 라이브러리의 플랫폼 기반 양상을 판단하기 위해 무언가를 처리할 필요 없이 공유 라이브러리를 통해 프로그램을 빌드할 수 있도록 하는 공통 인터페이스에서 플랫폼 관련 코드를 모으는 도구셋입니다. 이 기능 속성대로 동작하기 위해, 스크립트는 하드코딩한  버전을 보유한 다양한 라이브러리 위치를 각 위치에서 사용합니다.

ABI 변경
An ABI, or Application Binary Interface, is a set of conventions used by all tools that deal with binary representation of programs, including compilers, assemblers, linkers, and language runtime support (source: GCC Binary Compatibility). When the ABI used for binary applications and libraries is changed, you will risk getting linker errors or malfunctioning programs unless you rebuild all libraries that use C++ code.

예, 대부분의 비호환성은 C++ ABI에서 기인합니다. GCC 4.1 또는 5.1로 업그레이드한다면 몇가지 ABI 문제에 부딪힙니다. 때문에 (GCC 3에서 4.1로 업그레이드할 때) 또는 (GCC 4에서 5.1로 업그레이드할 때)에 대해  명령을 사용해야 합니다.

그래서 왜 GCC 3.4.0/4.1/5.1 이상에서만 필요할까요? 버전에 따른 이유인데, GCC는 프로그램과 라이브러리를 다시 빌드할 필요성을 제거한 차기 호환 ABI를 사용합니다. 물론 보증은 확실히 못하지만 비호환성이 또 발생하면 여기에 문서로 남겨놓도록 하겠습니다. 이 경우, 라이브러리의 버전은 증가할 것입니다.

특별한 경우 C++11(및 C++ 14)
GCC(또는 좀 더 구체적으로 libstdc++의 경우)가 최대한 ABI의 안정성을 추구하기를 보장하는데 반해, 보장 범위는 libstdc++의 모든 C++ 부분으로 확대되지는 않습니다. 보통, 3.4부터는 GCC/libstdc++는 C++98/C++03 ABI 안정성만을 보장하며 그 이상은 감당하지 않습니다. 이는 C++11에 관련된 꾸러미에게 결정적인 문제입니다. GCC는 5.1부터 C++11 ABI 안정성을 보장합니다. 무슨 얘기냐 하면, gcc 버전(4.7.3에서 4.7.4로 바꾼다고 해보죠)을 (마이너 버전일지라도) 바꾸면 C++11 코드에서 빌드한 바이너리의 ABI가 깨질 수 있단 의미입니다.

더 많은 내용은 다음을 참조하십시오:


 * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758
 * https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/
 * https://stackoverflow.com/questions/16190269/g-always-backward-compatible-with-older-static-libraries/16196475#16196475
 * https://stackoverflow.com/questions/16190269/g-always-backward-compatible-with-older-static-libraries/16196475#16196475

모두 다시 빌드
어떤 사람들은 새 GCC 버전이 동작하게 하려면 시스템의 모든 단일 꾸러미를 다시 빌드해야 한다고 주장합니다. 물론, 딱히 문제가 되는건 아니고, 어쨌듵 빌드 및 설치 과정에서 GCC를 사용하지 않는 프로그램이 많이 있기 때문에, 이런 바뀐 상황에 영향을 주진 않습니다.

그러나 이러한 주장은 확실히 잘못됐습니다: 새 GCC 버전은 일부 프로그램의 동작을 더 좋게 하는 프로세서 명령 셋을 종종 더 많이 지원합니다. 이런 개선사항이 잉여스러운 것 같지만, 어떤 경우에는(특히 CPU를 중점적으로 다루는 프로그램) 주목할만한 성능 향상을 보일 때도 있습니다.

There are also known cases where packages need to be built with the same compiler. Although these packages are usually bumped by package maintainers simultaneously (so that they are always built with the same GCC version) cherry-picking re-installs on these packages might prove to be troublesome. The various packages are a nice example on this matter.

libstdc++.so.6: `GLIBCXX_3.4.15' 버전을 찾을 수 없음
업데이트 하는 동안 다음과 같은 오류를 만날 수 있습니다:

이는 빌드한 의존 라이브러리보다 "오래된" GCC 버전으로 패키지를 빌드하려 함을 의미합니다. 차기 호환성이 있는 C++ ABI를 호출했음을 기억하십니까? 맞는 말이긴 한데, 프로그램을 빌드하고 라이브러리에 연결(이들 라이브러리를 빌드할때 사용한 GCC 버전과 비교했을 때)할 때는 "더 높은" GCC버전에 대해서만 동작이 보장됩니다.

libstdc++에 의존하는 모든 꾸러미를 다시 빌드하려면 이전의 revdep-rebuild 부분을 참고하십시오.

리빌드 해야 한다고 알려진 꾸러미는 무엇인지요?
다음 테이블에서 설치했을 경우 꾸러미 이름과 왜 다시 빌드해야 하는지를 보여줍니다.

추가 참조

 * Upgrade GCC up to 4.1, the previous version of this document
 * Upgrading from gcc-4.x to gcc-5.x
 * Fedora's 'Changes/GCC6' Wiki Page