제가 이해한 바는 G++ 4.7.2의 C++11 지원이 그다지 좋지 않다는 것입니다(C++ 코드를 컴파일하려고 할 때마다 경고가 표시됩니다. 아마도 이러한 경고에는 그럴 만한 이유가 있을 것입니다). 새로운 것을 업데이트해 보세요.
다운로드 할당량이 많지 않아서 다운로드를 꼭 제한하고 싶기 때문에 꼭 build-essentials필요한 경우가 아니면 Debian stable(Wheezy)로 업그레이드하거나 업그레이드하고 싶지 않습니다.
apt-get적성 저장소에 이상한 작업을 수행하지 않고 최신 GCC 버전(또는 전체 C++11을 지원하는 모든 버전)을 사용할 수 있는 간단한 명령이 있습니까 ?
나는 여전히 전체 Linux 설치 프로세스를 파악하려고 노력 중이기 때문에 기존 설치를 덮어쓰는 실행 가능한 명령 형식으로 대답을 듣고 싶습니다.
답변1
패키지 관리는 "함께 속하는" 패키지 세트를 제공합니다. 배포판에 포함되지 않은 새로운 소프트웨어 세트를 설치하도록 속이려는 시도는 "잘 작동하지 않을" 수 있습니다. 일반적으로 발생하는 일은 업그레이드해야 하는 후속 패키지의 거대한 데이지 체인을 얻는 것입니다(예: "gcc에는 새 glibc가 필요하고, 새 glibc에는 새 binutil이 필요하며, 새 binutils는 gdb를 손상시키므로 업데이트해야 합니다. "" 등 ).
기존에 설치된 도구를 유지하는 것이 더 나은 솔루션이라는 것을 알았고 자체 gcc, llvm+clang, gdb, lldb 또는 더 높은 버전이 필요하다고 생각되는 모든 도구를 구축하는 것이 더 나은 솔루션이라는 것을 알았습니다. 일반적으로 이 작업은 /usr/local/{bin,lib,include,...}에 설치되고 distro 도구는 /usr/{bin,lib,include,..}에 설치되므로 문제 없이 작동합니다. in - 따라서 이전 버전을 사용해야 하는 경우(가끔 이런 경우가 발생합니다. 예를 들어 최신 gcc가 있는데 불행하게도 프로젝트 A 또는 그 자체를 컴파일할 수 없습니다) - /usr/bin/ gcc를 사용할 수 있습니다. /usr/local을 사용하지 않도록 $PATH를 편집하세요.
Fedora-16이 설치되어 있지만 gcc 4.8.2(3월 말 최신 버전) 및 clang 3.5를 사용하고 있습니다. 시스템과 함께 제공되는 기본 컴파일러는 gcc 4.6.3 및 clang 2.9입니다. Clang 3.5에는 C++11 호환 컴파일러가 필요하므로 이 프로젝트에는 4.7 또는 4.8이 필요합니다. 그것은 아주 잘 작동합니다. (그러나 새로운 gcc와 clang은 이전 gdb를 망가뜨려 기호가 예상대로 작동하지 않았기 때문에 gdb를 다시 빌드하거나 업그레이드해야 했습니다.)
답변2
올바른 방법은 백포팅을 사용하는 것입니다. 바라보다데비안이 제공하는 것보다 새로운 버전의 소프트웨어를 어떻게 설치하나요?배경. 불행하게도 이것은 "자동"이 아닙니다.
아래에서 그 과정을 간략하게 설명하겠습니다. 질문은 gcc 버전을 지정하지 않지만 4.9가 방금 릴리스되었으므로 이를 백포트하는 방법에 대한 설명으로 제한하겠습니다. 모든 백포트는 서로 다르며 서로 다른 문제를 가지고 있습니다. 보편적인 방법은 없습니다.
1) gcc 4.9 소스 코드를 하위 디렉터리(예: )에 다운로드합니다 gcc-4.9.
cd gcc-4.9
apt-get source gcc-4.9
2) 그런 다음
cd gcc-4.9-4.9.0/debian
3) 그런 다음 해당 debian/디렉토리를 버전 관리하에 두십시오. 나는 수은을 사용했다. 이는 선택적인 단계이지만 문제가 발생할 경우 유용합니다.
4) 이것을 복제하십시오Mercurial 저장소에는 Debian 패키징 파일용 패치가 포함되어 있습니다.저장소. debian/디렉터리 에 복제할 수 있습니다 . 즉
gcc-4.9/gcc-4.9-4.9.0/debian$ hg clone https://bitbucket.org/faheem/gcc-4.9-debian-mq
gcc-4.9/gcc-4.9-4.9.0/debian$ patch -p1 < gcc-4.9-debian-mq/debian
patching file control
patching file rules.defs
patching file source/format
4) 이제 빌드를 시도해 볼 수 있습니다. build-essential, fakeroot등 의 일부 패키지를 설치해야 합니다 devscripts.
debuild -uc -us
필요한 빌드 종속성이 없으면 실패할 수 있습니다. 따라서 설치하면 debuild무엇이 빠졌는지 알려줄 것입니다. 이 패치를 사용하면 wheezy에 대한 모든 종속성을 성공적으로 해결할 수 있습니다.
이 프로세스가 끝나면 디렉터리의 최상위 수준에 gcc debs가 표시되며 gcc-4.9Wheezy에 설치할 준비가 됩니다. 참고: 글을 쓰는 시점에는 이 내용을 확인하지 않았습니다. 아래를 참조하세요.
참고: 이 패치는 더 이상 작동하지 않을 수 있습니다
gcc-4.9. 참고로 이것이 제가 패치하는 버전입니다. 이것은 2014년 4월 22일에 gcc 4.9가 출시된 이후 첫 번째 데비안 패키지입니다.
$ apt-cache policy gcc-4.9
gcc-4.9:
Installed: (none)
Candidate: 4.9.0-1
Version table:
4.9.0-1 0
50 http://debian.lcs.mit.edu/debian/ unstable/main amd64 Packages
그래서 다른 사람들이 스스로 패치를 생성할 수 있도록 패치를 생성하는 방법에 대한 몇 가지 참고 사항을 추가했습니다. 이 글을 주의 깊게 읽어보시기 바랍니다. 특히, 주석 (6)(다중 아키텍처)은 자신만의 패치를 만들 계획이 없더라도 관심을 가질 수 있습니다.
1) 첫째, 빌드 종속성이 불안정하고 불필요하게 제한적입니다. 첫 번째는 빌드 종속성이 충족되도록 제약 조건을 약화시키는 것입니다. 그럼 먼저 시도해 보세요.
debuild -uc -us
debuild빌드 종속성이 설치되지 않았다고 불평합니다. 설치 후에도 debuild버전이 충분히 새롭지 않다고 불평합니다. 따라서 가장 쉬운 방법은 언급된 버전 번호를 제거하는 것입니다.
이에 대한 예로는 다양한 binutils, libcloog-isl-dev, 가 있습니다 libmpc-dev.
예를 들어 변경
libmpc-dev (>= 1.0),
도착하다
libmpc-dev,
파일 Build-Depends:상단의 줄에는 debian/control빌드 종속성 및 바이너리 패키지에 대한 정보가 포함되어 있습니다. 문제가 있는 모든 패키지에 대해 이 작업을 수행하고 필요한 빌드 패키지를 설치하면 데비안 빌드 시스템이 실행됩니다.
2) 당신이해야 할 또 다른 일은 쌍을 제거하는 것입니다
x32. 이는 Wheezy에는 적용되지 않습니다. 예를 들어 libc6-dev-x32패키지가 Wheezy에 존재하지 않습니다. debian/rules.defsx32에 대한 모든 언급을 들어가서 제거하면 됩니다 . 이 파일은 빌드 파일에서 사용됩니다 debian/rules.
3) 당신도 변화를 원합니다 debian/source/format. 어떤 이유로 이것은 소스 형식 1입니다. 버전으로 변경하세요 3.0 (quilt). 1.0따라서 이 파일의 내용을 3.0 (quilt).
debian/이는 디렉토리를 버전 제어하에 두는 경우에만 절대적으로 필요합니다 . 여기서는 자세히 설명하지 않기 때문에 debian/형식 1이 버전 제어 하에 있으면 빌드가 실패합니다.
4) gcc는 이 빌드 중에 광범위한 테스트 스위트를 실행합니다. 이를 원하지 않으면 다음 줄을 변경하여 비활성화할 수 있습니다 rules.defs(아래 참조 # if you don't want to run the gcc testsuite, uncomment the next line).
~에서
#with_check := disabled by hand
도착하다
with_check := disabled by hand
내 패치에서 테스트 스위트를 비활성화했습니다.
5) 이 파일은 데비안 빌드 시스템이 실행되기 시작한 직후에
control사용됩니다
control.m4. 하지만 여전히 수정이 필요합니다 control. 그렇지 않으면 빌드 시스템이 계속 진행되지 않습니다. 시행할 수 있지만 일반적으로 권장되지 않습니다.
6) Multiarch에는 패키지를 업데이트하는 경우 설치된 다른 아키텍처가 동일한 버전을 유지해야 하는 성가신 기능이 있습니다. 저는 amd64를 실행하고 있는데 Skype 설치를 위해 i386 패키지를 실행하고 있기 때문에 이것이 나에게 영향을 미칩니다. 따라서 amd64를 실행 중인 경우 동일한 amd64 및 i386 gcc 패키지가 설치되어 있는지 확인하십시오. 특히 4.9가 설치된 경우 libgcc1 패키지가 업그레이드됩니다. 이것은 무해합니다.
아무튼 글을 쓰는 시점에는 i386 deb를 생성하지 않았기 때문에 gcc 4.9 amd64 wheezy 설치는 확인할 수 없습니다.
업데이트: 마침내 gcc 4.9용 i386 debs 구축을 시작했습니다(i386 chroot에서 사용됨 schroot(참조)64비트 Debian/Ubuntu에서 32비트 프로그램을 어떻게 실행하나요?)), 앞서 언급한 multilib 제한으로 인해 amd64와 함께 설치합니다. 아직 테스트 중이지만 g++ 4.7과 g++-4.9 모두 내가 테스트한 코드를 컴파일합니다. gcc 4.94.7 및 4.9의 일부 공통 라이브러리도 업그레이드해야 하기 때문에 debs 설치가 완전히 간단하지는 않습니다 libstdc++6.
이에 대한 다른 사람들의 보고를 듣고 싶습니다. gcc 4.9 이후 버전/배포판에 대한 패치를 조정하는 데 도움이 필요한 사람이 있으면 여기에 의견을 남겨 알려주세요.
답변3
유감스럽게도 그것은 불가능하거나 적어도 그럴 가치가 없습니다. 다음을 수행할 수 있습니다.
- 저장소의 최신 g++를 사용하여 chroot 환경을 설정하십시오.debootstrap이 도움이 될 것입니다.
- 장점: 설치에 영향을 미치지 않습니다. 자동화할 수도 있습니다.
- 단점: chroot 환경을 올바르게 설정하는 것이 때때로 간단하지 않습니다. 시간.
- 패키지 직접 빌드(백포트)
- 장점: 높은 수준의 개인화. 하드 드라이브 공간을 낭비할 필요가 없습니다.
- 단점: 매번 다시 빌드해야 하므로 자동이 아닙니다. 환경이 손상될 가능성이 더 높습니다.
- 가상 머신 사용:
- 장점/단점: 두 시스템이 커널에서 완전히 분리된다는 점을 제외하면 chrooted 솔루션과 동일합니다.
답변4
GCC 4.9는 데비안 sid에 있습니다. 이를 설치하려면 불안정한 저장소를 저장소에 추가 sources.list하고 설치에 필요한 필수 구성 요소와 함께 설치해야 합니다. 4.9는 결국 베타 버전이 될 것이지만 결코 쌕쌕거림이 없기 때문에 저장소를 추가하거나 수동으로 빌드하지 않으면 설치할 수 없습니다.