Paket untuk dibangun kembali setelah memutakhirkan gcc pada sistem gentoo

Paket mana yang harus dibangun kembali setelah memutakhirkan gccpada sistem gentoo? Apakah itu cukup untuk dijalankan

# emerge -a --oneshot `equery depends gcc |awk '{print " ="$1}'`

seperti yang disarankan serupa untuk perl dalam FAQ ini ?

TL; DR

Saya memiliki pandangan berbeda tentang ini sebagai pengguna Gentoo. Sementara saya setuju dengan pendekatan peterph dari "Biarkan Sistem Memutuskan," saya tidak setuju ketika datang ke Pembaruan ABI . Pembaruan ABI terkadang merupakan perubahan besar dalam perilaku. Dalam kasus GCC 4.7, Perubahan ABI adalah adopsi dari Standar C ++ 11 yang baru, yang ditunjukkan oleh peterph.

Inilah mengapa saya menulis jawaban ini. Saya seorang pecandu standar. Saya mulai di dunia web ketika ada sekitar 4 browser berbeda, dan sejumlah besar tag dalam HTML yang hanya didukung oleh browser tertentu. Pada saat itu, semua tag itu meningkatkan kebingungan, dan IMO membuat pekerjaan menjadi lebih sulit. C ++ telah distandarisasi untuk alasan yang sama, singkatnya sehingga Anda dapat mengkompilasi kode yang saya tulis, dan saya dapat mengkompilasi kode yang Anda tulis . Jika kami memilih untuk tidak mengikuti standar, kami kehilangan kebebasan untuk berbagi.

C ++ 98 telah menjadi Standar yang disetujui selama 13 tahun. C ++ 11 telah diratifikasi oleh Komite ISO pada tahun 2011, dan sepenuhnya terintegrasi ke dalam GCC 4.7. Lihat status ISO saat ini , dan Standar ISO baru .

Mengapa Kita Harus Merasa Privileged sebagai Pengguna Gentoo

Sebagai pengguna distribusi berbasis sumber, kami memiliki peluang unik untuk membentuk perilaku paket di masa mendatang karena kami mengkompilasinya sebelum kami menggunakannya. Karena itu, untuk mempersiapkan kesempatan itu, saya merasa bahwa perintah berikut harus dijalankan, ketika memperbarui ke kompiler baru:

emerge -ev system
gcc-config -l && gcc-config *new compiler name*
env-update && source /etc/profile
emerge -1v libtool
emerge -ev system

Sistem pass through pertama membangun compiler baru, dan dependensinya, dengan kompiler lama. Sistem pass-through kedua membangun kembali kompiler baru dan dependensinya dengan kompiler baru. Secara khusus, kami ingin melakukan ini agar Build Chain kami mengambil keuntungan dari fitur-fitur baru dari kompiler baru, jika paket Build Chain telah diperbarui juga ... Beberapa orang mengganti sistem pass-through ke-2 dengan set dunia, meskipun saya menganggap ini berlebihan, karena kita tidak tahu paket mana yang sudah mendukung standar baru, tapi kami ingin rantai build kami berperilaku sehat.

Melakukan ini setidaknya untuk set sistem, mempersiapkan kami untuk menguji setiap paket yang kami kompilasi terhadap standar baru, karena kami menggunakan rilis bergulir. Dengan cara ini, menambahkan -std=c++11untuk CXXFLAGSsetelah memperbarui rantai membangun memungkinkan kita untuk tes untuk kerusakan, dan dapat mengirimkan bug langsung baik bugzilla kami atau hulu ke pengembang sebenarnya untuk alasan sederhana:

Hei, paket Anda bla bla istirahat menggunakan standar C ++ baru, dan saya sudah melampirkan log build saya.

Saya menganggap ini sebagai rasa hormat kepada para pengembang, karena mereka sekarang punya waktu untuk mempersiapkan karena standar menjadi lebih banyak diadopsi, dan standar lama dihapus. Bayangkan keributan di pihak pengembang jika dia menerima ratusan bug, karena dia menunggu sampai standarnya dihapus ...

Tidak ada distribusi lain yang saya tahu dapat menggunakan metode ini karena pengelola paket yang sebenarnya ada sebagai perantara sebelum tambalan atau pembaruan dapat digunakan oleh komunitas pengguna masing-masing. Kami memang memiliki pengelola, tetapi kami juga memiliki kemampuan untuk menggunakan pohon portage lokal.

Mengenai Pikiran Insightful Diposting di Permintaan Bounty

