Upgrading GCC

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Upgrading GCC and the translation is 13% complete.
Outdated translations are marked like this.
Other languages:

GCC upgrades should generally be handled gracefully with Portage and the usual Gentoo tools, see next section. If ever there are more involved updates that require user intervention, they should be accompanied by a corresponding news item, that should be read and followed.

Downgrading GCC might have unwanted side effects. Refer to the troubleshooting section for some commonly reported issues.

Quick guide to GCC upgrades

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

root #emerge --ask --oneshot sys-devel/gcc
root #emerge -u sys-devel/gcc
root #gcc-config -l
[1] i686-pc-linux-gnu-4.4.5 *
[2] i686-pc-linux-gnu-4.5.3
root #gcc-config 2
root #env-update && source /etc/profile
root #emerge --ask --oneshot sys-devel/libtool

현재 버전을 확인하고 이전 버전을 삭제하십시오:

root #gcc --version
root #emerge --ask --depclean =sys-devel/gcc-4.4.5

Enjoy the new compiler!

자세한 내용의 GCC 업그레이드

GCC 업그레이드는 "더이상 뭘 할 필요가 없다"부터 시작해서 "시스템 전체를 한번 더 빌드해야 한다"까지 여러가지로 햇갈립니다. 대부분의 두려움, 불확실성, 혼동은 ABI 비호환성으로 인한 혼동에서 옵니다. 그러나 우선 간편한 포인터에서는 libtool를 가리킵니다.

libtool과 fix_libtool_files.sh

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

See bug #88596.

ABI changes

ABI 변경

"Application Binary Interface"라고 하는 ABI는 컴파일러, 어셈블러, 링커, 언어 런타임 지원을 포함하는 프로그램의 바이너리 표현을 다루는 모든 도구에서 사용하는 관례(원본: GCC 바이너리 호환성en)입니다. 이진 프로그램과 라이브러리가 사용하던 ABI가 바뀌면 C++ 코드를 사용하는 모든 라이브러리를 다시 빌드하지 않는 한 프로그램이 링커 오류가 뜨거나 제대로 동작하지 않아 피해를 볼 수 있습니다.

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

root #revdep-rebuild --library 'libstdc\+\+.so.6' -- --exclude gcc

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

특별한 경우 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가 깨질 수 있단 의미입니다.

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

Downgrading GCC

For the aforementioned reasons, if downgrading GCC or choosing an older slot with gcc-config, it is necessary to run revdep-rebuild to catch libstdc++ consumers requiring newer symbols:

root #revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc

다시 빌드해야 하는 꾸러미는 무엇인지요?

다음 테이블에서 설치했을 경우 꾸러미 이름과 왜 다시 빌드해야 하는지를 보여줍니다.

꾸러미 다시 빌드해야 하는 이유 ...
sys-devel/libtool GCC 내부 라이브러리에 대해 libtool 프로그램 경로를 하드코딩 했음
sys-devel/llvm 정확히 gcc 버전에 따라, LLVM 을 활용하는 다른 ebuild(e.g. media-libs/mesa)를 다시 빌드하지 않으면 링크 에러가 나타남
root #emerge --ask --oneshot --usepkg=n --verbose dev-build/libtool

동일한 컴파일러로 빌드할 필요가 있는 꾸러미에 대해 몇가지 알려진 경우가 더 있습니다. 젠투 꾸러미 관리자가 보통 여러 꾸러미 버전을 동시에 올리긴 하지만(그래서 항상 동일한 GCC 버전으로 빌드합니다), 이 꾸러미를 따로 골라서 재설치하는 경우는 문제가 있음을 찾아볼 수 있습니다. 다양한 qt-* 꾸러미는 이러한 상황에 대한 바람직한 예입니다.

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

요령
This isn't necessary but is described here so people know how to do it thoroughly if they desire.

Some people swear that they need to rebuild every single package on their system when a new GCC version is made available. Of course, that doesn't make sense, since there are many applications that are not using GCC for their build and install process anyhow, so they would never be affected by such changes.

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

Apart from such "benign" benefits, rebuilding everything from scratch may be necessary in some cases to fix problems that don't seem to have any obvious cause.

Some software problems are inherently difficult to diagnose and yet could be solved by simply rebuilding one or more appropriate packages. If such a problem has arisen following a GCC upgrade and persists after using the revdep-rebuild approach described above (and after rebuilding any other obviously relevant packages), a complete system rebuild may be the answer.

The "safest" but slowest way to accomplish this is to use the --emptytree (-e) option of emerge to rebuild the system set and then the world set:

root #emerge --ask --emptytree --usepkg=n @system
root #emerge --ask --emptytree --usepkg=n @world

Try this approach before reporting bugs that might have been caused by a GCC upgrade.

참고
The commands above will cause the packages in the system set to be rebuilt twice, which is necessary to be absolutely certain that every package gets built in the same presumably "problem-free" environment. Any problems that remain after doing this are due to either "genuine bugs" that should be reported or poor system configuration.

문제 해결

Rebuild of Boost

If dev-libs/boost needs to be rebuilt, one will get the following error message:

root #emerge ... 
checking for the Boost _____ library... no
configure: error: cannot find the flags to link with Boost _____

One can rebuild with:

root #emerge --ask --oneshot --usepkg=n --verbose dev-libs/boost

libstdc++.so.6: `GLIBCXX_3.4.15' 버전을 찾을 수 없음

업데이트 하는 동안 다음과 같은 오류를 만날 수 있습니다:

코드 GLIBCXX_x.y.z를 찾을 수 없음
cmake_bootstrap_28021_test: /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/libstdc++.so.6:
version `GLIBCXX_3.4.11' not found

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

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

undefined reference to `__cxa_call_terminate@CXXABI_1.3.15'

This is usually a result of compiling a package that had its dependencies built with a newer GCC version than with the current one selected. An example output might be:

코드 undefined reference to __cxa_call_terminate@CXXABI_1.3.15
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libgtest.so: undefined reference to `__cxa_call_terminate@CXXABI_1.3.15'

What this means is the package that is emerging is building with, for example, GCC 13 but the package that provides libgtest.so was built with a newer version of GCC, 14 in this case.

The solution to this problem is rather simple but can be hard to figure out if the package providing the file is unknown. Portage supports emerging file paths directly so running emerge -1 /path/to/file.so might detect the file.

In the example, try emerging /usr/lib64/libgtest.so

root #emerge -1a /usr/lib64/libgtest.so
Calculating dependencies -
 
!!! '/usr/lib/libgtest.so' is not claimed by any package.
... done!

Unfortunately the file needed was not claimed, but another utility exists to find files installed by packages, Pfl. Using e-file, it is possible to find the package that installs the needed file.

user $e-file libgtest.so
...
[I] dev-cpp/gtest
        Seen Versions:          1.13.0 1.14.0
        Portage Versions:       1.13.0 1.14.0 9999
        Installed Versions:     1.14.0(Fri Nov 24 04:35:00 2023)
        Homepage:               https://github.com/google/googletest
        Description:            Google C++ Testing Framework
        Matched Files:          /usr/lib/libgtest.so; /usr/lib64/libgtest.so
...

In this case, dev-cpp/gtest is causing the build issue, re-merging it with:

root #emerge --ask --oneshot dev-cpp/gtest

should fix the issue and allow the continuation of emerging the original package.

참고
For larger packages, it is likely to encounter this more than once while rebuilding a package with a lower version of GCC, keep following the above steps to eventually succeed in recompiling the package with GCC 13

추가 참조

External resources

References

Retrieved from "https://wiki.gentoo.org/index.php?title=Upgrading_GCC/ko&oldid=1305968"