ฉันมีส่วนร่วมในการอภิปรายบางอย่างเกี่ยวกับห้องสมุดใน Linux และต้องการยืนยันบางสิ่ง

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

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

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

ฉันเคยได้ยินบางคนสร้างความแตกต่างระหว่างวัตถุที่ใช้ร่วมกันและไลบรารีที่เชื่อมโยงแบบไดนามิก (DLL's) แม้ว่าพวกเขาจะเป็นทั้งไฟล์ ".so" ก็ตาม มีความแตกต่างระหว่างวัตถุที่ใช้ร่วมกันและ DLLs เมื่อมันมาถึงการพัฒนา C / C ++ บน Linux หรือระบบปฏิบัติการที่สอดคล้องกับ POSIX อื่น ๆ (เช่น: MINIX, UNIX, QNX, ฯลฯ )? ฉันได้รับการบอกว่าความแตกต่างที่สำคัญอย่างหนึ่ง (จนถึง) คือวัตถุที่ใช้ร่วมกันนั้นเพิ่งใช้งานในขณะที่ DLL ต้องเปิดก่อนโดยใช้การเรียก dlopen () ภายในแอปพลิเคชัน

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

ขอบคุณล่วงหน้าสำหรับความช่วยเหลือของคุณ

ปรับปรุง

ในบริบทที่ข้อกำหนดเหล่านี้ให้ฉันมันเป็นเงื่อนไขที่ผิดพลาดที่ใช้โดยทีมนักพัฒนา Windows ที่ต้องเรียนรู้ Linux ฉันพยายามที่จะแก้ไขพวกเขา แต่บรรทัดฐานทางภาษา (ไม่ถูกต้อง) ติดอยู่

1. Shared Object: ไลบรารีที่เชื่อมโยงเข้ากับโปรแกรมโดยอัตโนมัติเมื่อโปรแกรมเริ่มทำงานและมีอยู่เป็นไฟล์สแตนด์อโลน ไลบรารีจะรวมอยู่ในรายการเชื่อมโยงในเวลารวบรวม (เช่น: LDOPTS+=-lmylibสำหรับไฟล์ไลบรารีที่ชื่อmylib.so) ไลบรารีต้องแสดงในเวลารวบรวมและเมื่อแอปพลิเคชันเริ่มต้น
2. ห้องสมุดคงที่: ห้องสมุดที่ถูกรวมเข้าไปในโปรแกรมจริงในเวลาบิลด์สำหรับแอปพลิเคชั่นเดี่ยว (ใหญ่กว่า) ที่มีรหัสแอปพลิเคชันและรหัสห้องสมุดที่เชื่อมโยงเข้ากับโปรแกรมโดยอัตโนมัติเมื่อโปรแกรมถูกสร้างขึ้น โปรแกรมหลักและไลบรารีมีอยู่เป็นไฟล์ไบนารีแบบสแตนด์อโลนเดียว ห้องสมุดจะรวมอยู่ในรายการเชื่อมโยงในเวลารวบรวม (เช่น: LDOPTS+=-lmylibสำหรับไฟล์ไลบรารีชื่อ mylib.a) ห้องสมุดจะต้องปรากฏตัวในเวลารวบรวม
3. DLL: เป็นหลักเหมือนกับวัตถุที่ใช้ร่วมกัน แต่แทนที่จะรวมอยู่ในรายการการเชื่อมโยง ณ เวลารวบรวมไลบรารีจะถูกโหลดผ่านdlopen()/ dlsym()คำสั่งเพื่อให้ไลบรารีไม่จำเป็นต้องอยู่ ณ เวลาบิลด์เพื่อให้โปรแกรมรวบรวม นอกจากนี้ไลบรารีไม่จำเป็นต้องมีอยู่ (จำเป็น) เมื่อเริ่มต้นแอปพลิเคชันหรือเวลารวบรวมเนื่องจากจำเป็นเท่านั้นในขณะที่มีการเรียกdlopen/ dlsymเรียกใช้
4. Shared Archive: เป็นหลักเช่นเดียวกับไลบรารีแบบสแตติก แต่ถูกคอมไพล์ด้วยแฟล็ก "export-shared" และ "-fPIC" ไลบรารีจะรวมอยู่ในรายการเชื่อมโยงในเวลารวบรวม (เช่น: LDOPTS+=-lmylibSสำหรับไฟล์ไลบรารีที่ชื่อmylibS.a) ความแตกต่างระหว่างทั้งสองคือจำเป็นต้องมีการตั้งค่าสถานะเพิ่มเติมนี้ถ้าวัตถุที่ใช้ร่วมกันหรือ DLL ต้องการเชื่อมโยงการเก็บถาวรที่ใช้ร่วมกันแบบคงที่ลงในรหัสของตนเองและสามารถทำให้ฟังก์ชันในวัตถุที่ใช้ร่วมกันพร้อมใช้งานกับโปรแกรมอื่น ๆ ภายในกับ DLL สิ่งนี้มีประโยชน์ในกรณีที่มีคนให้ห้องสมุดแบบคงที่แก่คุณและคุณต้องการบรรจุใหม่เป็น SO ห้องสมุดจะต้องปรากฏตัวในเวลารวบรวม

ปรับปรุงเพิ่มเติม

ความแตกต่างระหว่าง " DLL" และ " shared library" เป็นแค่ภาษาพูด (ขี้เกียจไม่ถูกต้อง) ใน บริษัท ที่ฉันทำงานในเวลานั้น (นักพัฒนา Windows ถูกบังคับให้เปลี่ยนไปใช้การพัฒนา Linux และคำที่ติดอยู่) ตามคำอธิบายที่ระบุไว้ข้างต้น

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

ฉันคิดเสมอว่า DLLs และวัตถุที่ใช้ร่วมกันเป็นเพียงคำศัพท์ที่แตกต่างกันสำหรับสิ่งเดียวกัน - Windows เรียกพวกเขาว่า DLLs ในขณะที่บนระบบ UNIX พวกเขากำลังแชร์วัตถุกับคำทั่วไป - ห้องสมุดที่เชื่อมโยงแบบไดนามิก - ครอบคลุมทั้งสอง เปิด. so บน UNIX ถูกเรียกdlopen()หลังจาก 'dynamic library')

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

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

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

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

