คำถามติดแท็ก static-linking

5
มีใบอนุญาต LGPL ที่แก้ไขแล้วซึ่งอนุญาตให้มีการเชื่อมโยงแบบสแตติก
LGPLต้องการให้ใช้หากโปรแกรมใช้ไลบรารี LGPL-ed ผู้ใช้จะต้องสามารถเชื่อมโยงโปรแกรมกับไลบรารีเวอร์ชันอื่น: ... d) ทำสิ่งใดสิ่งหนึ่งต่อไปนี้: 0) สื่อความหมายแหล่งที่มาที่น้อยที่สุดภายใต้เงื่อนไขของใบอนุญาตนี้และรหัสแอปพลิเคชันที่สอดคล้องกันในรูปแบบที่เหมาะสมสำหรับและภายใต้ข้อกำหนดที่อนุญาตให้ผู้ใช้สามารถรวมกันอีกครั้งหรือเชื่อมโยงแอปพลิเคชัน Combined Work ในลักษณะที่ระบุไว้ในส่วนที่ 6 ของ GNU GPL สำหรับถ่ายทอดแหล่งที่เกี่ยวข้อง 1) ใช้กลไกไลบรารีแบบแบ่งใช้ที่เหมาะสมสำหรับการลิงก์กับไลบรารี กลไกที่เหมาะสมคือกลไกหนึ่งที่ (a) ใช้งาน ณ เวลาที่สำเนาของ Library มีอยู่แล้วในระบบคอมพิวเตอร์ของผู้ใช้และ (b) จะทำงานอย่างถูกต้องกับ Library รุ่นที่แก้ไขซึ่งสามารถใช้งานร่วมกับรุ่นที่เชื่อมโยงได้ ... อย่างไรก็ตามในบางกรณีอาจทำให้เกิดปัญหาได้ โดยเฉพาะอย่างยิ่งโปรแกรม Haskell จะถูกรวบรวมแบบคงที่เกือบตลอดเวลา ยิ่งไปกว่านั้นคอมไพเลอร์ทำการปรับข้ามโมดูลให้เหมาะสมดังนั้นจึงเป็นไปไม่ได้ที่จะมีส่วนร่วมของโค้ดและแทนที่ด้วยโค้ดอื่น ดังนั้นจึงเป็นเรื่องยากมากที่จะตอบสนองเงื่อนไขนี้ (ดูลิงค์นี้ที่ Haskell Wiki) การเชื่อมโยงแบบไดนามิกจะเป็นวิธีแก้ปัญหา แต่ในหลายกรณีไม่สามารถทำได้ ตัวอย่างเช่น: บางแพลตฟอร์มอาจไม่มีการเชื่อมโยงแบบไดนามิกเลย บางภาษาไม่มีความเป็นไปได้ของการเชื่อมโยงแบบไดนามิก หรือไม่สามารถสร้างโมดูลหลายแพลตฟอร์มได้ ในบางกรณีการเชื่อมโยงแบบไดนามิกจะป้องกันการเพิ่มประสิทธิภาพที่สำคัญ แม้ว่าฉันจะบอกว่านี่เป็นปัญหาร้ายแรง แต่ในภาษาอย่าง Haskell การสูญเสียประสิทธิภาพอาจมีความสำคัญ …

2
ซ้อนห้องสมุดคงที่เป็นไปได้?
ฉันกำลังทำงานใน QT ไลบรารีแบบสแตติกสามารถขึ้นอยู่กับไลบรารีแบบสแตติกอื่นได้หรือไม่ (Static Lib ถูกสร้างโดยการเชื่อมโยงแบบสแตติกแบบอื่น) ถ้าใช่เป็นไปได้ไหมว่าหลังจากเชื่อมโยงไปยัง lib2 แล้ว lib ที่สร้างขึ้น (lib1) จะไม่ประกอบด้วยรหัสทั้งหมดของ lib2 หรือไม่ ในโครงการ Qt ของฉันฉันใช้ไลบรารีแบบสแตติกซึ่งขึ้นอยู่กับหลายไลบรารี ฉันต้องเพิ่มไลบรารีทั้งหมด (โดยมีส่วนหัวทั้งหมดในโครงการของฉัน) แม้ว่าฉันต้องการเพียงหนึ่ง lib (และหนึ่ง .h ของคลาสนั้น) ในรหัสของฉัน กรุณาอธิบายสถานการณ์
12 c++  qt  static-linking 

