การเชื่อมโยง libstdc ++ แบบคงที่: gotchas ใด ๆ ?

ฉันต้องการปรับใช้แอปพลิเคชัน C ++ ที่สร้างขึ้นบน Ubuntu 12.10 พร้อม libstdc ++ ของ GCC 4.7 กับระบบที่ใช้ Ubuntu 10.04 ซึ่งมาพร้อมกับ libstdc ++ เวอร์ชันเก่ากว่ามาก

ขณะนี้ผมกำลังรวบรวมกับ-static-libstdc++ -static-libgccที่แนะนำโดยการโพสต์บล็อกนี้: การเชื่อมโยง libstdc ++ แบบคงที่ ผู้เขียนเตือนไม่ให้ใช้โค้ด C ++ ที่โหลดแบบไดนามิกเมื่อคอมไพล์ libstdc ++ แบบคงที่ซึ่งเป็นสิ่งที่ฉันยังไม่ได้ตรวจสอบ ถึงกระนั้นทุกอย่างดูเหมือนจะราบรื่นจนถึงตอนนี้: ฉันสามารถใช้ประโยชน์จากคุณสมบัติ C ++ 11 บน Ubuntu 10.04 ซึ่งเป็นสิ่งที่ฉันเป็นหลังจากนั้น

ฉันทราบว่าบทความนี้มาจากปี 2548 และอาจมีการเปลี่ยนแปลงมากมายตั้งแต่นั้นมา คำแนะนำยังคงเป็นปัจจุบันหรือไม่? มีปัญหาที่น่าสงสัยที่ฉันควรระวังหรือไม่?

โพสต์บล็อกนั้นค่อนข้างไม่ถูกต้อง

เท่าที่ฉันทราบได้มีการนำการเปลี่ยนแปลง C ++ ABI มาใช้กับ GCC ทุกรุ่นที่สำคัญ (เช่นการเปลี่ยนแปลงที่มีส่วนประกอบหมายเลขเวอร์ชันแรกหรือเวอร์ชันที่สองต่างกัน)

ไม่จริง. การเปลี่ยนแปลง C ++ ABI เพียงอย่างเดียวที่นำมาใช้ตั้งแต่ GCC 3.4 สามารถใช้งานร่วมกันได้ซึ่งหมายความว่า C ++ ABI มีความเสถียรมาเกือบเก้าปี

เพื่อให้เรื่องแย่ลงการกระจาย Linux ที่สำคัญส่วนใหญ่ใช้สแน็ปช็อต GCC และ / หรือแพตช์เวอร์ชัน GCC ทำให้แทบจะเป็นไปไม่ได้เลยที่จะทราบว่า GCC เวอร์ชันใดที่คุณอาจจัดการเมื่อคุณแจกจ่ายไบนารี

ความแตกต่างระหว่าง GCC เวอร์ชันแพตช์ของดิสทริบิวชันนั้นมีเพียงเล็กน้อยและไม่มีการเปลี่ยนแปลง ABI เช่น 4.6.3 20120306 (Red Hat 4.6.3-2) ของ Fedora คือ ABI เข้ากันได้กับรุ่นอัปสตรีม FSF 4.6.x และเกือบจะแน่นอนกับ 4.6 ใด ๆ x จาก distro อื่น ๆ

บนไลบรารีรันไทม์ของ GNU / Linux GCC ใช้การกำหนดเวอร์ชันสัญลักษณ์ ELF ดังนั้นจึงง่ายต่อการตรวจสอบเวอร์ชันสัญลักษณ์ที่ต้องการโดยอ็อบเจ็กต์และไลบรารีและหากคุณมีlibstdc++.soสัญลักษณ์ที่ให้สัญลักษณ์เหล่านั้นก็จะใช้งานได้ไม่สำคัญว่าจะเป็นเวอร์ชันที่ได้รับการแก้ไขที่แตกต่างกันเล็กน้อย จาก distro เวอร์ชันอื่นของคุณ

แต่ไม่มีรหัส C ++ (หรือรหัสใด ๆ ที่ใช้การสนับสนุนรันไทม์ C ++) อาจเชื่อมโยงแบบไดนามิกหากใช้งานได้

นี่ไม่เป็นความจริงเช่นกัน

