ฉันเข้าใจวิธีกำหนดรวมวัตถุที่ใช้ร่วมกันในการเชื่อมโยง / รวบรวมเวลา อย่างไรก็ตามฉันยังสงสัยว่าไฟล์เรียกทำงานค้นหาวัตถุที่ใช้ร่วมกัน ( *.soไลบรารี) ณ เวลาดำเนินการอย่างไร
ตัวอย่างเช่นแอปของฉันa.outเรียกฟังก์ชั่นที่กำหนดไว้ในlib.soห้องสมุด หลังจากรวบรวมฉันย้ายไปยังไดเรกทอรีใหม่ของฉันlib.so$HOME
ฉันa.outจะบอกให้ไปหาที่นั่นได้อย่างไร
คำตอบ:
HOWTO ห้องสมุดสาธารณะอธิบายมากที่สุดของกลไกที่เกี่ยวข้องและคู่มือรถตักดินแบบไดนามิกไปในรายละเอียดมากขึ้น ตัวแปร unix แต่ละตัวมีวิธีการของตัวเอง แต่ส่วนใหญ่ใช้รูปแบบที่ปฏิบัติการได้เหมือนกัน ( ELF ) และมีตัวเชื่อมโยงแบบไดนามิกที่คล้ายกัน(มาจาก Solaris) ด้านล่างฉันจะสรุปพฤติกรรมทั่วไปโดยมุ่งเน้นที่ Linux ตรวจสอบคู่มือระบบของคุณสำหรับเรื่องราวทั้งหมด
สรุปเมื่อมองหาไลบรารี่แบบไดนามิก ( .soไฟล์) ตัวเชื่อมโยงจะพยายาม:
LD_LIBRARY_PATHตัวแปรสภาพแวดล้อม ( DYLD_LIBRARY_PATHบน OSX);/etc/ld.so.confบวกและ/lib/usr/librpath จะถูกเก็บไว้ในไฟล์เรียกทำงาน (เป็นแอ็ตทริบิวต์DT_RPATHหรือDT_RUNPATHไดนามิก) มันสามารถมีเส้นทางที่แน่นอนหรือเส้นทางที่เริ่มต้นด้วย$ORIGINเพื่อระบุเส้นทางที่สัมพันธ์กับสถานที่ตั้งของปฏิบัติการ (เช่นถ้าที่ปฏิบัติการอยู่ใน/opt/myapp/binและ RPATH ของมัน$ORIGIN/../lib:$ORIGIN/../pluginsแล้วลิงเกอร์แบบไดนามิกจะมีลักษณะใน/opt/myapp/libและ/opt/myapp/plugins) RPATH จะถูกกำหนดตามปกติเมื่อปฏิบัติการจะรวบรวมกับ-rpathตัวเลือกที่จะแต่คุณสามารถเปลี่ยนได้ในภายหลังด้วยldchrpath
ในสถานการณ์ที่คุณอธิบายถ้าคุณพัฒนาหรือแพกเกจของโปรแกรมและตั้งใจเพื่อให้มีการติดตั้งใน…/bin, โครงสร้างแล้วเชื่อมโยงกับ…/lib -rpath='$ORIGIN/../lib'หากคุณกำลังติดตั้งไบนารีที่สร้างไว้ล่วงหน้าในระบบของคุณไม่ว่าจะใส่ห้องสมุดในไดเรกทอรีบนเส้นทางการค้นหา ( /usr/local/libถ้าคุณเป็นผู้ดูแลระบบมิฉะนั้นไดเรกทอรีที่คุณเพิ่ม$LD_LIBRARY_PATH) chrpathหรือลอง
ldconfigมองหาห้องสมุดซึ่งไม่เกี่ยวข้องกับ ldconfigมีส่วนร่วมเมื่อคุณติดตั้งห้องสมุด
*.soห้องสมุดคือไม่ได้$PATHเช่นเดียวกับ เส้นทางการค้นหาตามที่ @enzotib มอบให้ในคำตอบของพวกเขา ldconfig -v 2>/dev/null | grep -v ^$'\t'ที่จะพิมพ์ออกเส้นทางที่จะค้นหาเรียกใช้
/sbin/ldconfigและความมหัศจรรย์อื่นของ Andrew Bate เพื่อให้มันทำงานโดยไม่รูท
ใน Linux พฤติกรรมนั้นได้ถูกอธิบายไว้ในld(1)man page
The linker uses the following search paths to locate required shared libraries: 1. Any directories specified by -rpath-link options. 2. Any directories specified by -rpath options. The difference between -rpath and -rpath-link is that directories specified by -rpath options are included in the executable and used at runtime, whereas the -rpath-link option is only effective at link time. Searching -rpath in this way is only supported by native linkers and cross linkers which have been configured with the --with-sysroot option. 3. On an ELF system, for native linkers, if the -rpath and -rpath-link options were not used, search the contents of the environment variable "LD_RUN_PATH". 4. On SunOS, if the -rpath option was not used, search any directories specified using -L options. 5. For a native linker, the search the contents of the environment variable "LD_LIBRARY_PATH". 6. For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of a shared library are searched for shared libraries needed by it. The "DT_RPATH" entries are ignored if "DT_RUNPATH" entries exist. 7. The default directories, normally /lib and /usr/lib. 8. For a native linker on an ELF system, if the file /etc/ld.so.conf exists, the list of directories found in that file. If the required shared library is not found, the linker will issue a warning and continue with the link.
ldconfigผมค่อนข้างมั่นใจว่าคำตอบที่นี่คือ
ldconfig สร้างลิงค์และแคชที่จำเป็นไปยังไลบรารีที่แชร์ล่าสุดที่พบในไดเรกทอรีที่ระบุในบรรทัดคำสั่งในไฟล์ /etc/ld.so.conf และในไดเรกทอรีที่เชื่อถือได้ (/ lib และ / usr / lib) แคชถูกใช้โดยตัวลิงก์รันไทม์, ld.so หรือ ld-linux.so ldconfig ตรวจสอบส่วนหัวและชื่อไฟล์ของไลบรารีที่พบเมื่อพิจารณาว่าเวอร์ชันใดควรมีการอัพเดตลิงก์
สำหรับการใช้งานแอพพลิเคชั่นไฟล์นั้น/proc/1234/mapsมีไลบรารี่ที่เชื่อมโยงแบบไดนามิกทั้งหมด
ที่ไหน1234เป็น pid ของปฏิบัติการเรียกใช้
Linux ติดตาม LD_LIBRARY_PATH และตัวแปรอื่น ๆ ตามที่ Gilles ได้ชี้แจงไว้
/lib64และ/usr/lib64ใช้สำหรับไบนารี 64 บิต/libและ/usr/libใช้สำหรับไบนารี 32 บิต