gcc젠투 시스템에서 업그레이드 한 후 어떤 패키지를 다시 빌드해야 합니까? 실행하기에 충분합니까
# emerge -a --oneshot `equery depends gcc |awk '{print " ="$1}'`
이 FAQ에서 perl 과 비슷한 제안 ?
gcc젠투 시스템에서 업그레이드 한 후 어떤 패키지를 다시 빌드해야 합니까? 실행하기에 충분합니까
# emerge -a --oneshot `equery depends gcc |awk '{print " ="$1}'`
이 FAQ에서 perl 과 비슷한 제안 ?
답변:
TL; DR
젠투 사용자와는 다른 견해를 가지고 있습니다. Peterph의 "시스템 결정"에 대한 접근 방식에 동의하지만 ABI 업데이트에 대해서는 동의하지 않습니다 . ABI 업데이트는 때때로 행동의 주요 변화입니다. GCC 4.7의 경우 ABI 변경은 새로운 C ++ 11 표준을 채택한 것으로 peterph도 지적했습니다.
여기 내가이 답변을 쓰는 이유가 있습니다. 나는 표준 중독자입니다. 웹 브라우저에서 약 4 개의 서로 다른 브라우저와 특정 브라우저에서만 지원되는 HTML의 수많은 태그가있을 때 시작했습니다. 당시에는 이러한 모든 태그가 혼동을 일으키고 IMO는 작업을 더욱 어렵게 만들었습니다. C ++도 이와 같은 이유로 표준화되어 있으므로 작성한 코드를 컴파일하고 작성한 코드를 컴파일 할 수 있습니다 . 우리가 표준을 따르지 않기로 선택했다면 공유 할 자유가 없어집니다.
C ++ 98은 13 년 동안 승인 된 표준입니다. C ++ 11은 2011 년 ISO위원회에 의해 비준되었으며 GCC 4.7에 완전히 통합되었습니다. 현재 ISO 상태 및 새로운 ISO 표준을 참조하십시오 .
소스 기반 배포판 사용자는 패키지를 사용하기 전에 컴파일하기 때문에 패키지의 향후 동작을 구체화 할 고유 한 기회가 있습니다. 따라서 그 기회를 준비하기 위해 새 컴파일러로 업데이트 할 때 다음 명령을 실행해야한다고 생각합니다.
emerge -ev system
gcc-config -l && gcc-config *new compiler name*
env-update && source /etc/profile
emerge -1v libtool
emerge -ev system
첫 번째 시스템 통과는 이전 컴파일러와 함께 새로운 컴파일러를 빌드하고 종속성을 만듭니다. 시스템을 통한 두 번째 통과는 새 컴파일러를 재구성하고 새 컴파일러와의 종속성입니다. 특히, 우리는 너무이 작업을 수행 할 수 빌드 체인 빌드 체인 패키지가 어떤 사람들은 세계가 설정된 시스템을 통해 2 패스를 대체 ... 또한 갱신 한 경우, I 있지만, 새로운 컴파일러의 새로운 기능을 활용 우리는 어떤 패키지가 이미 새로운 표준을 지원하는지 알지 못하므로 빌드 체인이 이상하게 작동하기를 원하기 때문에 과도하게 사용하십시오.
최소한 시스템 세트에서이 작업을 수행하면 롤링 릴리스를 사용하므로 새 표준에 대해 컴파일하는 모든 패키지를 테스트 할 준비가됩니다. 이런 식으로 빌드 체인을 업데이트 한 후에 추가 -std=c++11하면 CXXFLAGS파손 여부를 테스트 할 수 있으며 다음과 같은 간단한 이유로 버그질라 또는 실제 개발자에게 버그를 직접 제출할 수 있습니다.
이봐, 당신의 패키지 blah blah는 새로운 C ++ 표준을 사용하여 중단되고 빌드 로그를 첨부했습니다.
나는 표준이 더 널리 채택되고 구 표준이 단계적으로 폐지됨에 따라 이제 준비 할 시간이 있기 때문에 개발자에게 의례라고 생각합니다. 표준이 단계적으로 종료 될 때까지 기다렸 기 때문에 개발자가 수백 개의 버그를 받았을 때 개발자의 동요를 상상해보십시오.
패치 나 업데이트를 해당 사용자 커뮤니티에서 사용하기 전에 실제 패키지 관리자가 중개인으로 존재하므로 내가 아는 다른 배포판에서는이 방법을 사용할 수 없습니다. 우리에게는 관리자가 있지만 로컬 포티지 트리를 사용할 수 있습니다.
나는 당신이 내 통찰력 있고, 잘 생각 된 답변을 좋아하기 때문에 현상금이 게시되었는지 알지 못하지만, 현상금을 시도하기 위해, 당신의 통찰력 있고 잘 생각 된 현상금 제공에 대답하려고 노력할 것입니다. 먼저 소스 기반 배포판의 사용자로서 점을 연결하는 것이 바운티 요청에서 요청한 모든 것임을 확실하게 믿습니다. 누군가는 훌륭한 코더가 될 수 있지만 소프트웨어를 엉뚱하게 돌봐야합니다. 같은 방식으로, 소프트웨어를 잘 관리하는 엉터리 코더가있는 사람들이 있습니다.
여기에 오기 전에 젠투 포럼 에서 열렬한 포스터였습니다 . 마침내 여기에 오기 시작했을 때 모든 사람이 어느 정도 재능을 발휘할 수 있다는 것을 깨달았습니다. 그들이 기여하는 차이를 만드는 것은 그들이하는 일입니다. 우리 중 일부는 위대한 작가 (I가 아님)이므로 일부 프로젝트에 기여하고 싶지만 코드를 쓰거나 버그를 수정할 수 없거나 버그를 수정하려면 위대한 작가가 훌륭한 문서 또는 훌륭한 위키 기사를 작성할 수 있음을 기억하십시오. .
표준은 또 다른 이유가 있습니다. 커뮤니티에서는 특정 규칙이 해당 구성원의 것으로 예상 됩니다. 그 진술도 여기에서 따르십시오. 수정 사항, 패치, 개선 사항 등을 제출하고 표준이없는 경우, 패치가 중요한 상황, 즉 whizbang 컴파일러 2.0을 사용하고 있고 패치가 whizbang 컴파일러 1.0에 대해 빌드 된 경우에만 작동합니다. 실패합니다. 노력은 커뮤니티를위한 것이기 때문에 커뮤니티는 대부분의 상황에서 모든 것이 작동하기를 기대하므로 모든 사용자가 컴파일러 2로 업그레이드하지 않고 표준으로 지정할 수 있습니다.
이 패키지는 Whizbang Compiler 1.0과의 호환성을 허용합니다.
이런 식으로 개발자, 엉터리 코더 여부에 관계없이 컴파일러 버전 1.0을 사용하거나 최소한 테스트해야한다는 것을 알고 있습니다. 반면에 사용자는 내가 원하는 것을 선택할 수 있습니다. 마음에 들지 않으면 버그를 제출하거나 "이 소프트웨어는 허물입니다!"의 다른 극단을 통해 패치를 요청할 수 있습니다. 어쨌든, 사용자와 개발자는 표준이 작성 되었기 때문에 표준을 이해합니다.
격차를 해소하려면 사용자 측에서 어떤 형태의 조치를 취해야하며, 이는 귀하가 저와 다른 사람들이 의견을 말하도록 요구 한 모든 것을 필요로하며, 우리는 사용자 공동체와 모든 형태의 재능이 그 격차를 해소해야합니다. 당신이 기여하는 사용자 중 하나가되도록 선택하면, 나는 당신에게 박수를 보냅니다. 활동하지 않기로 선택한 사람들에게는 고정 된 것을 원하면 활동적인 것이 입력이 필요하다는 것을 기억하십시오. 그래서 나는 당신에게 말하고, 버그 제출에 대해 부끄러워하지 말고, 우리가 문서를 업데이트해야한다고 말하고, 우리가 무례하게 말하거나 다른 사람을 찾으면 당신이 당신의 전문 분야를 찾을 때까지 말하십시오.
어떤 종류의 컴파일러 업그레이드를했는지에 달려 있습니다. 그것이 상당했다면 , 컴파일러에 의해 ABI가 변경 될 수 있기 때문에 모든 것이 다시 컴파일 되어야합니다 *) . 많은 경우에 필요하지는 않지만 패키지가 C ++ 11과 같은 것에 의존하는 경우 문제가 발생할 수 있습니다. 예를 들어 GCC 4.7 또는 GCC bugzilla의 ABI 변경에 대한 Gentoo 뉴스를 참조하십시오 .
*) "재 컴파일"에 중점을 두십시오. C 컴파일러를 변경했기 때문에 Python 또는 Perl 응용 프로그램을 재 컴파일 (읽기 재 빌드)하는 것은 의미가 없습니다. 네이티브 구성 요소가없는 한 (잘있을 수도 있습니다).