ที่กล่าวว่าการลิงก์แบบคงที่libstdc++.aเป็นทางเลือกหนึ่งสำหรับคุณ

สาเหตุที่อาจใช้ไม่ได้หากคุณโหลดไลบรารี (โดยใช้dlopen) แบบไดนามิกคือสัญลักษณ์ libstdc ++ ซึ่งขึ้นอยู่กับว่าแอปพลิเคชันของคุณอาจไม่ต้องการเมื่อคุณเชื่อมโยง (แบบคงที่) ดังนั้นสัญลักษณ์เหล่านั้นจะไม่ปรากฏในไฟล์ปฏิบัติการของคุณ ซึ่งสามารถแก้ไขได้โดยการเชื่อมโยงไลบรารีที่แบ่งใช้แบบไดนามิกเข้ากับlibstdc++.so(ซึ่งเป็นสิ่งที่ถูกต้องที่จะทำต่อไปหากขึ้นอยู่กับมัน) การคั่นด้วยสัญลักษณ์ ELF หมายถึงสัญลักษณ์ที่มีอยู่ในไฟล์ปฏิบัติการของคุณจะถูกใช้โดยไลบรารีที่แบ่งใช้ แต่อื่น ๆ ไม่ใช้ ที่มีอยู่ในไฟล์ปฏิบัติการของคุณจะพบได้ในสิ่งที่libstdc++.soเชื่อมโยงไปยัง หากแอปพลิเคชันของคุณไม่ได้ใช้งานdlopenคุณไม่จำเป็นต้องสนใจเรื่องนั้น

อีกทางเลือกหนึ่ง (และทางเลือกหนึ่งที่ฉันชอบ) คือการปรับใช้เวอร์ชันใหม่libstdc++.soควบคู่ไปกับแอปพลิเคชันของคุณและตรวจสอบให้แน่ใจว่าพบก่อนระบบเริ่มต้นlibstdc++.soซึ่งสามารถทำได้โดยบังคับให้ตัวเชื่อมโยงแบบไดนามิกดูในตำแหน่งที่ถูกต้องไม่ว่าจะใช้$LD_LIBRARY_PATHตัวแปรสภาพแวดล้อมที่รัน - เวลาหรือโดยการตั้งค่าRPATHในปฏิบัติการในเวลาลิงค์ ฉันชอบใช้RPATHเพราะมันไม่ได้ขึ้นอยู่กับสภาพแวดล้อมที่ตั้งไว้อย่างถูกต้องเพื่อให้แอปพลิเคชันทำงาน หากคุณเชื่อมโยงแอพลิเคชันของคุณด้วย'-Wl,-rpath,$ORIGIN'(หมายเหตุราคาเดียวเพื่อป้องกันไม่ให้เปลือกพยายามที่จะขยาย$ORIGIN) แล้วปฏิบัติการจะมีRPATHของ$ORIGINที่บอกลิงเกอร์แบบไดนามิกที่จะมองหาห้องสมุดสาธารณะในไดเรกทอรีเดียวกันเป็นปฏิบัติการของตัวเอง ถ้าใส่ใหม่กว่าlibstdc++.soในไดเร็กทอรีเดียวกันกับไฟล์ปฏิบัติการซึ่งจะพบได้ในขณะรันไทม์แก้ไขปัญหาได้ (อีกทางเลือกหนึ่งคือการใส่ไฟล์ปฏิบัติการลงใน/some/path/bin/libstdc ++ ที่ใหม่กว่าดังนั้นใน/some/path/lib/และเชื่อมโยงกับ'-Wl,-rpath,$ORIGIN/../lib'หรือตำแหน่งคงที่อื่น ๆ ที่สัมพันธ์กับไฟล์ปฏิบัติการและตั้งค่า RPATH ให้สัมพันธ์กับ$ORIGIN)

อีกหนึ่งคำตอบที่ยอดเยี่ยมของ Jonathan Wakely ทำไม dlopen () ถึงมีปัญหา:

