แพ็คเกจที่จะสร้างใหม่หลังจากอัพเกรด gcc บนระบบ gentoo


12

แพคเกจใดที่ควรสร้างใหม่หลังจากการอัพเกรดgccบนระบบ gentoo เพียงพอหรือไม่ที่จะเรียกใช้

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

ตามที่แนะนำคล้ายคลึงกันสำหรับ perl ในคำถามที่พบบ่อยนี้หรือไม่

คำตอบ:


11

TL; DR

ฉันมีสิ่งที่แตกต่างจากนี้ในฐานะผู้ใช้ Gentoo ในขณะที่ฉันเห็นด้วยกับวิธีการ "ให้ระบบตัดสินใจ" ปีเตอร์ฉันไม่เห็นด้วยเมื่อมาถึงABI Update ABI Update บางครั้งการเปลี่ยนแปลงครั้งสำคัญในพฤติกรรม ในกรณีของ GCC 4.7 การเปลี่ยนแปลง ABI คือการนำมาตรฐาน C ++ 11 ใหม่มาใช้ซึ่งปีเตอร์ยังชี้ให้เห็น

นี่คือเหตุผลที่ฉันเขียนคำตอบนี้ ฉันเป็นมาตรฐานขี้ยา ฉันเริ่มต้นในโลกเว็บเมื่อมีเบราว์เซอร์ที่แตกต่างกันประมาณ 4 และแท็กมากมายใน HTML ที่เบราว์เซอร์บางตัวสนับสนุนเท่านั้น ในขณะนั้นแท็กทั้งหมดนั้นเพิ่มความสับสนและ IMO ทำให้การทำงานหนักขึ้น C ++ ได้รับมาตรฐานด้วยเหตุผลเดียวกันนี้โดยย่อเพื่อให้คุณสามารถคอมไพล์โค้ดที่ฉันเขียนและฉันสามารถคอมไพล์โค้ดที่คุณเขียนได้ หากเราเลือกที่จะไม่ทำตามมาตรฐานเราจะเสียเสรีภาพในการแบ่งปัน

C ++ 98 ได้รับการรับรองมาตรฐานเป็นเวลา 13 ปี C ++ 11 ได้รับการยอมรับจากคณะกรรมการ ISO ในปี 2011 และได้รวมเข้ากับ GCC 4.7 อย่างสมบูรณ์ ดูสถานะ ISO ปัจจุบันและมาตรฐานใหม่ ISO


ทำไมเราควรรู้สึกถึงสิทธิพิเศษในฐานะผู้ใช้ Gentoo

ในฐานะผู้ใช้ของการกระจายตามแหล่งที่มาเรามีโอกาสที่ไม่ซ้ำกันในการกำหนดพฤติกรรมในอนาคตของแพคเกจเพราะเรารวบรวมมันก่อนที่เราจะใช้มัน ดังนั้นเพื่อเตรียมพร้อมสำหรับโอกาสนั้นฉันรู้สึกว่าควรรันคำสั่งต่อไปนี้เมื่ออัปเดตเป็นคอมไพเลอร์ใหม่:

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

การผ่านครั้งแรกของระบบจะสร้างคอมไพเลอร์ใหม่และมันขึ้นอยู่กับคอมไพเลอร์เก่า การผ่านครั้งที่สองของระบบจะสร้างคอมไพเลอร์ใหม่และการพึ่งพากับคอมไพเลอร์ใหม่ โดยเฉพาะเราต้องการทำสิ่งนี้เพื่อให้Build Chainของเราใช้ประโยชน์จากคุณสมบัติใหม่ของคอมไพเลอร์ใหม่หากแพ็กเกจ Build Chain ได้รับการอัปเดตเช่นกัน ... บางคนแทนที่การส่งผ่านครั้งที่ 2 ผ่านระบบด้วยชุดโลก พบว่าสิ่งนี้เกินความจริงเพราะเราไม่ทราบว่าแพคเกจใดที่รองรับมาตรฐานใหม่แล้ว แต่เราต้องการให้สายการผลิตของเรามีพฤติกรรมที่ดี

