ld.so(8) System Manager's Manual ld.so(8)

ld.so, ld-linux.so - پیونددهنده و بارگذار پویای برنامه‌ها

پیونددهنده پویا می‌تواند یا به صورت غیرمستقیم با اجرای یک برنامه پیوند داده شده پویا یا شیء مشترک اجرا شود (که در این حالت هیچ گزینه خط فرمانی به پیونددهنده پویا ارسال نمی‌شود و در حالت ELF، پیونددهنده پویایی که در بخش .interp برنامه ذخیره شده است، اجرا می‌گردد) یا به طور مستقیم با اجرای دستور زیر:

/lib/ld-linux.so.* [OPTIONS] [PROGRAM [ARGUMENTS]]

برنامه‌های 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. (در برخی معماری‌های ۶۴ بیتی، مسیرهای پیش‌فرض برای اشیای مشترک ۶۴ بیتی عبارت‌اند از /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 در کجای سلسله‌مراتب دایرکتوری‌ها واقع شده است، شیء مشترک مرتبط را در somedir/lib بیابد. این قابلیت ساخت برنامه‌های «آماده اجرا» (turn-key) را تسهیل می‌کند که نیازی به نصب در دایرکتوری‌های خاص ندارند، بلکه می‌توان آن‌ها را در هر دایرکتوری استخراج کرد و همچنان اشیای مشترک خود را پیدا کنند.
$LIB (یا به صورت معادل ${LIB})
این نشانه بسته به معماری به lib یا lib64 بسط می‌یابد (برای مثال، در x86-64 به lib64 و در x86-32 به lib بسط می‌یابد).
$PLATFORM (یا به صورت معادل ${PLATFORM})
این نشانه به رشته‌ای متناظر با نوع پردازنده سیستم میزبان (برای مثال "x86_64") بسط می‌یابد. در برخی معماری‌ها، هسته لینوکس رشته پلتفرم را به پیونددهنده پویا ارائه نمی‌دهد. مقدار این رشته از مقدار AT_PLATFORM در بردار کمکی گرفته می‌شود (ببینید getauxval(3)).

توجه داشته باشید که نشانه‌های رشته‌ای پویا هنگام تنظیم از طریق یک پوسته باید به درستی نقل‌قول (quote) شوند تا از بسط آن‌ها به عنوان متغیرهای پوسته یا محیطی جلوگیری شود.

تنظیم argv[0] به مقدار string پیش از اجرای برنامه.
استفاده از اشیای نام‌برده‌شده در list به عنوان حسابرس (auditor). اشیای موجود در list با دونقطه (:) از هم جدا می‌شوند.
تنها در صورتی زیردایرکتوری‌های توکار جستجو می‌شوند که در list باشند.
جستجوی زیردایرکتوری‌های glibc-hwcaps موجود در list.
عدم استفاده از /etc/ld.so.cache.
استفاده از path به جای تنظیمات متغیر محیطی LD_LIBRARY_PATH (پایین‌تر را ببینید). نام‌های ORIGIN، LIB و PLATFORM همانند متغیر محیطی LD_LIBRARY_PATH تفسیر می‌شوند.
نادیده گرفتن اطلاعات RPATH و RUNPATH در نام اشیای موجود در list. این گزینه هنگام اجرا در حالت اجرای امن نادیده گرفته می‌شود (پایین‌تر را ببینید). اشیای موجود در list با دونقطه یا فاصله از هم جدا می‌شوند.
فهرست کردن تمامی وابستگی‌ها و نحوه تفکیک آنها.
--list-diagnostics (از glibc 2.33)
چاپ اطلاعات عیب‌یابی سیستم در قالبی خوانا برای ماشین، از قبیل برخی متغیرهای داخلی بارگذار، بردار کمکی (ببینید getauxval(3)) و متغیرهای محیطی. در برخی معماری‌ها، ممکن است دستور اطلاعات بیشتری را چاپ کند (مانند ویژگی‌های cpu مورد استفاده در انتخاب تابع غیرمستقیم GNU در x86).
--list-tunables (از glibc 2.33)
چاپ نام‌ها و مقادیر تمام پارامترهای تنظیمی (tunables) به همراه حداقل و حداکثر مقادیر مجاز.
پیش‌بارگذاری اشیای مشخص‌شده در list. اشیای موجود در list با دونقطه یا فاصله جدا می‌شوند. اشیاء همان‌طور که در توضیحات متغیر محیطی LD_PRELOAD در زیر آمده است، پیش‌بارگذاری می‌شوند.
برخلاف LD_PRELOAD، گزینه --preload راهکاری برای انجام پیش‌بارگذاری برای یک فایل اجرایی منفرد بدون تأثیر بر پیش‌بارگذاری در فرایندهای فرزندی که برنامه جدیدی را اجرا می‌کنند، فراهم می‌آورد.
بررسی اینکه برنامه به صورت پویا پیوند خورده است و این پیونددهنده پویا می‌تواند آن را مدیریت کند.

متغیرهای محیطی گوناگونی بر عملکرد پیونددهنده پویا اثر می‌گذارند.

به دلایل امنیتی، اگر پیونددهنده پویا تشخیص دهد که یک باینری باید در حالت اجرای امن اجرا شود، اثرات برخی متغیرهای محیطی لغو یا تعدیل می‌شود، و فراتر از آن، این متغیرهای محیطی از محیط برنامه حذف (strip) می‌شوند تا برنامه حتی تعاریف آنها را نبیند. برخی از این متغیرهای محیطی بر عملکرد خود پیونددهنده پویا تأثیر می‌گذارند و در زیر توضیح داده شده‌اند. سایر متغیرهای محیطی که به این صورت با آنها برخورد می‌شود عبارت‌اند از: 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 رخ می‌دهد.
•
فرایندی با شناسه کاربری غیر ریشه، باینری‌ای را اجرا کند که قابلیت‌هایی (capabilities) به فرایند اعطا می‌نماید.
•
یک مقدار غیرصفر ممکن است توسط یک ماژول امنیت لینوکس تنظیم شده باشد.

در میان متغیرهای محیطی مهم‌تر، موارد زیر قرار دارند:

هر شیء مشترک می‌تواند حداقل نسخه ABI هسته مورد نیاز خود را به پیونددهنده پویا اطلاع دهد. (این نیازمندی در یک بخش یادداشت ELF کدگذاری می‌شود که از طریق readelf -n به عنوان بخشی با برچسب NT_GNU_ABI_TAG قابل مشاهده است.) در زمان اجرا، پیونددهنده پویا نسخه ABI هسته در حال اجرا را تعیین می‌کند و از بارگذاری اشیای مشترکی که حداقل نسخه ABI مشخص‌شده در آنها از نسخه جاری فراتر باشد، خودداری می‌کند.
متغیر LD_ASSUME_KERNEL می‌تواند برای این استفاده شود که پیونددهنده پویا فرض کند روی سیستمی با یک نسخه ABI هسته متفاوت در حال اجرا است. برای مثال، دستور زیر باعث می‌شود که پیونددهنده پویا هنگام بارگذاری اشیای مشترک مورد نیاز myprog، فرض کند روی لینوکس 2.2.5 اجرا می‌شود:

$ LD_ASSUME_KERNEL=2.2.5 ./myprog

در سیستم‌هایی که چندین نسخه از یک شیء مشترک (در دایرکتوری‌های مختلف مسیر جستجو) با نیازمندی‌های حداقل نسخه ABI هسته متفاوت ارائه می‌دهند، LD_ASSUME_KERNEL می‌تواند برای انتخاب نسخه‌ای از شیء که استفاده می‌شود (بسته به ترتیب جستجوی دایرکتوری‌ها) به کار رود.
از نظر تاریخی، رایج‌ترین کاربرد قابلیت LD_ASSUME_KERNEL انتخاب دستی پیاده‌سازی قدیمی‌تر نخ‌های پوزیکس LinuxThreads در سیستم‌هایی بود که هر دو پیاده‌سازی LinuxThreads و NPTL را ارائه می‌دادند (که NPTL در چنین سیستم‌هایی معمولاً پیش‌فرض بود)؛ ببینید pthreads(7).
اگر بر روی یک رشته غیرخالی تنظیم شود، موجب می‌شود پیونددهنده پویا تمام نمادها را در زمان راه‌اندازی برنامه تفکیک کند، به جای اینکه تفکیک فراخوانی توابع را تا زمانی که برای نخستین بار ارجاع داده می‌شوند به تعویق بیندازد. این گزینه هنگام استفاده از یک اشکال‌زدا (debugger) مفید است.
فهرستی از دایرکتوری‌ها برای جستجوی کتابخانه‌های ELF در زمان اجرا. آیتم‌های موجود در این فهرست با دونقطه یا نقطه‌ویرگول جدا می‌شوند، و هیچ پشتیبانی برای گریز (escape) دادن این جداکننده‌ها وجود ندارد. نام دایرکتوری با طول صفر نشان‌دهنده دایرکتوری کاری جاری است.
این متغیر در حالت اجرای امن نادیده گرفته می‌شود.
درون مسیرهای مشخص‌شده در LD_LIBRARY_PATH، پیونددهنده پویا نشانه‌های $ORIGIN، $LIB و $PLATFORM (یا نسخه‌هایی با استفاده از آکولاد در اطراف نام‌ها) را همان‌طور که در بالا تحت عنوان نشانه‌های رشته‌ای پویا شرح داده شد، بسط می‌دهد. بنابراین، برای مثال، دستور زیر باعث می‌شود که یک کتابخانه در زیردایرکتوری lib یا lib64 در زیر دایرکتوری حاوی برنامه مورد اجرا جستجو شود:

$ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog

(به استفاده از نقل‌قول تکی دقت کنید، که مانع از بسط $ORIGIN و $LIB به عنوان متغیرهای پوسته می‌شود!)
فهرستی از اشیای مشترک ELF اضافی مشخص‌شده توسط کاربر که باید قبل از بقیه بارگذاری شوند. این قابلیت می‌تواند برای جایگزینی (override) انتخابی توابع در سایر اشیای مشترک استفاده شود.
آیتم‌های این فهرست را می‌توان با فاصله یا دونقطه از هم جدا کرد و هیچ پشتیبانی برای گریز دادن این جداکننده‌ها وجود ندارد. اشیاء با استفاده از قواعد ارائه‌شده در بخش «توضیحات» جستجو می‌شوند. اشیاء به ترتیبی از چپ به راست که در فهرست مشخص شده‌اند جستجو شده و به نگاشت پیوند (link map) اضافه می‌شوند.
در حالت اجرای امن، نام مسیرهای پیش‌بارگذاری حاوی اسلش نادیده گرفته می‌شوند. علاوه بر این، اشیای مشترک فقط از دایرکتوری‌های جستجوی استاندارد و تنها در صورتی پیش‌بارگذاری می‌شوند که بیت حالت set-user-ID آنها فعال باشد (که این امری نامعمول است).
درون نام‌های مشخص‌شده در فهرست LD_PRELOAD، پیونددهنده پویا نشانه‌های $ORIGIN، $LIB و $PLATFORM (یا نسخه‌های دارای آکولاد در اطراف نام‌ها) را همان‌طور که در بالا تحت عنوان نشانه‌های رشته‌ای پویا شرح داده شد، درک می‌کند. (همچنین به بحث نقل‌قول در ذیل توضیحات LD_LIBRARY_PATH مراجعه کنید.)
روش‌های گوناگونی برای تعیین کتابخانه‌ها جهت پیش‌بارگذاری وجود دارد، و این روش‌ها به ترتیب زیر پردازش می‌شوند:
(1)
متغیر محیطی LD_PRELOAD.
(2)
گزینه خط فرمان --preload هنگام فراخوانی مستقیم پیونددهنده پویا.
(3)
فایل /etc/ld.so.preload (توضیح داده شده در زیر).
در صورت تنظیم شدن (روی هر مقداری)، باعث می‌شود برنامه به جای اجرای عادی، وابستگی‌های پویای خود را فهرست کند، گویی توسط ldd(1) اجرا شده است.

سپس تعداد زیادی متغیر کم‌وبیش مبهم وجود دارد که بسیاری از آنها منسوخ شده‌اند یا صرفاً برای استفاده داخلی هستند.

فهرستی از اشیای مشترک ELF مشخص‌شده توسط کاربر که باید قبل از بقیه در یک فضای نام پیونددهنده جداگانه بارگذاری شوند (یعنی فضایی که در مقیدسازی‌های عادی نمادها که در فرایند رخ می‌دهد تداخلی ایجاد نمی‌کند). این اشیاء می‌توانند برای حسابرسی و بازرسی عملکرد پیونددهنده پویا استفاده شوند. آیتم‌های موجود در فهرست با دونقطه جدا می‌شوند و هیچ پشتیبانی برای گریز از جداکننده وجود ندارد.
متغیر LD_AUDIT در حالت اجرای امن نادیده گرفته می‌شود.
پیونددهنده پویا، اشیای مشترک حسابرسی را در به اصطلاح نقاط بازرسی حسابرسی—برای مثال، بارگذاری یک شیء مشترک جدید، تفکیک یک نماد، یا فراخوانی یک نماد از یک شیء مشترک دیگر—از طریق فراخوانی یک تابع مناسب درون شیء مشترک حسابرسی مطلع می‌سازد. برای جزئیات، ببینید rtld-audit(7). رابط حسابرسی تا حد زیادی با رابط ارائه‌شده در Solaris سازگار است، همان‌طور که در راهنمای پیونددهنده و کتابخانه‌ها آن، در فصل رابط حسابرسی پیونددهنده زمان اجرا توضیح داده شده است.
درون نام‌های مشخص‌شده در فهرست LD_AUDIT، پیونددهنده پویا نشانه‌های $ORIGIN، $LIB و $PLATFORM (یا نسخه‌های دارای آکولاد در اطراف نام‌ها) را همان‌طور که در بالا در بخش نشانه‌های رشته‌ای پویا توضیح داده شد درک می‌کند. (همچنین به بحث پیرامون نقل‌قول ذیل توضیحات LD_LIBRARY_PATH رجوع کنید.)
از glibc 2.13، در حالت اجرای امن، نام‌های موجود در فهرست حسابرسی که حاوی اسلش هستند نادیده گرفته می‌شوند، و تنها اشیای مشترکی در دایرکتوری‌های جستجوی استاندارد که بیت حالت set-user-ID در آنها فعال باشد بارگذاری می‌شوند.
اگر این متغیر محیطی روی یک رشته غیرخالی تنظیم شود، پس از تفکیک یک نماد تابع، جدول‌های GOT (جدول آفست سراسری) و PLT (جدول پیوند رویه‌ها) را به‌روزرسانی نمی‌کند. با ترکیب استفاده از این متغیر با LD_DEBUG (با دسته‌های bindings و symbols)، می‌توان تمامی مقیدسازی‌های توابع در زمان اجرا را مشاهده کرد.
خروجی پرگو از اطلاعات اشکال‌زدایی درباره عملکرد پیونددهنده پویا. محتوای این متغیر شامل یک یا چند دسته از موارد زیر است که با دونقطه، کاما یا (اگر مقدار نقل‌قول شده باشد) فاصله از هم جدا می‌شوند:
تعیین help در مقدار این متغیر، برنامه مشخص‌شده را اجرا نمی‌کند و پیامی راهنما درباره اینکه چه دسته‌هایی را می‌توان در این متغیر محیطی تعیین کرد نمایش می‌دهد.
چاپ تمامی اطلاعات اشکال‌زدایی (به جز statistics و unused؛ پایین‌تر را ببینید).
نمایش اطلاعات درباره اینکه هر نماد به کدام تعریف مقید شده است.
نمایش پیشرفت پردازش فایل ورودی.
نمایش مسیرهای جستجوی کتابخانه‌ها.
نمایش پردازش بازنشانی‌ها (relocations).
نمایش اطلاعات حوزه (scope).
نمایش آمار بازنشانی‌ها.
نمایش مسیرهای جستجو برای هر جستجوی نماد.
تشخیص DSOهای استفاده‌نشده.
نمایش وابستگی‌های نسخه‌ای.
از glibc 2.3.4، متغیر LD_DEBUG در حالت اجرای امن نادیده گرفته می‌شود، مگر اینکه فایل /etc/suid-debug وجود داشته باشد (محتوای فایل اهمیتی ندارد).
به طور پیش‌فرض، خروجی LD_DEBUG در خطای استاندارد نوشته می‌شود. اگر LD_DEBUG_OUTPUT تعریف شده باشد، خروجی در نام مسیری که توسط مقدار آن تعیین شده نوشته می‌شود، به همراه پسوند "." (نقطه) و در ادامه شناسه فرایند (PID) که به انتهای نام مسیر اضافه می‌گردد.
متغیر LD_DEBUG_OUTPUT در حالت اجرای امن نادیده گرفته می‌شود.
به طور پیش‌فرض، هنگام جستجوی کتابخانه‌های مشترک برای تفکیک یک ارجاع نماد، پیونددهنده پویا به اولین تعریفی که پیدا کند تفکیک را انجام می‌دهد.
نسخه‌های قدیمی glibc (قبل از glibc 2.2)، رفتار متفاوتی ارائه می‌دادند: اگر پیونددهنده نمادی را پیدا می‌کرد که ضعیف (weak) بود، آن نماد را به خاطر می‌سپرد و به جستجو در بقیه کتابخانه‌های مشترک ادامه می‌داد. اگر در ادامه تعریفی قوی (strong) از همان نماد پیدا می‌کرد، در عوض از آن تعریف استفاده می‌نمود. (اگر نماد دیگری یافت نمی‌شد، پیونددهنده پویا از همان نماد ضعیفی که در ابتدا یافته بود استفاده می‌کرد.)
رفتار قدیمی glibc غیراستاندارد بود. (رویه استاندارد این است که تمایز میان نمادهای ضعیف و قوی فقط در زمان پیوند ایستا مؤثر باشد.) در glibc 2.2، پیونددهنده پویا اصلاح شد تا رفتار فعلی را ارائه دهد (که رفتاری بود که بیشتر پیاده‌سازی‌های دیگر در آن زمان ارائه می‌کردند).
تعریف متغیر محیطی LD_DYNAMIC_WEAK (با هر مقداری) رفتار قدیمی (غیراستاندارد) glibc را فراهم می‌آورد، که به موجب آن ممکن است یک نماد ضعیف در یک کتابخانه مشترک توسط یک نماد قوی که پس از آن در کتابخانه مشترک دیگری کشف می‌شود جایگزین (override) گردد. (توجه داشته باشید که حتی زمانی که این متغیر تنظیم شده باشد، یک نماد قوی در یک کتابخانه مشترک تعریف ضعیف از همان نماد در برنامه اصلی را بازنویسی نخواهد کرد.)
از glibc 2.3.4، متغیر LD_DYNAMIC_WEAK در حالت اجرای امن نادیده گرفته می‌شود.
ماسک برای قابلیت‌های سخت‌افزاری. از glibc 2.26، اگر glibc از متغیرهای تنظیمی (tunables) پشتیبانی نکند، ممکن است این گزینه نادیده گرفته شود.
مسیری که فایل باینری در آن قرار دارد.
از glibc 2.4، متغیر LD_ORIGIN_PATH در حالت اجرای امن نادیده گرفته می‌شود.
تنظیم روی 0 برای غیرفعال کردن محافظت از اشاره‌گرها (pointer guarding). هر مقدار دیگری محافظت از اشاره‌گرها را فعال می‌کند که حالت پیش‌فرض نیز هست. محافظت از اشاره‌گر یک سازوکار امنیتی است که به موجب آن برخی اشاره‌گرها به کد ذخیره‌شده در حافظه قابل نوشتن برنامه (آدرس‌های بازگشتی ذخیره‌شده توسط setjmp(3) یا اشاره‌گرهای تابع مورد استفاده در بخش‌های داخلی مختلف glibc) به صورت شبه‌تصادفی درهم‌ریخته (mangle) می‌شوند تا ربودن اشاره‌گرها توسط یک مهاجم برای استفاده در صورت سرریز بافر یا حمله تخریب پشته (stack-smashing) دشوارتر گردد. از glibc 2.23، متغیر LD_POINTER_GUARD دیگر نمی‌تواند برای غیرفعال کردن محافظت از اشاره‌گرها استفاده شود، و این ویژگی اکنون همیشه فعال است.
نام یک شیء مشترک (واحد) برای پروفایل‌گیری، که یا به صورت یک نام مسیر یا یک soname تعیین می‌شود. خروجی پروفایل‌گیری به انتهای فایلی با نام زیر افزوده می‌گردد: $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 در حالت اجرای امن نادیده گرفته می‌شود.
اگر این متغیر محیطی تعریف شده باشد، پیش‌پیوند (prelinking) شیئی را که نام آن به این متغیر اختصاص داده شده ردگیری می‌کند. (از ldd(1) برای دریافت فهرستی از اشیایی که ممکن است ردگیری شوند استفاده کنید.) اگر نام شیء شناسایی نشود، تمامی فعالیت‌های پیش‌پیوند ردگیری می‌شوند.
به طور پیش‌فرض (یعنی اگر این متغیر تعریف نشده باشد)، فایل‌های اجرایی و اشیای مشترک پیش‌پیوندشده از آدرس‌های پایه اشیای مشترک وابسته به خود تبعیت می‌کنند و فایل‌های اجرایی مستقل از موقعیت (PIE) غیرپیش‌پیوندشده و سایر اشیای مشترک از آنها تبعیت نمی‌کنند. اگر LD_USE_LOAD_BIAS با مقدار 1 تعریف شده باشد، هم فایل‌های اجرایی و هم PIEها از آدرس‌های پایه تبعیت می‌کنند. اگر LD_USE_LOAD_BIAS با مقدار 0 تعریف شده باشد، نه فایل‌های اجرایی و نه PIEها از آدرس‌های پایه تبعیت نخواهند کرد.
از glibc 2.3.3، این متغیر در حالت اجرای امن نادیده گرفته می‌شود.
اگر روی یک رشته غیرخالی تنظیم شود، در صورتی که متغیر محیطی LD_TRACE_LOADED_OBJECTS تنظیم شده باشد، اطلاعات نسخه‌بندی نمادهای برنامه را در خروجی نمایش می‌دهد.
اگر روی یک رشته غیرخالی تنظیم شود، درباره نمادهای تفکیک‌نشده هشدار می‌دهد.
بر اساس راهنمای بهینه‌سازی نرم‌افزاری Intel Silvermont، برای برنامه‌های ۶۴ بیتی، در صورتی که مقصد یک انشعاب (branch) بیش از ۴ گیگابایت از انشعاب فاصله داشته باشد، کارایی پیش‌بینی انشعاب می‌تواند تحت تأثیر منفی قرار گیرد. اگر این متغیر محیطی تنظیم شده باشد (روی هر مقداری)، پیونددهنده پویا ابتدا تلاش می‌کند صفحه‌های اجرایی را با استفاده از پرچم MAP_32BIT دستور mmap(2) نگاشت کند، و اگر آن تلاش شکست بخورد، به نگاشت بدون آن پرچم بازمی‌گردد. توجه: MAP_32BIT نگاشت را در ۲ گیگابایت پایینی (نه ۴ گیگابایت) فضای آدرس انجام می‌دهد.
از آنجا که MAP_32BIT محدوده آدرس در دسترس برای تصادفی‌سازی چیدمان فضای آدرس (ASLR) را کاهش می‌دهد، LD_PREFER_MAP_32BIT_EXEC همواره در حالت اجرای امن غیرفعال است.

/lib/ld.so
پیونددهنده و بارگذار پویای a.out
/lib/ld-linux.so.{1,2}
پیونددهنده و بارگذار پویای ELF
/etc/ld.so.cache
فایلی شامل فهرستی کامپایل‌شده از دایرکتوری‌ها برای جستجوی اشیای مشترک، فهرستی مرتب‌شده از اشیای مشترک کاندید، و هرگونه متغیر تنظیمی (tunables) که باید اعمال شود. ببینید ldconfig(8).
/etc/ld.so.preload
فایلی شامل فهرستی با جداکننده فاصله از اشیای مشترک ELF که باید پیش از برنامه بارگذاری شوند. توضیحات مربوط به LD_PRELOAD در بالا را ببینید. اگر هر دو مورد LD_PRELOAD و /etc/ld.so.preload به کار گرفته شوند، کتابخانه‌های مشخص‌شده توسط LD_PRELOAD ابتدا پیش‌بارگذاری می‌شوند. فایل /etc/ld.so.preload تأثیری در سطح سراسر سیستم دارد و باعث می‌شود کتابخانه‌های تعیین‌شده برای تمامی برنامه‌هایی که در سیستم اجرا می‌شوند پیش‌بارگذاری گردند. (این امر معمولاً نامطلوب است و معمولاً تنها به عنوان یک چاره‌اندیشی اضطراری به کار می‌رود، برای مثال به عنوان یک راهکار موقت برای مشکل پیکربندی نادرست کتابخانه.)
اشیای مشترک

برخی اشیای مشترک با استفاده از دستورالعمل‌های خاص سخت‌افزاری کامپایل می‌شوند که در تمامی پردازنده‌ها وجود ندارند. چنین اشیایی باید در دایرکتوری‌هایی نصب شوند که نام‌های آن‌ها قابلیت‌های سخت‌افزاری مورد نیاز را تعریف می‌کند، مانند /usr/lib/sse2/. پیونددهنده پویا این دایرکتوری‌ها را با سخت‌افزار ماشین بررسی می‌کند و مناسب‌ترین نسخه از یک شیء مشترک معین را انتخاب می‌نماید. دایرکتوری‌های قابلیت سخت‌افزاری می‌توانند به صورت آبشاری ترکیب شوند تا ویژگی‌های CPU را تجمیع کنند. فهرست نام‌های پشتیبانی‌شده قابلیت‌های سخت‌افزاری بستگی به CPU دارد. نام‌های زیر در حال حاضر شناخته می‌شوند:

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 ۳۲ بیتی، اگر سخت‌افزار از i686 و sse2 پشتیبانی کند، مسیر جستجوی حاصل به صورت i686/sse2:i686:sse2:. خواهد بود. یک قابلیت جدید به نام newcap مسیر جستجو را به صورت newcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2: تنظیم خواهد کرد.

در glibc 2.33 یک طرح جدید قابلیت‌های سخت‌افزاری اضافه شد، که تحت هر معماری CPU، سطوح خاصی می‌توانند تعریف شوند که پشتیبانی از ویژگی‌های خاص یا دستورالعمل‌های ویژه را گروه‌بندی می‌کنند. هر سطح معماری مجموعه‌ای ثابت از مسیرها دارد که بسته به سخت‌افزار ماشین، آنها را به فهرست جستجوی پیونددهنده پویا اضافه می‌کند. از آنجا که هر سطح معماری جدید با سطوح قبلی ترکیب نمی‌شود، طرح جدید عیب رشد کنترل‌نشده فهرست جستجوی پیونددهنده پویا را ندارد.

برای مثال، در x86 ۶۴ بیتی، اگر سخت‌افزار از x86_64-v3 (برای نمونه Intel Haswell یا AMD Excavator) پشتیبانی کند، مسیر جستجوی حاصل به صورت زیر خواهد بود: glibc-hwcaps/x86-64-v3:glibc-hwcaps/x86-64-v2:. مسیرهای زیر در حال حاضر به ترتیب اولویت پشتیبانی می‌شوند:

PowerPC (فقط ۶۴ بیتی little-endian)
power10, power9
s390 (فقط ۶۴ بیتی)
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), ld.so.conf(8), capabilities(7), rtld-audit(7), ldconfig(8), sln(8)

2026-08-03 Linux man-pages 6.19