เชื่อมโยงแบบไดนามิกห้องสมุดบน windows (.dll)เป็นเหมือนห้องสมุดสาธารณะ (ดังนั้น) บนลินุกซ์ แต่มีความแตกต่างบางอย่างระหว่างสองการใช้งานที่เกี่ยวข้องกับระบบปฏิบัติการ (Windows VS Linux):

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

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

ฉันสามารถอธิบายรายละเอียดของ DLLs ใน Windows เพื่อช่วยอธิบายความลึกลับเหล่านั้นให้กับเพื่อน ๆ ของฉันได้ที่ * NIX-land ...

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

Windows DLL มีตารางส่งออก การส่งออกสามารถตามชื่อหรือตามตำแหน่งตาราง (ตัวเลข) วิธีหลังถือเป็น "โรงเรียนเก่า" และมีความเปราะบางมากขึ้น - การสร้าง DLL ขึ้นใหม่และการเปลี่ยนตำแหน่งของฟังก์ชั่นในตารางจะสิ้นสุดลงเมื่อเกิดภัยพิบัติในขณะที่ไม่มีปัญหาจริงหากเชื่อมโยงจุดเข้าเป็นชื่อ ดังนั้นอย่าลืมว่าเป็นปัญหา แต่ควรระวังหากคุณทำงานกับรหัส "ไดโนเสาร์" เช่น libs ผู้ขายบุคคลที่สาม