การทำเช่นนี้กับอย่างน้อยชุดระบบเตรียมให้เราทดสอบทุกแพ็คเกจที่เรารวบรวมกับมาตรฐานใหม่เพราะเราใช้การวางจำหน่าย ด้วยวิธีนี้เพิ่ม-std=c++11ไปCXXFLAGSหลังจากการปรับปรุงการสร้างห่วงโซ่ช่วยให้เราสามารถทดสอบสำหรับการแตกและสามารถที่จะยื่นข้อบกพร่องโดยตรงกับทั้ง Bugzilla ของเราหรือต้นน้ำจนถึงนักพัฒนาที่เกิดขึ้นจริงด้วยเหตุผลง่ายๆของ:

เฮ้แพคเกจของคุณ blah blah หยุดพักโดยใช้มาตรฐาน C ++ ใหม่และฉันได้แนบบันทึกการสร้างของฉันแล้ว

ฉันคิดว่านี่เป็นมารยาทสำหรับนักพัฒนาเนื่องจากตอนนี้พวกเขามีเวลาเตรียมเมื่อมาตรฐานกลายเป็นที่ยอมรับอย่างกว้างขวางมากขึ้นและมาตรฐานเก่าจะค่อย ๆ หมดไป ลองนึกภาพความปั่นป่วนในส่วนของนักพัฒนาถ้าเขาได้รับข้อผิดพลาดหลายร้อยข้อเพราะเขาหรือเธอรอจนกระทั่งมาตรฐานหมดลง ...

ไม่มีการแจกจ่ายอื่นใดที่ฉันรู้ว่าสามารถใช้วิธีนี้เนื่องจากผู้ดูแลแพคเกจที่แท้จริงมีอยู่เป็นคนกลางก่อนที่จะสามารถใช้โปรแกรมแก้ไขหรือการปรับปรุงโดยชุมชนผู้ใช้ที่เกี่ยวข้อง เรามีผู้ดูแล แต่เราก็มีความสามารถในการใช้แผนผังการขนส่งในท้องถิ่น


เกี่ยวกับความคิดที่เฉียบแหลมโพสต์ในคำขอเงินรางวัล

ฉันไม่ทราบว่าเงินรางวัลถูกโพสต์หรือเปล่าเพราะคุณชอบคำตอบที่ชาญฉลาดและคิดอย่างถี่ถ้วน แต่ในความพยายามที่เงินรางวัลฉันจะพยายามตอบคำถามของคุณอย่างชาญฉลาด ก่อนอื่นให้ฉันพูดด้วยการตอบว่าในฐานะผู้ใช้การกระจายแบบอิงแหล่งที่มาฉันเชื่อมั่นว่าจุดเชื่อมต่อคือทุกสิ่งที่คุณขอในคำขอเงินรางวัลของคุณ บางคนอาจเป็นผู้เขียนโค้ดที่ยอดเยี่ยม แต่มีความใส่ใจในซอฟต์แวร์ ในทำนองเดียวกันมีคนที่เป็นนักเขียนเส็งเคร็งที่มีความสนใจซอฟต์แวร์เป็นอย่างมาก

ก่อนที่ผมจะมาที่นี่ผมเป็นโปสเตอร์มักมากในช่วงที่ฟอรั่ม Gentoo ในที่สุดฉันก็รู้เมื่อฉันเริ่มมาที่นี่ว่าทุกคนมีความสามารถระดับหนึ่งที่พวกเขาสามารถใช้ได้ นี่คือสิ่งที่พวกเขาเลือกทำกับมันซึ่งสร้างความแตกต่างให้เกิดขึ้น พวกเราบางคนเป็นนักเขียนที่ยอดเยี่ยม (ไม่ใช่ฉัน) ดังนั้นหากคุณต้องการมีส่วนร่วมในโครงการบางอย่าง แต่คุณทำไม่ได้หรือไม่สามารถเขียนรหัสหรือแก้ไขข้อผิดพลาดโปรดจำไว้ว่านักเขียนที่ยอดเยี่ยมสามารถเขียนเอกสารที่ยอดเยี่ยม .

