ld.so(8)

الاسم
ld.so, ld-linux.so - رابط/محمل ديناميكي

موجز
يمكن تشغيل الرابط الديناميكي إما بشكل غير مباشر عن طريق تشغيل برنامج مرتبط ديناميكيًا أو كائن مشترك (وفي هذه الحالة لا يمكن تمرير خيارات سطر أوامر للرابط الديناميكي، وفي حالة ELF، يتم تنفيذ الرابط الديناميكي المخزن في قسم .interp من البرنامج) أو بشكل مباشر عن طريق تشغيل:

/lib/ld-linux.so.* [خيارات] [برنامج [وسائط]]

الوصف
يجد البرنامجان ld.so و ld-linux.so* ويحملان الكائنات المشتركة (المكتبات المشتركة) التي يحتاجها البرنامج، ويجهزان البرنامج للتشغيل، ثم يشغلانه.

تتطلب ثنائيات لينكس الربط الديناميكي (الربط في وقت التشغيل) ما لم يتم إعطاء الخيار -static لـ ld(1) أثناء التجميع.

يتعامل البرنامج ld.so مع ثنائيات a.out، وهو تنسيق ثنائي استُخدم منذ زمن بعيد. يتعامل البرنامج ld-linux.so* (/lib/ld-linux.so.1 لـ libc5، /lib/ld-linux.so.2 لـ glibc2) مع الثنائيات الموجودة في تنسيق ELF الأكثر حداثة. كلا البرنامجين لهما نفس السلوك، ويستخدمان نفس ملفات وبرامج الدعم (ldd(1)، ldconfig(8)، و /etc/ld.so.conf).

عند حل تبعيات الكائن المشترك، يفحص الرابط الديناميكي أولاً كل سلسلة تبعية ليرى ما إذا كانت تحتوي على شرطة مائلة (يمكن أن يحدث هذا إذا تم تحديد اسم مسار كائن مشترك يحتوي على شرطات مائلة في وقت الربط). إذا وُجدت شرطة مائلة، فسيتم تفسير سلسلة التبعية كاسم مسار (نسبي أو مطلق)، ويتم تحميل الكائن المشترك باستخدام اسم المسار ذلك.

إذا لم تحتوِ تبعية كائن مشترك على شرطة مائلة، فسيتم البحث عنها بالترتيب التالي:

(1) باستخدام الدلائل المحددة في سمة القسم الديناميكي DT_RPATH للثنائي إذا كانت موجودة وسمة DT_RUNPATH غير موجودة.

(2) باستخدام متغير البيئة LD_LIBRARY_PATH، ما لم يتم تشغيل الملف القابل للتنفيذ في وضع التنفيذ الآمن (انظر أدناه)، وفي هذه الحالة يتم تجاهل هذا المتغير.

(3) باستخدام الدلائل المحددة في سمة القسم الديناميكي DT_RUNPATH للثنائي إذا كانت موجودة. يتم البحث في هذه الدلائل فقط للعثور على الكائنات المطلوبة بواسطة إدخالات DT_NEEDED (التبعيات المباشرة) ولا تنطبق على الكائنات التابعة لها، والتي يجب أن تحتوي هي نفسها على إدخالات DT_RUNPATH خاصة بها. هذا يختلف عن DT_RPATH، الذي يُطبق على عمليات البحث لجميع الكائنات التابعة في شجرة التبعية.

(4) من ملف الخبيئة /etc/ld.so.cache، الذي يحتوي على قائمة مجمعة من الكائنات المشتركة المرشحة التي تم العثور عليها سابقًا في مسار المكتبة المعزز. ومع ذلك، إذا تم ربط الثنائي مع خيار الرابط -z nodefaultlib، فسيتم تخطي الكائنات المشتركة في المسارات المبدئية. يتم تفضيل الكائنات المشتركة المثبتة في دلائل قدرات الأجهزة (انظر أدناه) على الكائنات المشتركة الأخرى.

(5) في المسار المبدئي /lib، ثم /usr/lib. (في بعض البنى 64-بت، المسارات المبدئية للكائنات المشتركة 64-بت هي /lib64، ثم /usr/lib64.) إذا تم ربط الثنائي مع خيار الرابط -z nodefaultlib، فسيتم تخطي هذه الخطوة.

  رموز السلسلة الديناميكية