Windows DLL สร้างขึ้นโดยการคอมไพล์และเชื่อมโยงเช่นเดียวกับที่คุณทำกับ EXE (แอปพลิเคชันที่ปฏิบัติการได้) แต่ DLL นั้นหมายถึงการไม่ทำงานเดี่ยว ๆ เช่นเดียวกับการใช้งาน SO เพื่อให้โปรแกรมใช้งานผ่านการโหลดแบบไดนามิกหรือ โดยการโยงเวลาเชื่อมโยง (การอ้างอิงถึง SO นั้นฝังอยู่ในข้อมูลเมตาของแอ็พพลิเคชันไบนารีและตัวโหลดโปรแกรมระบบปฏิบัติการจะโหลด SO ที่อ้างอิงโดยอัตโนมัติ) DLLs สามารถอ้างอิง DLLs อื่น ๆ เช่นเดียวกับ SOs สามารถอ้างอิง SOs อื่น ๆ

ใน Windows DLLs จะให้เฉพาะจุดเข้าใช้งานที่ระบุเท่านั้น สิ่งเหล่านี้เรียกว่า "การส่งออก" นักพัฒนาสามารถใช้คีย์เวิร์ดคอมไพเลอร์พิเศษเพื่อสร้างสัญลักษณ์ให้มองเห็นได้จากภายนอก (ไปยังตัวเชื่อมโยงอื่นและตัวโหลดแบบไดนามิก) หรือการส่งออกสามารถแสดงรายการในไฟล์โมดูลคำจำกัดความซึ่งใช้ในเวลาเชื่อมโยงเมื่อ DLL เอง กำลังสร้าง แนวปฏิบัติที่ทันสมัยคือการตกแต่งนิยามฟังก์ชั่นด้วยคำหลักเพื่อส่งออกชื่อสัญลักษณ์ นอกจากนี้ยังเป็นไปได้ที่จะสร้างไฟล์ส่วนหัวด้วยคีย์เวิร์ดซึ่งจะประกาศสัญลักษณ์นั้นเป็นไฟล์เดียวที่จะถูกนำเข้าจาก DLL ภายนอกหน่วยการรวบรวมปัจจุบัน ค้นหาคีย์เวิร์ด __declspec (dllexport) และ __declspec (dllimport) สำหรับข้อมูลเพิ่มเติม

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

เมื่อนักพัฒนาต้องการใช้ DLL ที่สร้างขึ้นมาแล้วเธอจะต้องอ้างอิง "ไลบรารีส่งออก" (* .LIB) ที่สร้างโดยนักพัฒนา DLL เมื่อเธอสร้าง DLL ขึ้นมาหรือต้องโหลด DLL ในเวลาใช้งานและขอให้ ที่อยู่จุดเข้าใช้งานตามชื่อผ่านกลไก LoadLibrary () และ GetProcAddress () ส่วนใหญ่แล้วการลิงก์กับไฟล์ LIB (ซึ่งมีเพียงเมตาดาต้าของ linker สำหรับจุดเข้าที่ส่งออกของ DLL) คือวิธีที่ DLLs ใช้งาน การโหลดแบบไดนามิกนั้นสงวนไว้สำหรับการใช้งาน "polymorphism" หรือ "runtime configurability" ในการทำงานของโปรแกรม (การเข้าถึงโปรแกรมเสริมหรือฟังก์ชั่นที่กำหนดในภายหลังหรือที่เรียกว่า "ปลั๊กอิน")

วิธีการทำสิ่งต่าง ๆ ของ Windows อาจทำให้เกิดความสับสนได้ในบางครั้ง ระบบใช้ส่วนขยาย. LIB เพื่ออ้างถึงไลบรารีแบบสแตติกทั่วไป (ไฟล์เก็บถาวรเช่นไฟล์ POSIX * .a) และไลบรารี "export stub" ที่จำเป็นในการผูกแอปพลิเคชันกับ DLL ในเวลาเชื่อมโยง ดังนั้นหนึ่งควรดูเพื่อดูว่าไฟล์ * .LIB มีไฟล์ * .DLL ชื่อเดียวกัน; หากไม่มีโอกาสที่ดีที่ไฟล์ * .LIB จะเป็นไฟล์เก็บถาวรของไลบรารีแบบสแตติกและไม่เอ็กซ์พอร์ตการเชื่อมโยงข้อมูลเมตาสำหรับ DLL

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

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