1. Manuals
  2. Tumbleweed
  3. man-pages-ar
  4. ld.so(8)

Scroll to navigation

ld.so(8) System Manager's Manual 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)).

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

الخيارات

اضبط argv[0] على القيمة string قبل تشغيل البرنامج.
استخدم الكائنات المُسماة في list كمدققين. تُفصل الكائنات في list بنقطتين رأسيتين.
ابحث فقط في الأدلة الفرعية المضمنة إذا كانت في list.
ابحث في الأدلة الفرعية glibc-hwcaps في list.
لا تستخدم /etc/ld.so.cache.
استخدم path بدلاً من إعداد متغير البيئة LD_LIBRARY_PATH (انظر أدناه). تُفسر الأسماء ORIGIN وLIB وPLATFORM كما هو الحال مع متغير البيئة LD_LIBRARY_PATH.
تجاهل معلومات RPATH وRUNPATH في أسماء الكائنات في list. يُتجاهل هذا الخيار عند التشغيل في وضع التنفيذ الآمن (انظر أدناه). تُفصل الكائنات في list بنقطتين رأسيتين أو مسافات.
اسرد كل التبعيات وكيفية حلها.
اطبع معلومات تشخيص النظام بتنسيق قابل للقراءة آليًا، مثل بعض متغيرات المحمل الداخلية، والمتجه المساعد (انظر getauxval(3))، ومتغيرات البيئة. في بعض البنى، قد يطبع الأمر معلومات إضافية (مثل ميزات وحدة المعالجة المركزية المستخدمة في اختيار الدوال غير المباشرة لـ GNU على x86). --list-tunables (منذ glibc 2.33) اطبع أسماء وقيم جميع القابلات للضبط، مع الحد الأدنى والحد الأقصى المسموح بهما.
حمّل مسبقًا الكائنات المحددة في list. تُفصل الكائنات في list بنقطتين رأسيتين أو مسافات. تُحمل الكائنات مسبقًا كما هو موضح في وصف متغير البيئة LD_PRELOAD أدناه.
على النقيض من LD_PRELOAD، يوفر الخيار --preload طريقة لأداء التحميل المسبق لملف تنفيذي واحد دون التأثير على التحميل المسبق المُجرى في أي عملية فرعية تنفذ برنامجًا جديدًا.
تحقق من أن البرنامج مرتبط ديناميكيًا وأن هذا الرابط الديناميكي يمكنه معالجته.

البيئة

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

وضع التنفيذ الآمن

لأسباب أمنية، إذا قرر الرابط الديناميكي أن ملفًا ثنائيًا يجب تشغيله في وضع التنفيذ الآمن، تُبطل أو تُعدل تأثيرات بعض متغيرات البيئة، وعلاوة على ذلك تُزال تلك المتغيرات من البيئة، بحيث لا يرى البرنامج التعريفات حتى. بعض متغيرات البيئة هذه تؤثر على تشغيل الرابط الديناميكي نفسه، وهي موصوفة أدناه. متغيرات البيئة الأخرى المعالجة بهذه الطريقة تشمل: 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.
•
نفذت عملية ذات معرف مستخدم غير جذر ملفًا ثنائيًا منح قدرات للعملية.
•
قد تكون قيمة غير صفرية قد عُينت بواسطة وحدة أمان لينكس.

متغيرات البيئة

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

يمكن لكل كائن مشترك إعلام الرابط الديناميكي بأقل إصدار ABI للنواة الذي يتطلبه. (يُرمّز هذا المطلب في قسم ملاحظات ELF يمكن عرضه عبر readelf -n كقسم معنون NT_GNU_ABI_TAG.) في وقت التشغيل، يحدد الرابط الديناميكي إصدار ABI للنواة الجاري تشغيلها ويرفض تحميل الكائنات المشتركة التي تحدد إصدارات ABI دنيا تتجاوز ذلك الإصدار.
يمكن استخدام 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).
إذا ضُبطت على سلسلة غير فارغة، يتسبب ذلك في حل الرابط الديناميكي لجميع الرموز عند بدء تشغيل البرنامج بدلاً من تأجيل حل استدعاءات الدوال إلى النقطة التي يُشار إليها أولاً. هذا مفيد عند استخدام مصحح أخطاء.
قائمة بالأدلة التي يُبحث فيها عن مكتبات ELF في وقت التنفيذ. تُفصل العناصر في القائمة إما بنقطتين رأسيتين أو فاصلة منقوطة، ولا يوجد دعم لتخطي أي من الفاصلين. يشير اسم الدليل ذو الطول الصفري إلى دليل العمل الحالي.
يُتجاهل هذا المتغير في وضع التنفيذ الآمن.
ضمن أسماء المسارات المحددة في LD_LIBRARY_PATH، يوسع الرابط الديناميكي الرموز $ORIGIN و$LIB و$PLATFORM (أو الإصدارات التي تستخدم الأقواس المعقوفة حول الأسماء) كما هو موصوف أعلاه في Dynamic string tokens. وبالتالي، على سبيل المثال، سيتسبب ما يلي في البحث عن مكتبة إما في الدليل الفرعي lib أو lib64 أسفل الدليل المحتوي على البرنامج المراد تنفيذه:

$ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog

(لاحظ استخدام علامات الاقتباس المفردة، التي تمنع توسيع $ORIGIN و$LIB كمتغيرات شل!)
قائمة بكائنات مشتركة 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 (الموصوف أدناه).
إذا عُيين (إلى أي قيمة)، يتسبب في قيام البرنامج بسرد تبعياته الديناميكية، كما لو شُغل بواسطة ldd(1)، بدلاً من التشغيل العادي.

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

قائمة من الكائنات المشتركة 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 ممكّنًا.
إذا عُيين متغير البيئة هذا إلى سلسلة غير فارغة، لا تقم بتحديث GOT (جدول الإزاحة العام) وPLT (جدول ربط الإجراءات) بعد حل رمز دالة. من خلال الجمع بين استخدام هذا المتغير مع LD_DEBUG (مع الفئات bindings وsymbols)، يمكن للمرء ملاحظة جميع روابط الدوال في وقت التشغيل.
إخراج معلومات تصحيح مفصلة حول تشغيل الرابط الديناميكي. محتوى هذا المتغير هو فئة واحدة أو أكثر من الفئات التالية، مفصولة بنقطتين، أو فواصل، أو (إذا كانت القيمة مقتبسة) مسافات:
تحديد help في قيمة هذا المتغير لا يشغل البرنامج المحدد، ويعرض رسالة مساعدة حول الفئات التي يمكن تحديدها في متغير البيئة هذا.
طباعة جميع معلومات التصحيح (باستثناء statistics وunused؛ انظر أدناه).
عرض معلومات حول التعريف الذي يرتبط به كل رمز.
عرض التقدم لملف الإدخال.
عرض مسارات بحث المكتبات.
عرض معالجة إعادة التحديد.
عرض معلومات النطاق.
عرض إحصائيات إعادة التحديد.
عرض مسارات البحث لكل بحث رمز.
تحديد كائنات DSO غير المستخدمة.
عرض تبعيات الإصدار.
منذ glibc 2.3.4، يُتجاهل LD_DEBUG في وضع التنفيذ الآمن، ما لم يكن الملف /etc/suid-debug موجودًا (محتوى الملف غير ذي صلة).
مبدئيًا، يُكتب مخرج LD_DEBUG إلى الخطأ المعياري. إذا عُرف LD_DEBUG_OUTPUT، يُكتب المخرج إلى اسم المسار المحدد بقيمته، مع اللاحقة "." (نقطة) متبوعة بمعرف العملية المُلحق باسم المسار.
يُتجاهل LD_DEBUG_OUTPUT في وضع التنفيذ الآمن.
بشكل مبدئي، عند البحث في المكتبات المشتركة لحل مرجع رمز، سيقوم الرابط الديناميكي بالحل إلى أول تعريف يجده.
الإصدارات القديمة من glibc (قبل glibc 2.2) قدمت سلوكًا مختلفًا: إذا وجد الرابط رمزًا ضعيفًا، فإنه يتذكر ذلك الرمز ويواصل البحث في المكتبات المشتركة المتبقية. إذا وجد لاحقًا تعريفًا قويًا لنفس الرمز، فإنه يستخدم ذلك التعريف بدلاً من ذلك. (إذا لم يُعثر على رمز إضافي، فإن الرابط الديناميكي يستخدم الرمز الضعيف الذي وجده في البداية.)
السلوك القديم لـ glibc كان غير قياسي. (الممارسة القياسية هي أن التمييز بين الرموز الضعيفة والقوية يجب أن يكون له تأثير فقط في وقت الربط الثابت.) في glibc 2.2، عُدل الرابط الديناميكي لتوفير السلوك الحالي (وهو السلوك الذي قدمته معظم التطبيقات الأخرى في ذلك الوقت).
تعريف متغير البيئة LD_DYNAMIC_WEAK (بأي قيمة) يوفر السلوك القديم (غير القياسي) لـ glibc، حيث يمكن تجاوز رمز ضعيف في مكتبة مشتركة بواسطة رمز قوي يُكتشف لاحقًا في مكتبة مشتركة أخرى. (لاحظ أنه حتى عند تعيين هذا المتغير، فإن الرمز القوي في مكتبة مشتركة لن يتجاوز تعريفًا ضعيفًا لنفس الرمز في البرنامج الرئيس.)
منذ glibc 2.3.4، يتم تجاهل LD_DYNAMIC_WEAK في وضع التنفيذ الآمن.
قناع لقدرات العتاد. منذ glibc 2.26، قد يُتجاهل الخيار إذا كان glibc لا يدعم القابلات للتعديل.
المسار الذي عُثر على الملف الثنائي فيه.
منذ glibc 2.4، يُتجاهل LD_ORIGIN_PATH في وضع التنفيذ الآمن.
اضبط على 0 لتعطيل حماية المؤشر. أي قيمة أخرى تمكن حماية المؤشر، وهو أيضًا المبدئي. حماية المؤشر هي آلية أمان حيث تُشوه بعض المؤشرات إلى الكود المخزن في ذاكرة البرنامج القابلة للكتابة (عناوين العودة المحفوظة بواسطة setjmp(3) أو مؤشرات الدوال المستخدمة بواسطة مكونات glibc الداخلية المختلفة) بشكل شبه عشوائي لجعل من الصعب على المهاجم اختطاف المؤشرات لاستخدامها في حالة تجاوز سعة المخزن المؤقت أو هجوم تحطيم المكدس. منذ glibc 2.23، لم يعد بإمكان LD_POINTER_GUARD استخدامه لتعطيل حماية المؤشر، والتي أصبحت الآن ممكنة دائمًا.
اسم كائن مشترك (واحد) ليُحلل، محدد إما كاسم مسار أو اسم ابن. تُلحق مخرجات التحليل بالملف الذي اسمه: $LD_PROFILE_OUTPUT/$LD_PROFILE.profile.
منذ glibc 2.2.5، يستخدم LD_PROFILE مسارًا مبدئيًا مختلفًا في وضع التنفيذ الآمن.
الدليل حيث يجب كتابة مخرجات LD_PROFILE. إذا لم يُعرف هذا المتغير، أو عُرفه كسلسلة فارغة، فإن المبدئي هو /var/tmp.
يُتجاهل LD_PROFILE_OUTPUT في وضع التنفيذ الآمن؛ بدلاً من ذلك، يُستخدم /var/profile دائمًا.
إذا عُرف متغير البيئة هذا (بأي قيمة)، فستُعرض المصفوفة المساعدة الممررة من النواة (انظر أيضًا getauxval(3)).
منذ glibc 2.3.4، يُتجاهل LD_SHOW_AUXV في وضع التنفيذ الآمن.
إذا عُرف متغير البيئة هذا، يُتتبع الربط المسبق للكائن الذي عُيين اسمه لمتغير البيئة هذا. (استخدم ldd(1) للحصول على قائمة بالكائنات التي قد تُتبع.) إذا لم يتعرف على اسم الكائن، فسيتتبع جميع أنشطة الربط المسبق.
بشكل مبدئي (أي إذا لم يُعرف هذا المتغير)، ستلتزم الملفات التنفيذية والكائنات المشتركة المربوطة مسبقًا بالعناوين الأساسية للكائنات المشتركة التابعة لها، بينما لن تلتزم بها الملفات التنفيذية المستقلة عن الموضع (غير المربوطة مسبقًا) والكائنات المشتركة الأخرى. إذا عُرف LD_USE_LOAD_BIAS بالقيمة 1، فستلتزم كل من الملفات التنفيذية وملفات PIE بالعناوين الأساسية. إذا عُرف LD_USE_LOAD_BIAS بالقيمة 0، فلن تلتزم الملفات التنفيذية ولا ملفات PIE بالعناوين الأساسية.
منذ glibc 2.3.3، يُتجاهل هذا المتغير في وضع التنفيذ الآمن.
إذا عُيين إلى سلسلة غير فارغة، فسيُخرج معلومات إصدار الرموز حول البرنامج إذا عُيين متغير البيئة LD_TRACE_LOADED_OBJECTS.
إذا عُيين إلى سلسلة غير فارغة، فسيُحذر حول الرموز غير المحلولة.
وفقًا لدليل تحسين برامج 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 له تأثير على مستوى النظام، مما يتسبب في التحميل المسبق للمكتبات المحددة لجميع البرامج التي يُنفذها على النظام. (هذا غير مرغوب فيه عادةً، ويُستخدم فقط كعلاج طارئ، على سبيل المثال، كحل مؤقت لمشكلة تكوين مكتبة خاطئ.)
الكائنات المشتركة

ملاحظات

قدرات العتاد القديمة (من glibc 2.5 إلى glibc 2.37)

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

ev4، ev5، ev56، ev6، ev67
loongson2e، loongson2f، octeon، octeon2
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
flush، muldiv، stbar، swap، ultra3، v9، v9v، v9v2
dfp، eimm، esan3، etf3enh، g5، highgprs، hpage، ldisp، msa، stfle، z900، z990، z9-109، z10، zarch
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:. المسارات التالية مدعومة حالياً، بترتيب الأولوية.

power10, power9
z16, z15, z14, z13
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 أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

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

8 فبراير 2026 صفحات دليل لينكس (لم تصدر بعد)