في عدة أماكن، يقوم الرابط الديناميكي بتوسيع رموز السلسلة الديناميكية:

•   في متغيرات البيئة LD_LIBRARY_PATH و LD_PRELOAD و LD_AUDIT،

•   داخل قيم علامات القسم الديناميكي DT_NEEDED و DT_RPATH و DT_RUNPATH و DT_AUDIT و DT_DEPAUDIT لثنائيات ELF،

•   في وسائط خيارات سطر أوامر ld.so --audit و --library-path و --preload (انظر أدناه)، و

•   في وسائط اسم الملف للدالتين dlopen(3) و dlmopen(3).

الرموز المستبدلة هي كما يلي:

$ORIGIN (أو ما يعادله ${ORIGIN})
    يتوسع هذا إلى الدليل الذي يحتوي على البرنامج أو الكائن المشترك. وبالتالي، يمكن تجميع تطبيق موجود في somedir/app باستخدام

        gcc -Wl,-rpath,'$ORIGIN/../lib'

    بحيث يعثر على كائن مشترك مرتبط في somedir/lib بغض النظر عن موقع somedir في التسلسل الهرمي للدليل. يسهل هذا إنشاء تطبيقات "جاهزة" لا تحتاج إلى التثبيت في أدلة خاصة، بل يمكن بدلاً من ذلك فك ضغطها في أي دليل مع الاستمرار في العثور على كائناتها المشتركة.

$LIB (أو ما يعادله ${LIB})
    يتوسع هذا إلى lib أو lib64 اعتمادًا على البنية (مثلًا، على x86-64، يتوسع إلى lib64 وعلى x86-32، يتوسع إلى lib).

$PLATFORM (أو ما يعادله ${PLATFORM})
    يتوسع هذا إلى سلسلة نصية تتوافق مع نوع معالج النظام المضيف (مثلًا، "x86_64"). في بعض البنيات، لا يوفر نواة لينكس سلسلة منصة للمُوصِل الديناميكي. تؤخذ قيمة هذه السلسلة من قيمة AT_PLATFORM في المتجه المساعد (انظر getauxval(3)).

لاحظ أن رموز السلسلة الديناميكية يجب أن تُقتبس بشكل صحيح عند تعيينها من الصدفة، لمنع توسعها كمتغيرات صدفة أو بيئة.

الخيارات

--argv0 string (منذ glibc 2.33)
    اضبط argv[0] على القيمة string قبل تشغيل البرنامج.

--audit list
    استخدم الكائنات المُسماة في list كمدققين. تُفصل الكائنات في list بنقطتين رأسيتين.

--glibc-hwcaps-mask list
    ابحث فقط في الأدلة الفرعية المضمنة إذا كانت في list.

--glibc-hwcaps-prepend list
    ابحث في الأدلة الفرعية glibc-hwcaps في list.

--inhibit-cache
    لا تستخدم /etc/ld.so.cache.

--library-path path
    استخدم path بدلاً من إعداد متغير البيئة LD_LIBRARY_PATH (انظر أدناه). تُفسر الأسماء ORIGIN وLIB وPLATFORM كما هو الحال مع متغير البيئة LD_LIBRARY_PATH.

--inhibit-rpath list
    تجاهل معلومات RPATH وRUNPATH في أسماء الكائنات في list. يُتجاهل هذا الخيار عند التشغيل في وضع التنفيذ الآمن (انظر أدناه). تُفصل الكائنات في list بنقطتين رأسيتين أو مسافات.

--list
    اسرد كل التبعيات وكيفية حلها.

--list-diagnostics (منذ glibc 2.33)
    اطبع معلومات تشخيص النظام بتنسيق قابل للقراءة آليًا، مثل بعض متغيرات المحمل الداخلية، والمتجه المساعد (انظر getauxval(3))، ومتغيرات البيئة. في بعض البنى، قد يطبع الأمر معلومات إضافية (مثل ميزات وحدة المعالجة المركزية المستخدمة في اختيار الدوال غير المباشرة لـ GNU على x86). --list-tunables (منذ glibc 2.33) اطبع أسماء وقيم جميع القابلات للضبط، مع الحد الأدنى والحد الأقصى المسموح بهما.

