ห้องสมุดแบบคงที่ C ขมวดคิ้วอยู่หรือไม่? [ปิด]

มี 2 ​​อาร์กิวเมนต์สำหรับการมีไลบรารีที่แบ่งใช้:

1. ช่วยลดพื้นที่ดิสก์
2. เมื่อมีการอัปเดตไลบรารีที่ใช้ร่วมกันไบนารีทั้งหมดขึ้นอยู่กับว่าจะได้รับการอัปเดต

มีข้อเสียเปรียบหนึ่งสำหรับไลบรารีที่แชร์:

• พวกเขา (สามารถ) แนะนำนรกพึ่งพา

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

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

ข้อได้เปรียบที่สองยังคงมีอยู่ แต่ฉันคิดว่าข้อดีของไบนารีคงที่ในคอมพิวเตอร์เดสก์ท็อปนั้นมีน้ำหนักมากกว่า ฉันหมายถึงแม้แต่ภาษาใหม่อย่าง Go ก็รวบรวมไบนารีทั้งหมดของพวกเขาทั้งๆที่มีข้อได้เปรียบของ shared library เพราะความสะดวก

เนื่องจากข้อได้เปรียบหลักอย่างหนึ่งของไลบรารีที่ใช้ร่วมกันไม่ใช่เรื่องใหญ่อีกต่อไปแล้ว C นิ่งไลบรารียังคงขมวดคิ้วอยู่หรือไม่? ถ้าเป็นเช่นนั้นทำไม

หลักฐานของคำถามของคุณมีข้อบกพร่อง สิ่งที่ขมวดคิ้วคือการยึดมั่นในหลักคำสอนและสัมบูรณ์โดยไม่เข้าใจพื้นฐานเบื้องหลังการเขียนโปรแกรม (Cargo ลัทธิ?)

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

คำถามจริงคืออะไรข้อดีข้อเสียของการเชื่อมโยงแบบคงที่และแบบไดนามิกและเมื่อหนึ่งจะเป็นที่ต้องการมากกว่าที่อื่น

จากมุมมองของนักพัฒนาซอฟต์แวร์การเชื่อมโยงแบบไดนามิกมักจะเพิ่มความเร็วในการคอมไพล์ / ลิงค์ / ทดสอบของคุณอย่างมาก

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

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

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

ไลบรารีที่ใช้ร่วมกันเป็นที่ต้องการอย่างมากโดยผู้ดูแลการแจกจ่าย Linux เนื่องจากเหตุผลที่คุณ # 2 เป็นสิ่งสำคัญสำหรับพวกเขาเช่นเมื่อมีคนพบข้อบกพร่องด้านความปลอดภัยใน zlibพวกเขาไม่จำเป็นต้องคอมไพล์ใหม่ทุก ๆ โปรแกรมที่ใช้ zlib --- ไม่เพียง แต่จะทำให้พวกเขาใช้ CPU รอบมากขึ้นในการทำ การคอมไพล์ใหม่ทุกคนที่ใช้ distro จะต้องดาวน์โหลดโปรแกรมเหล่านั้นทั้งหมดอีกครั้ง ในขณะเดียวกันภายในชุดของแพ็กเกจที่จัดจำหน่ายโดยการกระจายนรกไม่ได้เป็นปัญหาเพราะทุกอย่างได้รับการทดสอบการทำงานกับชุดของไลบรารีนั้น

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

สิ่งสำคัญอื่น ๆ ที่ควรทราบคือ GNU libcและ GCC libstdc++มีองค์ประกอบที่ไม่สามารถทำงานได้อย่างน่าเชื่อถือหากห้องสมุดมีการเชื่อมโยงแบบคงที่ ปัญหาที่พบบ่อยที่สุดคือมีdlopenเพราะสิ่งที่คุณโหลดโมดูลที่มีdlopenอยู่ในตัวเองแบบไดนามิกlibc.so.6การเชื่อมโยงกับ นั่นหมายความว่าตอนนี้คุณมีไลบรารี่ C สองชุดในพื้นที่ที่อยู่ของคุณและความฮือฮาจะเกิดขึ้นเมื่อพวกเขาไม่เห็นด้วยกับการคัดลอกmallocโครงสร้างข้อมูลภายใน(ตัวอย่าง) มีสิทธิ์ มันแย่ลงเรื่อย ๆ : ฟังก์ชั่นมากมายที่ไม่ได้มีส่วนเกี่ยวข้องกับอะไรdlopenเช่นใช้gethostbynameและiconvใช้งานdlopenภายใน (เพื่อให้พฤติกรรมของพวกเขาสามารถกำหนดค่าได้เอง) โชคดีที่ ABI สำหรับ libc และ libstdc ++ มีความเสถียรมากดังนั้นคุณจึงไม่น่าจะพบปัญหาในการเชื่อมโยงพวกมันแบบไดนามิก

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

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

• การเชื่อมโยงแบบคงที่ทำให้มั่นใจได้ว่าแอปพลิเคชันมีอยู่ในตัวเองมากขึ้น ในขณะที่ไลบรารีที่แบ่งใช้สามารถ colocated ด้วยการปฏิบัติการหลัก แต่บ่อยครั้งที่พวกเขาจะถูกฝากไว้ในสถานที่ที่ใช้ร่วมกัน แอปพลิเคชั่นที่เชื่อมโยงแบบคงที่นั้นง่ายต่อการตรวจสอบให้แน่ใจว่า "พกพา" ในแง่ของ "ไม่ต้องการการเปลี่ยนแปลงไฟล์ไดเรกทอรีหรือการตั้งค่าที่ระบบปฏิบัติการเป็นเจ้าของ" (คิดว่าไดเรกทอรี Windows รีจิสทรี / etc)

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

การลิงก์แบบสแตติกทำให้การปรับใช้แอปพลิเคชันง่ายขึ้นอย่างมาก ไม่ต้องตรวจจับและจัดการกับรุ่นที่แตกต่างกัน เพียงอบและปรับใช้

ข้อได้เปรียบที่ชัดเจนของไลบรารีแบบไดนามิกคือความสามารถในการใช้การอัปเดตอย่างอิสระ

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