มาตรฐานจะมีเหตุผลอื่น: ในชุมชน, กฎระเบียบบางอย่างที่คาดว่าสมาชิกของมัน ทำตามคำสั่งที่นี่ด้วย ถ้าฉันส่งโปรแกรมแก้ไขโปรแกรมปรับปรุงและอื่น ๆ และไม่มีมาตรฐานโปรแกรมแก้ไขจะทำงานเฉพาะในสถานการณ์ที่ฉันเห็นว่าสำคัญเช่นถ้าฉันใช้ whizbang compiler 2.0 และโปรแกรมแก้ไขนั้นสร้างจากคอมไพเลอร์ Whizbang 1.0 จะล้มเหลว เนื่องจากความพยายามสำหรับชุมชนชุมชนคาดหวังว่าทุกอย่างจะทำงานในสถานการณ์ส่วนใหญ่ดังนั้นแทนที่จะบังคับให้ผู้ใช้ทุกคนอัปเกรดเป็นคอมไพเลอร์ 2 ฉันสามารถกำหนดมาตรฐาน:

แพคเกจนี้เลือกที่จะอนุญาตให้ใช้งานร่วมกันได้กับ Whizbang Compiler 1.0

ด้วยวิธีนี้ในฐานะนักพัฒนา coder เส็งเคร็งหรือไม่ฉันรู้ว่าฉันต้องใช้หรือทดสอบอย่างน้อยกับ Compiler เวอร์ชัน 1.0 ในฐานะผู้ใช้ในอีกทางหนึ่งฉันสามารถเลือกสิ่งที่ฉันต้องการจะทำ ถ้าฉันไม่มีความสุขฉันสามารถขอแพตช์โดยส่งข้อผิดพลาดหรือสุดโต่งอื่น ๆ ของ "ซอฟต์แวร์นี้เป็นชิ้นส่วนของอึ!" และไม่ทำอะไรเลย ไม่ว่าผู้ใช้และผู้พัฒนาจะเข้าใจมาตรฐานเพราะเขียน

การเชื่อมช่องว่างดำเนินการบางรูปแบบในส่วนของผู้ใช้และนั่นต้องใช้ทุกสิ่งที่คุณขอให้ฉันและของคนอื่นแสดงความคิดเห็นและเราต้องพึ่งพาชุมชนผู้ใช้และความสามารถของพวกเขาในทุกรูปแบบ หากคุณเลือกที่จะเป็นหนึ่งในผู้ใช้ที่มีส่วนร่วมฉันขอยกย่องคุณ สำหรับบรรดาของคุณที่เลือกที่จะไม่ใช้งานโปรดจำไว้ว่าหากคุณต้องการบางสิ่งบางอย่างคงที่คนที่ใช้งานต้องการข้อมูลของคุณ ดังนั้นฉันจะบอกคุณอย่าอายที่จะส่งข้อผิดพลาดหรือบอกเราว่าเราต้องอัปเดตเอกสารและถ้าเราหยาบคายแจ้งให้เราทราบหรือหาคนอื่นจนกว่าคุณจะพบความเชี่ยวชาญของคุณ


การอ่านที่น่าสนใจอื่น ๆ ที่เกี่ยวข้องกับหัวข้อนี้

  1. การเปลี่ยนแปลงที่ใหญ่ที่สุดใน C ++ 11 (และทำไมคุณควรดูแล)
  2. รองรับ C ++ 0x / C ++ 11 ใน GCC
  3. ข่าวสถานะและการสนทนาเกี่ยวกับมาตรฐาน C ++

ฉันจะอัปเดตถ้อยคำแล้วและขอขอบคุณที่ให้ความสนใจในวิธีนี้ ...
eyoung100

3

มันขึ้นอยู่กับว่าคุณอัพเกรดคอมไพเลอร์แบบไหน ถ้ามันเป็นรูปธรรมแล้วทุกอย่างควรจะคอมไพล์ใหม่*)เนื่องจากคอมไพเลอร์อาจมีการเปลี่ยนแปลง ABI ในหลายกรณีก็จะไม่จำเป็น แต่ถ้าแพคเกจของคุณขึ้นอยู่กับบางสิ่งบางอย่างเช่น C ++ 11 แล้วคุณอาจทำงานเป็นปัญหา - ดูเช่นข่าวเกี่ยวกับการเปลี่ยนแปลง Gentoo ABI ใน GCC 4.7หรือGCC Bugzilla

*)สังเกตการเน้นที่ "คอมไพล์ใหม่" - มันไม่สมเหตุสมผลเลยที่จะคอมไพล์ใหม่ (read rebuild) แอพพลิเคชั่น Python หรือ Perl เพราะคุณเปลี่ยนคอมไพเลอร์ C เว้นแต่จะมีองค์ประกอบดั้งเดิมเช่นกัน (ซึ่งมันอาจดี)

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.