--preload list (منذ glibc 2.30)
    حمّل مسبقًا الكائنات المحددة في list. تُفصل الكائنات في list بنقطتين رأسيتين أو مسافات. تُحمل الكائنات مسبقًا كما هو موضح في وصف متغير البيئة LD_PRELOAD أدناه.

    على النقيض من LD_PRELOAD، يوفر الخيار --preload طريقة لأداء التحميل المسبق لملف تنفيذي واحد دون التأثير على التحميل المسبق المُجرى في أي عملية فرعية تنفذ برنامجًا جديدًا.

--verify
    تحقق من أن البرنامج مرتبط ديناميكيًا وأن هذا الرابط الديناميكي يمكنه معالجته.

البيئة
تؤثر متغيرات بيئة متنوعة على تشغيل الرابط الديناميكي.

  وضع التنفيذ الآمن
لأسباب أمنية، إذا قرر الرابط الديناميكي أن ملفًا ثنائيًا يجب تشغيله في وضع التنفيذ الآمن، تُبطل أو تُعدل تأثيرات بعض متغيرات البيئة، وعلاوة على ذلك تُزال تلك المتغيرات من البيئة، بحيث لا يرى البرنامج التعريفات حتى. بعض متغيرات البيئة هذه تؤثر على تشغيل الرابط الديناميكي نفسه، وهي موصوفة أدناه. متغيرات البيئة الأخرى المعالجة بهذه الطريقة تشمل: GCONV_PATH، GETCONF_DIR، HOSTALIASES، LOCALDOMAIN، LD_AUDIT، LD_DEBUG، LD_DEBUG_OUTPUT، LD_DYNAMIC_WEAK، LD_HWCAP_MASK، LD_LIBRARY_PATH، LD_ORIGIN_PATH، LD_PRELOAD، LD_PROFILE، LD_SHOW_AUXV، LOCALDOMAIN، LOCPATH، MALLOC_TRACE، NIS_PATH، NLSPATH، RESOLV_HOST_CONF، RES_OPTIONS، TMPDIR، وTZDIR.

يُشغل ملف ثنائي في وضع التنفيذ الآمن إذا كان للإدخال AT_SECURE في المتجه المساعد (انظر getauxval(3)) قيمة غير صفرية. قد يكون لهذا الإدخال قيمة غير صفرية لأسباب متنوعة، بما في ذلك:

•   تختلف معرفات المستخدم الحقيقية والفعالة للعملية، أو تختلف معرفات المجموعة الحقيقية والفعالة. يحدث هذا عادةً نتيجة تنفيذ برنامج set-user-ID أو set-group-ID.

•   نفذت عملية ذات معرف مستخدم غير جذر ملفًا ثنائيًا منح قدرات للعملية.

•   قد تكون قيمة غير صفرية قد عُينت بواسطة وحدة أمان لينكس.

  متغيرات البيئة
من بين متغيرات البيئة الأكثر أهمية ما يلي:

LD_ASSUME_KERNEL (من glibc 2.2.3 إلى glibc 2.36)
    Each shared object can inform the dynamic linker of the minimum kernel ABI version that it requires. (This requirement is encoded in an ELF note section that is viewable via readelf -n as a section labeled NT_GNU_ABI_TAG.) At run time, the dynamic linker determines the ABI version of the running kernel and will reject loading shared objects that specify minimum ABI versions that exceed that ABI version.

    يمكن استخدام LD_ASSUME_KERNEL لجعل الرابط الديناميكي يفترض أنه يعمل على نظام بإصدار ABI نواة مختلف. على سبيل المثال، يتسبب سطر الأوامر التالي في افتراض الرابط الديناميكي أنه يعمل على Linux 2.2.5 عند تحميل الكائنات المشتركة المطلوبة بواسطة myprog:

        $ LD_ASSUME_KERNEL=2.2.5 ./myprog

    على الأنظمة التي توفر إصدارات متعددة من كائن مشترك (في أدلة مختلفة في مسار البحث) بمتطلبات إصدار ABI نواة دنيا مختلفة، يمكن استخدام LD_ASSUME_KERNEL لاختيار إصدار الكائن المستخدم (اعتمادًا على ترتيب البحث في الدليل).

    تاريخيًا، كان الاستخدام الأكثر شيوعًا لميزة LD_ASSUME_KERNEL هو الاختيار اليدوي لتطبيق LinuxThreads POSIX threads الأقدم على الأنظمة التي توفر كلاً من LinuxThreads وNPTL (والأخير كان المبدئي عادةً على هذه الأنظمة)؛ انظر pthreads(7).

