ถ้ามันเป็นห้องสมุดอื่น ๆ แต่ glibc ... ฉันคิดว่าคงไม่มีวิธีที่รวดเร็วเพราะ glibc นั้นเป็นสถานที่ที่สิ่งต่าง ๆ นั้น "รหัสยาก" เหมาะกับ glibc กับรุ่นเคอร์เนลของคุณและรถตักดินที่เป็นตัวอย่างที่ไม่จริงสิ่งที่ถูกต้อง (TM) LD_LIBRARY_PATHด้วย
บางทีวิธีที่ถูกต้องคือ:
LD_LIBRARY_PATH="/opt/myglibc/;..." /opt/myglibc/ld-linux.so.2 the_program`
ไม่แน่ใจว่าใช้งานได้หรือไม่
ผมคิดว่าการใช้ glibc ทางเลือกนั้นจำเป็นต้องใช้เฟรมเวิร์กเนื่องจากบางครั้งพา ธ การค้นหาจะถูกต่อสายและ glibc จะต้องมีขนาดพอดีกับระบบปฏิบัติการ / เคอร์เนลของคุณดังนั้นจึงไม่มีไบนารีทั่วไป IMO ผู้ปกครองหลายคนของเดเบียนแสดงให้เห็นว่ามันไม่สำคัญ แต่ก็ยังสามารถทำได้ หากมีใครที่จะมีวิธีการอื่นที่แยกแยะห้องสมุดนอกเหนือจากสถาปัตยกรรมเป้าหมาย
เว็บไซต์เพิ่งให้หัวข้อที่เกี่ยวข้องอื่น ๆ นี้แก่ฉัน:
ที่นั่นคำตอบที่ยอมรับนั้นมีลิงค์ไปยังโปรแกรมที่เรียกว่าrtldiซึ่งดูเหมือนว่าจะแก้ปัญหา glibc มันมาจากปี 2004 ดังนั้นมันจึงอาจไม่ได้ผลจาก linker อีกต่อไป แต่อาจคุ้มค่าที่จะดู แหล่งที่มาของมันคือ GPLv2
Jehova, Jehova
เพื่อนของฉันเคยคิดขึ้นมาว่าการใช้ห้องสมุดสาธารณะที่ใช้ร่วมกันนั้นเกินจริง และเขาก็มีประเด็น: ไลบรารีที่ใช้ร่วมกันนั้นดีที่จะไม่เติมหน่วยความจำของคอมพิวเตอร์ของคุณซ้ำซ้อน แต่เมื่อพิจารณาถึงอินสแตนซ์ของแต่ละแอปพลิเคชันนี้จะมีเพียงไม่กี่ MB
มีแอปพลิเคชั่นเพียงไม่กี่ตัวเท่านั้นที่เราจะหันไปใช้กับการกระทำเช่นมอบ glibc ให้พวกเขาเอง ช่วยเราในการวิเคราะห์ที่ยาวนานลองเรียกพวกเขาว่า "แอปพลิเคชั่นทันที" ซึ่งเป็นของใช้เองในแง่ของการทำงานให้เสร็จ ตัวอย่างเช่นเว็บเบราว์เซอร์ตัวแทนผู้ใช้จดหมายชุดสำนักงานและเครื่องเล่นเพลงช่วยให้ผู้ใช้สามารถได้รับสิ่งที่ต้องการและมีเพียงไม่กี่กรณีต่อผู้ใช้ เมื่อต้องการแสดงภาพอีกด้านหนึ่งบริการระบบผู้จัดการหน้าต่างแม้แต่สภาพแวดล้อมเดสก์ท็อปทั้งหมดล้วน แต่มีความสำคัญมาก แต่เพียงสนับสนุนและมักจะไม่แปลกหรือไม่สำคัญพอดังนั้นผู้คนจะเต็มใจให้ glibc ของพวกเขาเอง
จำนวนของ "แอปพลิเคชันทันที" ค่อนข้างเล็กแน่นอนต่อผู้ใช้และค่อนข้างเมื่อเทียบกับสิ่งที่ "พื้นฐาน" ระบบปฏิบัติการและ DEs วางไข่วันนี้ หากแอปพลิเคชันทันทีเช่น Chrome, Firefox ถูกรวบรวมแบบสแตติกความต้องการหน่วยความจำเพิ่มเติมสำหรับระบบเฉลี่ยจะอยู่ที่ 100MB เพียงไม่กี่ ข้อโต้แย้งที่ไม่ได้ดำเนินการมากเกินไปในระบบ GB จำนวนมากในปัจจุบันดังนั้นการเชื่อมโยงเชิงสถิติสำหรับแอปพลิเคชันทันทีอาจเป็นตัวเลือก
นอกจากนี้ยังมีแนวคิดของพื้นที่สว็อปและ SSD ที่อนุญาตให้สลับสว็อป / ออกอย่างรวดเร็วแบบ Rediculously ซึ่งช่วยจัดการความต้องการหน่วยความจำที่เพิ่มขึ้น
ปัญหา glibc ที่กล่าวถึงในที่นี้ไม่ได้รับการแก้ไขอย่างแท้จริงแม้ว่าจะเป็นการเชื่อมโยงแบบคงที่ แต่สำหรับแอปพลิเคชันเช่นเว็บเบราว์เซอร์รูปแบบการกระจายที่มีอยู่ในตัวเองนั้นเป็นไปได้โดยที่โปรโตคอล X ข้อดีคือความเข้ากันไม่ได้ของเวอร์ชันไลบรารีน้อยลง
du -h /lib) โปรดทราบว่าหากมีการรวบรวมในแบบคงที่จำนวน RAM จะต้องสำหรับแต่ละ และทุกแอปพลิเคชันที่คอมไพล์ด้วย ดังนั้นถ้าเช่น คุณมีสองแอพโดยใช้ไลบราไลบรารีเดียวกันตอนนี้คุณต้องมีหน่วยความจำมากเป็นสองเท่า สามแอพ มากเป็นสามเท่า ไม่พูดถึงมันส่วนใหญ่จะลบล้างประโยชน์ของแคช ...