เนื่องจากพูลการจัดการข้อยกเว้นใหม่ใน GCC 5 (ดูPR 64535และPR 65434 ) หากคุณ dlopen และ dl ปิดไลบรารีที่เชื่อมโยงกับ libstdc ++ แบบคงที่คุณจะได้รับหน่วยความจำรั่ว (ของวัตถุพูล) ทุกครั้ง ดังนั้นหากมีโอกาสที่คุณจะใช้ dlopen ดูเหมือนว่าเป็นความคิดที่ไม่ดีจริงๆในการลิงก์ libstdc ++ แบบคงที่ หมายเหตุว่านี่คือการรั่วไหลจริงเมื่อเทียบกับคนใจดีที่กล่าวถึงในPR 65434

เพิ่มเติมสำหรับคำตอบของ Jonathan Wakely เกี่ยวกับ RPATH:

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

ตัวอย่างเช่นสมมติว่าคุณมีแอปพลิเคชัน App.exe ซึ่งมีการเชื่อมโยงแบบไดนามิกบน libstdc ++ so.x สำหรับ GCC 4.9 App.exe มีการอ้างอิงนี้ได้รับการแก้ไขผ่าน RPATH เช่น

App.exe (RPATH=.:./gcc4_9/libstdc++.so.x)

ตอนนี้สมมติว่ามี Dependency.so ไลบรารีอื่นซึ่งมีการพึ่งพาแบบไดนามิกที่เชื่อมโยงกับ libstdc ++ ดังนั้นyสำหรับ GCC 5.5 การอ้างอิงที่นี่ได้รับการแก้ไขผ่าน RPATH ของไลบรารีเช่น

Dependency.so (RPATH=.:./gcc5_5/libstdc++.so.y)

เมื่อโหลด App.exe Dependency.so, มันไม่ผนวกมิได้ prepends RPATH ของห้องสมุด มันไม่ปรึกษามันเลย RPATH เดียวที่ถูกพิจารณาจะเป็นของแอปพลิเคชันที่ทำงานอยู่หรือ App.exe ในตัวอย่างนี้ นั่นหมายความว่าหากไลบรารีอาศัยสัญลักษณ์ที่อยู่ใน gcc5_5 / libstdc ++ so.y แต่ไม่ใช่ใน gcc4_9 / libstdc ++ so.x ไลบรารีจะไม่สามารถโหลดได้

นี่เป็นเพียงคำเตือนเนื่องจากฉันเคยพบปัญหาเหล่านี้ในอดีต RPATH เป็นเครื่องมือที่มีประโยชน์มาก แต่การนำไปใช้งานยังมี gotchas อยู่บ้าง

คุณอาจต้องตรวจสอบให้แน่ใจว่าไม่ได้ขึ้นอยู่กับไดนามิกกะล่อน รันlddบนไฟล์ปฏิบัติการที่เป็นผลลัพธ์ของคุณและจดบันทึกการอ้างอิงแบบไดนามิก (libc / libm / libpthread เป็นสิ่งต้องสงสัยที่ใช้งานได้)

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

ฉันต้องการเพิ่มคำตอบของ Jonathan Wakely ดังต่อไปนี้

เมื่อเล่น-static-libstdc++บน linux ฉันประสบปัญหากับdlclose(). สมมติว่าเรามีแอปพลิเคชัน "A" ที่เชื่อมโยงแบบคงที่libstdc++และโหลดแบบไดนามิกที่เชื่อมโยงกับlibstdc++ปลั๊กอิน "P" ที่รันไทม์ ไม่เป็นไร. แต่เมื่อ 'A' ยกเลิกการโหลด 'P' ความผิดพลาดในการแบ่งส่วนจะเกิดขึ้น สมมติฐานของฉันคือหลังจากยกเลิกการโหลดlibstdc++.so'A' จะไม่สามารถใช้สัญลักษณ์ที่เกี่ยวข้องกับlibstdc++. โปรดทราบว่าหากทั้ง 'A' และ 'P' เชื่อมโยงแบบคงที่libstdc++หรือถ้า 'A' ถูกเชื่อมโยงแบบไดนามิกและ 'P' แบบคงที่ปัญหาจะไม่เกิดขึ้น

สรุป: หากแอปพลิเคชันของคุณโหลด / ยกเลิกการโหลดปลั๊กอินที่อาจเชื่อมโยงแบบไดนามิกlibstdc++แอปนั้นจะต้องเชื่อมโยงแบบไดนามิกด้วย นี่เป็นเพียงข้อสังเกตของฉันและฉันต้องการรับความคิดเห็นของคุณ