LD_BIND_NOW (منذ glibc 2.1.1)
    إذا ضُبطت على سلسلة غير فارغة، يتسبب ذلك في حل الرابط الديناميكي لجميع الرموز عند بدء تشغيل البرنامج بدلاً من تأجيل حل استدعاءات الدوال إلى النقطة التي يُشار إليها أولاً. هذا مفيد عند استخدام مصحح أخطاء.

LD_LIBRARY_PATH
    قائمة بالأدلة التي يُبحث فيها عن مكتبات ELF في وقت التنفيذ. تُفصل العناصر في القائمة إما بنقطتين رأسيتين أو فاصلة منقوطة، ولا يوجد دعم لتخطي أي من الفاصلين. يشير اسم الدليل ذو الطول الصفري إلى دليل العمل الحالي.

    يُتجاهل هذا المتغير في وضع التنفيذ الآمن.

    ضمن أسماء المسارات المحددة في LD_LIBRARY_PATH، يوسع الرابط الديناميكي الرموز $ORIGIN و$LIB و$PLATFORM (أو الإصدارات التي تستخدم الأقواس المعقوفة حول الأسماء) كما هو موصوف أعلاه في Dynamic string tokens. وبالتالي، على سبيل المثال، سيتسبب ما يلي في البحث عن مكتبة إما في الدليل الفرعي lib أو lib64 أسفل الدليل المحتوي على البرنامج المراد تنفيذه:

        $ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog

    (لاحظ استخدام علامات الاقتباس المفردة، التي تمنع توسيع $ORIGIN و$LIB كمتغيرات شل!)

LD_PRELOAD
    قائمة بكائنات مشتركة ELF إضافية يحددها المستخدم ليتم تحميلها قبل جميع الكائنات الأخرى. يمكن استخدام هذه الميزة لتجاوز دوال في كائنات مشتركة أخرى بشكل انتقائي.

    يمكن فصل عناصر القائمة بمسافات أو نقطتين رأسيتين، ولا يوجد دعم لتخطي أي من الفاصلين. يُبحث عن الكائنات باستخدام القواعد الواردة تحت DESCRIPTION. يُبحث عن الكائنات وتُضاف إلى خريطة الربط بالترتيب من اليسار إلى اليمين المحدد في القائمة.

    في وضع التنفيذ الآمن، تُتجاهل أسماء مسارات التحميل المسبق التي تحتوي على شرطات مائلة. علاوة على ذلك، تُحمّل الكائنات المشتركة مسبقًا فقط من أدلة البحث القياسية وفقط إذا كانت تحتوي على بت وضع set-user-ID ممكّنًا (وهو أمر غير معتاد).

    ضمن الأسماء المحددة في قائمة LD_PRELOAD، يفهم الرابط الديناميكي الرموز $ORIGIN و$LIB و$PLATFORM (أو الإصدارات التي تستخدم الأقواس المعقوفة حول الأسماء) كما هو موصوف أعلاه في Dynamic string tokens. (انظر أيضًا مناقشة الاقتباس تحت وصف LD_LIBRARY_PATH.)

    توجد طرق مختلفة لتحديد المكتبات التي سيتم تحميلها مسبقًا، ويتم التعامل معها بالترتيب التالي:

    (1) متغير البيئة LD_PRELOAD.

    (2) خيار سطر الأوامر --preload عند استدعاء الرابط الديناميكي مباشرة.

    (3) الملف /etc/ld.so.preload (الموصوف أدناه).

LD_TRACE_LOADED_OBJECTS
    إذا تم تعيينه (إلى أي قيمة)، يتسبب في قيام البرنامج بسرد تبعياته الديناميكية، كما لو تم تشغيله بواسطة ldd(1)، بدلاً من التشغيل العادي.

ثم هناك الكثير من المتغيرات الغامضة إلى حد ما، العديد منها قديم أو للاستخدام الداخلي فقط.