Saya tidak tahu apakah bounty itu diposting karena Anda semua menyukai wawasan saya, jawaban yang dipikirkan dengan baik, tetapi dalam upaya di bounty, saya akan berusaha untuk menjawab penawaran bounty Anda yang penuh wawasan dan dipikirkan dengan matang. Pertama, izinkan saya mengatakan sebagai tanggapan bahwa sebagai pengguna distribusi berbasis sumber, saya sangat yakin apa yang menghubungkan titik-titik adalah semua hal yang Anda minta dalam permintaan karunia Anda. Seseorang bisa menjadi pembuat kode yang hebat, tetapi harus berhati-hati terhadap perangkat lunak. Dengan cara yang sama, ada orang-orang yang coders jelek yang sangat peduli untuk perangkat lunak.

Sebelum saya datang ke sini, saya adalah poster yang keranjingan, di Forum Gentoo . Saya akhirnya menyadari ketika saya mulai datang ke sini bahwa setiap orang memiliki beberapa tingkat bakat yang dapat mereka gunakan. Apa yang mereka pilih untuk dilakukan itulah yang membuat perbedaan kontribusi. Sebagian dari kita adalah penulis hebat (bukan saya), jadi jika Anda ingin berkontribusi pada suatu proyek, tetapi Anda tidak atau tidak dapat menulis kode, atau memperbaiki bug, ingat bahwa penulis hebat dapat menulis dokumentasi yang hebat, atau Artikel Wiki yang hebat .

Standar ada karena alasan lain: Dalam suatu Komunitas, aturan tertentu diharapkan dari anggotanya . Ikuti pernyataan itu di sini juga. Jika saya mengirimkan perbaikan, tambalan, peningkatan dll dan tidak ada standar, tambalan hanya akan berfungsi dalam situasi yang saya anggap penting, yaitu jika saya menggunakan whizbang compiler 2.0, dan tambalan ini dibuat melawan whizbang compiler 1.0, itu t akan gagal. Karena upaya ini untuk sebuah komunitas, komunitas mengharapkan segalanya berfungsi dalam sebagian besar situasi, jadi alih-alih memaksa semua pengguna untuk memutakhirkan ke kompiler 2, saya dapat menetapkan dalam standar:

Paket ini memilih untuk memungkinkan Kompatibilitas Mundur dengan Whizbang Compiler 1.0

Dengan cara ini, sebagai pengembang, pembuat kode jelek atau tidak, saya tahu bahwa saya harus menggunakan atau setidaknya menguji terhadap Compiler Versi 1.0. Di sisi lain, sebagai pengguna, saya dapat memilih apa yang ingin saya lakukan. Jika saya tidak senang, saya dapat meminta tambalan, dengan mengirimkan bug, atau ekstrem lain dari "Perangkat lunak ini adalah omong kosong!", Dan tidak melakukan apa pun. Apapun, pengguna, dan pengembang memahami standar karena sudah ditulis.

Menjembatani celah mengambil tindakan dari beberapa bentuk pada bagian pengguna, dan itu membutuhkan semua hal yang Anda minta saya dan orang lain untuk mengomentari, dan kita harus bergantung pada komunitas pengguna dan bakat mereka dari semua bentuk menjembatani kesenjangan itu. Jika Anda memilih untuk menjadi salah satu pengguna yang berkontribusi, saya memuji Anda. Bagi Anda yang memilih untuk tidak aktif, ingatlah bahwa jika Anda menginginkan sesuatu diperbaiki, yang aktif memerlukan masukan Anda. Jadi saya katakan kepada Anda, jangan malu untuk mengirimkan bug, atau memberi tahu kami bahwa kami perlu memperbarui dokumentasi, dan jika kami dengan kasar memberi tahu kami, atau menemukan orang lain, sampai Anda menemukan bidang keahlian Anda.

Bacaan Menarik Lainnya yang Terkait dengan Topik Ini

1. Perubahan Terbesar dalam C ++ 11 (dan Mengapa Anda Harus Peduli)
2. C ++ 0x / C ++ 11 Dukungan di GCC
3. Berita, Status & Diskusi tentang Standar C ++

Itu sangat tergantung pada jenis upgrade kompiler yang Anda lakukan. Jika sudah substansial, maka semuanya harus dikompilasi ulang ^*) karena kemungkinan perubahan ABI oleh kompiler. Dalam banyak kasus hal itu tidak diperlukan, tetapi jika paket Anda bergantung pada sesuatu seperti C ++ 11, maka Anda mungkin mengalami masalah - lihat misalnya berita Gentoo tentang perubahan ABI di GCC 4.7 atau GCC bugzilla .

^*) Perhatikan penekanan pada "recompiled" - jelas tidak masuk akal untuk mengkompilasi ulang (baca rebuild) aplikasi Python atau Perl karena Anda mengubah kompiler C. Kecuali ia memiliki komponen asli juga (yang mungkin juga).