2
เหตุใด Apple จึงอนุญาตเฉพาะสำหรับ Static Frameworks บน iOS
เห็นได้ชัดว่า Apple มีความสามารถในการสร้างไลบรารี่ที่โหลดแบบไดนามิก (เรียกว่าเฟรมเวิร์ก) สำหรับ iOS เนื่องจากพวกมันมาพร้อมกับ XCode (เช่น UIKit) นักพัฒนาแอปมีความสามารถในการสร้างห้องสมุดแบบคงที่หรืออย่างดีที่สุดหลอก Xcode ให้คิดว่ามันกำลังโหลดเฟรมเวิร์กเมื่อมันโหลดไลบรารีแบบสแตติกจริง ๆ แล้วสิ่งนี้เรียกว่าการสร้างเฟรมปลอม แต่ไม่มีประโยชน์ในการโหลดแบบไดนามิก เหตุผลของ Apple ในการป้องกันเฟรมเวิร์กแบบไดนามิกจากนักพัฒนาแอพคืออะไร ดูเหมือนว่าจะช่วยลดความยุ่งยากในการใช้งานไลบรารีภายนอกเนื่องจากผู้พัฒนาไม่จำเป็นต้องพึ่งพาแฟล็กเกอร์ลิงค์ฟิงเกอร์หรือการพึ่งพาไลบรารีโอเพนซอร์ส ฉันเห็นเหตุผลทั่วไปคือความปลอดภัย เหตุใด Apple จึงอนุญาตบน OSX และไม่ใช่ iOS การรักษาความปลอดภัยไม่ใช่ข้อกำหนดที่มีเช่นกัน? แก้ไข: นี่ไม่เกี่ยวข้องกับ iOS 8 อีกต่อไป Apple ได้เพิ่มการรองรับเฟรมเวิร์กแบบไดนามิก

3
มันเป็นสิ่งสำคัญที่ทำให้งงงวยรหัสแอปพลิเคชัน C ++?
ในโลก Java ดูเหมือนว่าบางครั้งจะมีปัญหา แต่สิ่งที่เกี่ยวกับ C ++? มีวิธีแก้ไขปัญหาต่าง ๆ หรือไม่? ฉันคิดเกี่ยวกับความจริงที่ว่าบางคนสามารถแทนที่ไลบรารี C ++ ของระบบปฏิบัติการที่เฉพาะเจาะจงด้วยเวอร์ชันเดียวกันของไลบรารีเดียวกัน แต่เต็มไปด้วยสัญลักษณ์การดีบักเพื่อทำความเข้าใจว่าโค้ดของฉันทำอะไร การใช้ไลบรารีมาตรฐานหรือห้องสมุดยอดนิยมเป็นสิ่งที่ดีหรือไม่? สิ่งนี้สามารถเกิดขึ้นได้กับไลบรารี่ dll บางตัวใน Windows แทนที่ด้วย "debug version" ของไลบรารี่นั้น มันจะดีกว่าที่จะรวบรวมแบบคงที่? ในแอพพลิเคชั่นเชิงพาณิชย์ฉันเห็นว่าแกนหลักของแอพของพวกเขารวบรวมทุกอย่างในแบบสแตติกและส่วนใหญ่ dll (ไลบรารีไดนามิกทั่วไป) ใช้เพื่อเสนอเทคโนโลยีของบุคคลที่สามเช่นโซลูชั่นต่อต้านการละเมิดลิขสิทธิ์ (ฉันเห็นในเกมหลายเกม ), ไลบรารี GUI (เช่น Qt), ไลบรารี OS ฯลฯ การรวบรวมแบบคงที่เทียบเท่ากับการทำให้งงงวยในโลก Java หรือไม่? ในแง่ที่ดีกว่าเป็นวิธีที่ดีที่สุดและประหยัดที่สุดในการปกป้องรหัสของคุณหรือไม่?

1
การให้ไฟล์วัตถุเป็นไปตามข้อเชื่อมโยง LGPL relink หรือไม่?
จากคำถามนี้ดังนั้นฉันอ่าน: รหัสที่มาที่เป็นกรรมสิทธิ์ + รหัสที่มา LGPL เชื่อมโยงแบบคงที่: คุณต้องปล่อยทั้งสองส่วนเป็น LGPL หรือจัดหาทุกอย่างที่อนุญาตให้ผู้ใช้เชื่อมโยงแอปพลิเคชันด้วยซอร์สโค้ด LGPL รุ่นอื่น ในกรณีนี้ข้อกำหนดอื่น ๆ จะเหมือนกับว่ามีการเชื่อมโยงแบบไดนามิก ดังนั้นดูเหมือนว่าการให้ไฟล์ออบเจ็กต์นั้นเพียงพอที่จะทำให้ LGPL พึงพอใจในแง่ของการเชื่อมโยงไลบรารี LGPL กับแอปพลิเคชันรหัสที่เป็นกรรมสิทธิ์ ในขณะที่การปฏิบัติการนั้นเชื่อมโยงแบบสแตติกการจัดเตรียมอ็อบเจ็กต์ไฟล์อนุญาตให้ผู้ใช้ปลายทางคอมไพล์แอ็พพลิเคชันอีกครั้งเชื่อมโยงไปยังไลบรารีเวอร์ชันต่าง ๆ สิ่งนี้ถูกต้องหรือไม่หากเป็นเช่นนั้นทำไม
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.