LD_AUDIT (منذ glibc 2.4)
    قائمة من الكائنات المشتركة ELF المحددة من قبل المستخدم، يتم تحميلها قبل جميع الكائنات الأخرى في مساحة اسم رابط منفصلة (أي مساحة لا تتداخل مع روابط الرموز العادية التي قد تحدث في العملية). يمكن استخدام هذه الكائنات لتدقيق تشغيل الرابط الديناميكي. العناصر في القائمة مفصولة بنقطتين، ولا يوجد دعم لتجاوز الفاصل.

    يتم تجاهل LD_AUDIT في وضع التنفيذ الآمن.

    سيقوم الرابط الديناميكي بإخطار الكائنات المشتركة للتدقيق عند نقاط التفتيش المسماة بالتدقيق—على سبيل المثال، تحميل كائن مشترك جديد، حل رمز، أو استدعاء رمز من كائن مشترك آخر—عن طريق استدعاء دالة مناسبة داخل الكائن المشترك للتدقيق. للتفاصيل، انظر rtld-audit(7). واجهة التدقيق متوافقة إلى حد كبير مع تلك المقدمة على Solaris، كما هو موصوف في دليل Linker and Libraries Guide، في الفصل Runtime Linker Auditing Interface.

    ضمن الأسماء المحددة في قائمة LD_AUDIT، يفهم الرابط الديناميكي الرموز $ORIGIN و$LIB و$PLATFORM (أو الإصدارات التي تستخدم الأقواس المتعرجة حول الأسماء) كما هو موصوف أعلاه في Dynamic string tokens. (انظر أيضًا مناقشة الاقتباس تحت وصف LD_LIBRARY_PATH.)

    منذ glibc 2.13، في وضع التنفيذ الآمن، يتم تجاهل الأسماء في قائمة التدقيق التي تحتوي على شرطات مائلة، ويتم تحميل الكائنات المشتركة فقط في أدلة البحث القياسية التي تحتوي على بت وضع set-user-ID ممكّنًا.

LD_BIND_NOT (منذ glibc 2.1.95)
    إذا تم تعيين متغير البيئة هذا إلى سلسلة غير فارغة، لا تقم بتحديث GOT (جدول الإزاحة العام) وPLT (جدول ربط الإجراءات) بعد حل رمز دالة. من خلال الجمع بين استخدام هذا المتغير مع LD_DEBUG (مع الفئات bindings وsymbols)، يمكن للمرء ملاحظة جميع روابط الدوال في وقت التشغيل.

LD_DEBUG (منذ glibc 2.1)
    إخراج معلومات تصحيح مفصلة حول تشغيل الرابط الديناميكي. محتوى هذا المتغير هو فئة واحدة أو أكثر من الفئات التالية، مفصولة بنقطتين، أو فواصل، أو (إذا كانت القيمة مقتبسة) مسافات:

    help
        تحديد help في قيمة هذا المتغير لا يشغل البرنامج المحدد، ويعرض رسالة مساعدة حول الفئات التي يمكن تحديدها في متغير البيئة هذا.

    all طباعة جميع معلومات التصحيح (باستثناء statistics وunused؛ انظر أدناه).

    bindings
        عرض معلومات حول التعريف الذي يرتبط به كل رمز.

    ملفات
        عرض التقدم لملف الإدخال.

    مكتبات
        عرض مسارات بحث المكتبات.

    إعادة_تحديد
        عرض معالجة إعادة التحديد.

    نطاقات
        عرض معلومات النطاق.

    إحصائيات
        عرض إحصائيات إعادة التحديد.

    رموز
        عرض مسارات البحث لكل بحث رمز.

    unused
        تحديد كائنات DSO غير المستخدمة.

    إصدارات
        عرض تبعيات الإصدار.

    منذ glibc 2.3.4، يُتجاهل LD_DEBUG في وضع التنفيذ الآمن، ما لم يكن الملف /etc/suid-debug موجودًا (محتوى الملف غير ذي صلة).

LD_DEBUG_OUTPUT (منذ glibc 2.1)
    مبدئيًا، يُكتب مخرج LD_DEBUG إلى الخطأ المعياري. إذا عُرف LD_DEBUG_OUTPUT، يُكتب المخرج إلى اسم المسار المحدد بقيمته، مع اللاحقة "." (نقطة) متبوعة بمعرف العملية المُلحق باسم المسار.

    يُتجاهل LD_DEBUG_OUTPUT في وضع التنفيذ الآمن.

LD_DYNAMIC_WEAK (since glibc 2.1.91)
    بشكل مبدئي، عند البحث في المكتبات المشتركة لحل مرجع رمز، سيقوم الرابط الديناميكي بالحل إلى أول تعريف يجده.

    الإصدارات القديمة من glibc (قبل glibc 2.2) قدمت سلوكًا مختلفًا: إذا وجد الرابط رمزًا ضعيفًا، فإنه يتذكر ذلك الرمز ويواصل البحث في المكتبات المشتركة المتبقية. إذا وجد لاحقًا تعريفًا قويًا لنفس الرمز، فإنه يستخدم ذلك التعريف بدلاً من ذلك. (إذا لم يتم العثور على رمز إضافي، فإن الرابط الديناميكي يستخدم الرمز الضعيف الذي وجده في البداية.)

    السلوك القديم لـ glibc كان غير قياسي. (الممارسة القياسية هي أن التمييز بين الرموز الضعيفة والقوية يجب أن يكون له تأثير فقط في وقت الربط الثابت.) في glibc 2.2، تم تعديل الرابط الديناميكي لتوفير السلوك الحالي (وهو السلوك الذي قدمته معظم التطبيقات الأخرى في ذلك الوقت).

    تعريف متغير البيئة LD_DYNAMIC_WEAK (بأي قيمة) يوفر السلوك القديم (غير القياسي) لـ glibc، حيث يمكن تجاوز رمز ضعيف في مكتبة مشتركة بواسطة رمز قوي يتم اكتشافه لاحقًا في مكتبة مشتركة أخرى. (لاحظ أنه حتى عند تعيين هذا المتغير، فإن الرمز القوي في مكتبة مشتركة لن يتجاوز تعريفًا ضعيفًا لنفس الرمز في البرنامج الرئيسي.)

    منذ glibc 2.3.4، يتم تجاهل LD_DYNAMIC_WEAK في وضع التنفيذ الآمن.

LD_HWCAP_MASK (من glibc 2.1 إلى glibc 2.38)
    قناع لقدرات العتاد. منذ glibc 2.26، قد يتم تجاهل الخيار إذا كان glibc لا يدعم القابلات للتعديل.

LD_ORIGIN_PATH (منذ glibc 2.1)
    المسار حيث يتم العثور على الملف الثنائي.

    منذ glibc 2.4، يتم تجاهل LD_ORIGIN_PATH في وضع التنفيذ الآمن.

LD_POINTER_GUARD (من glibc 2.4 إلى glibc 2.22)
    اضبط على 0 لتعطيل حماية المؤشر. أي قيمة أخرى تمكن حماية المؤشر، وهو أيضًا المبدئي. حماية المؤشر هي آلية أمان حيث يتم تشويه بعض المؤشرات إلى الكود المخزن في ذاكرة البرنامج القابلة للكتابة (عناوين العودة المحفوظة بواسطة setjmp(3) أو مؤشرات الدوال المستخدمة بواسطة مكونات glibc الداخلية المختلفة) بشكل شبه عشوائي لجعل من الصعب على المهاجم اختطاف المؤشرات لاستخدامها في حالة تجاوز سعة المخزن المؤقت أو هجوم تحطيم المكدس. منذ glibc 2.23، لم يعد بإمكان LD_POINTER_GUARD استخدامه لتعطيل حماية المؤشر، والتي أصبحت الآن ممكنة دائمًا.

LD_PROFILE (منذ glibc 2.1)
    اسم كائن مشترك (واحد) ليتم تحليله، محدد إما كاسم مسار أو اسم ابن. يتم إلحاق مخرجات التحليل بالملف الذي اسمه: $LD_PROFILE_OUTPUT/$LD_PROFILE.profile.

    منذ glibc 2.2.5، يستخدم LD_PROFILE مسارًا مبدئيًا مختلفًا في وضع التنفيذ الآمن.

LD_PROFILE_OUTPUT (منذ glibc 2.1)
    الدليل حيث يجب كتابة مخرجات LD_PROFILE. إذا لم يتم تعريف هذا المتغير، أو تم تعريفه كسلسلة فارغة، فإن المبدئي هو /var/tmp.

    يتم تجاهل LD_PROFILE_OUTPUT في وضع التنفيذ الآمن؛ بدلاً من ذلك، يتم استخدام /var/profile دائمًا.

LD_SHOW_AUXV (منذ glibc 2.1)
    إذا تم تعريف متغير البيئة هذا (بأي قيمة)، فسيتم عرض المصفوفة المساعدة الممررة من النواة (انظر أيضًا getauxval(3)).

    منذ glibc 2.3.4، يتم تجاهل LD_SHOW_AUXV في وضع التنفيذ الآمن.

LD_TRACE_PRELINKING (من glibc 2.4 إلى glibc 2.35)
    إذا تم تعريف متغير البيئة هذا، يتم تتبع الربط المسبق للكائن الذي تم تعيين اسمه لمتغير البيئة هذا. (استخدم ldd(1) للحصول على قائمة بالكائنات التي قد يتم تتبعها.) إذا لم يتم التعرف على اسم الكائن، فسيتم تتبع جميع أنشطة الربط المسبق.

LD_USE_LOAD_BIAS (من glibc 2.3.3 إلى glibc 2.35)
    بشكل مبدئي (أي إذا لم يتم تعريف هذا المتغير)، ستلتزم الملفات التنفيذية والكائنات المشتركة المربوطة مسبقًا بالعناوين الأساسية للكائنات المشتركة التابعة لها، بينما لن تلتزم بها الملفات التنفيذية المستقلة عن الموضع (غير المربوطة مسبقًا) والكائنات المشتركة الأخرى. إذا تم تعريف LD_USE_LOAD_BIAS بالقيمة 1، فستلتزم كل من الملفات التنفيذية وملفات PIE بالعناوين الأساسية. إذا تم تعريف LD_USE_LOAD_BIAS بالقيمة 0، فلن تلتزم الملفات التنفيذية ولا ملفات PIE بالعناوين الأساسية.

    منذ glibc 2.3.3، يتم تجاهل هذا المتغير في وضع التنفيذ الآمن.

LD_VERBOSE (منذ glibc 2.1)
    إذا تم تعيينه إلى سلسلة غير فارغة، فسيتم إخراج معلومات إصدار الرموز حول البرنامج إذا تم تعيين متغير البيئة LD_TRACE_LOADED_OBJECTS.

LD_WARN (منذ glibc 2.1.3)
    إذا تم تعيينه إلى سلسلة غير فارغة، فسيتم التحذير حول الرموز غير المحلولة.

LD_PREFER_MAP_32BIT_EXEC (x86-64 فقط؛ منذ glibc 2.23)
    وفقًا لدليل تحسين برامج Intel Silvermont، بالنسبة للتطبيقات 64 بت، قد يتأثر أداء توقع الفروع سلبًا عندما يكون هدف الفرع على بعد أكثر من 4 جيجابايت من الفرع. إذا تم تعيين متغير البيئة هذا (إلى أي قيمة)، فسيحاول الموصّل الديناميكي أولاً تعيين الصفحات القابلة للتنفيذ باستخدام علامة MAP_32BIT من mmap(2)، وسيعود إلى التعيين بدون تلك العلامة إذا فشلت تلك المحاولة. ملاحظة: MAP_32BIT سيعيّن إلى 2 جيجابايت المنخفضة (وليس 4 جيجابايت) من مساحة العنوان.

    نظرًا لأن MAP_32BIT يقلل من نطاق العناوين المتاح لعشوائية تخطيط مساحة العنوان (ASLR)، فإن LD_PREFER_MAP_32BIT_EXEC معطل دائمًا في وضع التنفيذ الآمن.

الملفات

/lib/ld.so
    الموصّل/المُحمّل الديناميكي a.out

/lib/ld-linux.so.{1,2}
    الموصّل/المُحمّل الديناميكي ELF

/etc/ld.so.cache
    ملف يحتوي على قائمة مجمّعة من الدلائل للبحث عن الكائنات المشتركة وقائمة مرتبة من الكائنات المشتركة المرشحة. انظر ldconfig(8).

/etc/ld.so.preload
    ملف يحتوي على قائمة مفصولة بمسافات بيضاء من الكائنات المشتركة ELF التي سيتم تحميلها قبل البرنامج. انظر مناقشة LD_PRELOAD أعلاه. إذا تم استخدام كل من LD_PRELOAD و /etc/ld.so.preload، فسيتم التحميل المسبق للمكتبات المحددة بواسطة LD_PRELOAD أولاً. /etc/ld.so.preload له تأثير على مستوى النظام، مما يتسبب في التحميل المسبق للمكتبات المحددة لجميع البرامج التي يتم تنفيذها على النظام. (هذا غير مرغوب فيه عادةً، ويُستخدم فقط كعلاج طارئ، على سبيل المثال، كحل مؤقت لمشكلة تكوين مكتبة خاطئ.)

lib*.so*
    الكائنات المشتركة

ملاحظات

  قدرات العتاد القديمة (من glibc 2.5 إلى glibc 2.37)
تُجمّع بعض الكائنات المشتركة باستخدام تعليمات خاصة بالعتاد غير موجودة في كل وحدة معالجة مركزية. يجب تثبيت هذه الكائنات في أدلّة تحدد أسماؤها قدرات العتاد المطلوبة، مثل /usr/lib/sse2/. يتحقق الرابط الديناميكي من هذه الأدلّة مقابل عتاد الجهاز ويختار الإصدار الأنسب لكائن مشترك معيّن. يمكن تسلسل أدلّة قدرات العتاد لدمج ميزات وحدة المعالجة المركزية. تعتمد قائمة أسماء قدرات العتاد المدعومة على وحدة المعالجة المركزية. الأسماء التالية معترف بها حاليًا:

Alpha
    ev4، ev5، ev56، ev6، ev67

MIPS
    loongson2e، loongson2f، octeon، octeon2

PowerPC
    4xxmac، altivec، arch_2_05، arch_2_06، booke، cellbe، dfp، efpdouble، efpsingle، fpu، ic_snoop، mmu، notb، pa6t، power4، power5، power5+، power6x، ppc32، ppc601، ppc64، smt، spe، ucache، vsx

SPARC
    flush، muldiv، stbar، swap، ultra3، v9، v9v، v9v2

s390
    dfp، eimm، esan3، etf3enh، g5، highgprs، hpage، ldisp، msa، stfle، z900، z990، z9-109، z10، zarch

x86 (32-bit فقط)
    acpi، apic، clflush، cmov، cx8، dts، fxsr، ht، i386، i486، i586، i686، mca، mmx، mtrr، pat، pbe، pge، pn، pse36، sep، ss، sse، sse2، tm

لدعم قدرات العتاد القديمة عيب يتمثل في أن كل ميزة جديدة تُضاف تزيد مسار البحث بشكل أسي، لأنها تُضاف إلى كل مجموعة من الميزات الأخرى الموجودة.

على سبيل المثال، في x86 32-bit، إذا كان العتاد يدعم i686 وsse2، سيكون مسار البحث الناتج i686/sse2:i686:sse2:.. قدرة جديدة newcap ستضبط مسار البحث إلى newcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2:.

  قدرات عتاد glibc (من glibc 2.33)

أضاف glibc 2.33 مخططًا جديدًا لقدرات العتاد،
    حيث يمكن تعريف مستويات معينة تحت كل بنية وحدة معالجة مركزية، لتجميع دعم ميزات أو تعليمات خاصة معينة. لكل مستوى بنية مجموعة ثابتة من المسارات التي يضيفها إلى قائمة بحث الرابط الديناميكي، اعتمادًا على عتاد الجهاز. نظرًا لأن كل مستوى بنية جديد لا يُدمج مع المستويات الموجودة سابقًا، لا يعاني المخطط الجديد من عيب زيادة قائمة بحث الرابط الديناميكي بشكل غير مسيطر عليه.

على سبيل المثال، في بنية x86 64-بت، إذا دعمت العتاد x86_64-v3 (مثل Intel Haswell أو AMD Excavator)، سيكون مسار البحث الناتج glibc-hwcaps/x86-64-v3:glibc-hwcaps/x86-64-v2:. المسارات التالية مدعومة حالياً، بترتيب الأولوية.

PowerPC (64-بت بنهاية صغيرة فقط)
    power10, power9

s390 (64-بت فقط)
    z16, z15, z14, z13

x86 (64-بت فقط)
    x86-64-v4, x86-64-v3, x86-64-v2

أزال glibc 2.37 دعم القدرات العتادية القديمة.

انظر أيضًا
ld(1), ldd(1), pldd(1), sprof(1), dlopen(3), getauxval(3), elf(5), capabilities(7), rtld-audit(7), ldconfig(8), sln(8)

ترجمة
تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 (https://www.gnu.org/licenses/gpl-3.0.html) أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.