লিনাক্সে LD_LIBRARY_PATH: সঠিক ব্যবহার, ঝুঁকি এবং বিকল্প

ইনফরমেটেক ডিজিটাল » রিসোর্স » লিনাক্সে LD_LIBRARY_PATH: সঠিক ব্যবহার, ঝুঁকি এবং বিকল্পসমূহ

LD_LIBRARY_PATH হলো লিনাক্সের সেইসব এনভায়রনমেন্ট ভেরিয়েবলগুলোর মধ্যে একটি, যা কমবেশি সবারই চোখে পড়ে, কিন্তু খুব কম লোকই এটি পুরোপুরি বোঝে এবং সর্বোপরি, এটি প্রায়শই ভুলভাবে ব্যবহৃত হয়। যখন আপনি শেয়ার্ড লাইব্রেরি, চালু না হওয়া এক্সিকিউটেবল, বা নিজস্ব লাইব্রেরির প্রয়োজন এমন অ্যাপ্লিকেশন নিয়ে সমস্যায় পড়েন, তখন এই নামটি বারবার সামনে আসে।

এই আর্টিকেলে আমরা আলোচনা করব LD_LIBRARY_PATH কী, ডাইনামিক লোডার অভ্যন্তরীণভাবে কীভাবে কাজ করে , কখন এই ভ্যারিয়েবলটি ব্যবহার করা যুক্তিযুক্ত এবং কখন এটি এড়িয়ে চলাই ভালো। আমরা উবুন্টুর মতো ডিস্ট্রিবিউশনের বাস্তব উদাহরণ দেখব (যদিও এটি প্রায় যেকোনো ডিস্ট্রোর ক্ষেত্রেই প্রযোজ্য), কীভাবে এটি সঠিকভাবে কনফিগার করতে হয় তা ব্যাখ্যা করব এবং আপনার ইউজার প্রোফাইলের সাথে এই ভ্যারিয়েবলটিকে স্থায়ীভাবে যুক্ত রাখার পরিবর্তে আরও অনেক পরিচ্ছন্ন ও নিরাপদ বিকল্পগুলো পর্যালোচনা করব।

LD_LIBRARY_PATH কী এবং এটি আসলে কীসের জন্য ব্যবহৃত হয়?

আধুনিক GNU/Linux সিস্টেমে, বেশিরভাগ প্রোগ্রাম এর সাথে লিঙ্ক করে শেয়ার্ড লাইব্রেরি (.so ফাইল) যা এক্সিকিউটেবল শুরু করার সময় মেমরিতে লোড হয়। রানটাইমে এই লাইব্রেরিগুলি খুঁজে বের করার জন্য দায়ী উপাদান হল গতিশীল চার্জার (সাধারণত ld.so অথবা বিভিন্নতা যেমন ld-linux-x86-64.so.2 স্থাপত্য অনুসারে)।

পরিবেশ পরিবর্তনশীল LD_LIBRARY_PATH ডিরেক্টরিগুলির একটি তালিকা সংজ্ঞায়িত করে যেখানে একটি প্রোগ্রাম চালু হওয়ার সময় ডাইনামিক লোডার সেই শেয়ার্ড লাইব্রেরিগুলি খুঁজবে। এটি একটি কোলন-বিভাজিত তালিকা, এরকম কিছু /ruta/uno:/ruta/dos:/otra/rutaএবং এটি নিয়ে পরামর্শ করা হয় স্ট্যান্ডার্ড রুটের আগে সিস্টেমের হিসাবে /lib o /usr/lib.

এর মানে হলো, যদি LD_LIBRARY_PATH-এ থাকা কোনো লাইব্রেরির নাম সিস্টেম ডিরেক্টরিতে থাকা অন্য কোনো লাইব্রেরির নামের সাথে মিলে যায়, তাহলে লোডার LD_LIBRARY_PATH-এ থাকা লাইব্রেরিটিকেই অগ্রাধিকার দেবে । এটাই এর শক্তিশালী দিক... এবং অসতর্কভাবে ব্যবহার করলে এটিই অনেক সমস্যার মূল কারণ হয়ে দাঁড়ায়।

এই পদ্ধতিটি বিশেষত অ-প্রমিত লাইব্রেরি পাথ নিয়ে কাজ করার সময় উপযোগী , যেমন—নিক্স-সদৃশ পরিবেশ, ব্যবহারকারীর ডিরেক্টরিতে ইনস্টলেশন, লাইব্রেরির কাস্টম সংস্করণ, অথবা এমন অ্যাপ্লিকেশন যা নিজস্ব নির্ভরতা সহ প্যাকেজ করা থাকে এবং সিস্টেম লাইব্রেরি থেকে ডেটা নিতে চায় না।

LD_LIBRARY_PATH এর জন্য সাধারণ ব্যবহারের ক্ষেত্রে

খুবই নির্দিষ্ট এবং নিয়ন্ত্রিত পরিস্থিতিতে LD_LIBRARY_PATH ব্যবহার করা যুক্তিযুক্ত । যদি আপনি এই ক্ষেত্রগুলিতেই সীমাবদ্ধ থাকেন, তবে এটি একটি অত্যন্ত কার্যকর উপায়; কিন্তু যদি আপনি এটিকে সবকিছুর জন্য আপনার ডিফল্ট সমাধান বানিয়ে ফেলেন, তবে শীঘ্রই বা দেরিতে এর কোনো না কোনো ফল পাওয়া যাবে।

সবচেয়ে সাধারণ ব্যবহারগুলির মধ্যে একটি হল একটি শেয়ার্ড লাইব্রেরির একটি নতুন সংস্করণ চেষ্টা করুন সিস্টেম লাইব্রেরি স্পর্শ না করেই, একটি পূর্ব-সংকলিত অ্যাপ্লিকেশনের বিপরীতে। উদাহরণস্বরূপ, যদি আপনি এর একটি ডেভেলপমেন্ট সংস্করণ তৈরি করে থাকেন libmylib.so আপনার হোম ডিরেক্টরিতে, আপনি LD_LIBRARY_PATH সামঞ্জস্য করতে পারেন যাতে শুধুমাত্র আপনার পরীক্ষার সেশন এটি ব্যবহার করতে পারে।

আরেকটি খুব সাধারণ পরিস্থিতি হলো পুরোনো সংস্করণগুলো সংরক্ষণ করার জন্য লাইব্রেরি স্থানান্তর করা । ধরুন, আপনি একটি লিগ্যাসি অ্যাপ্লিকেশনের জন্য কোনো লাইব্রেরির পুরোনো সংস্করণ রাখতে চান, অথচ সিস্টেমের বাকি অংশ একটি নতুন সংস্করণ ব্যবহার করছে; LD_LIBRARY_PATH ব্যবহার করে আপনি সেই নির্দিষ্ট অ্যাপ্লিকেশনটিকে পুরোনো সংস্করণটির ডিরেক্টরিতে নির্দেশ করতে পারেন।

এটি প্রায়শই বড় অ্যাপ্লিকেশনগুলির জন্য স্বয়ংসম্পূর্ণ এবং স্থানান্তরযোগ্য পরিবেশ তৈরি করতে ব্যবহৃত হয় , যেখানে বিক্রেতা সিস্টেম লাইব্রেরির উপর নির্ভর না করে একটি ফোল্ডারের মধ্যে তার নিজস্ব লাইব্রেরিগুলি প্যাকেজ করে। এইসব ক্ষেত্রে, সাধারণত একটি স্টার্টআপ স্ক্রিপ্ট থাকে যা LD_LIBRARY_PATH সমন্বয় করে, যাতে অ্যাপ্লিকেশনটি সর্বদা তার নিজস্ব .so ফাইলগুলি লোড করে।

এই সমস্ত ক্ষেত্রে মূল বিষয়টি হলো যে, LD_LIBRARY_PATH একটি সীমিত ও সুনির্দিষ্ট উপায়ে ব্যবহৃত হয় , যা কোনো নির্দিষ্ট অ্যাপ্লিকেশন বা টেস্ট এনভায়রনমেন্টের সাথে যুক্ত থাকে; এটি এমন কোনো গ্লোবাল ভেরিয়েবল হিসেবে ব্যবহৃত হয় না যা ব্যবহারকারীর চালানো সবকিছু বা পুরো সিস্টেমকে প্রভাবিত করে।

ধাপে ধাপে লিনাক্সে LD_LIBRARY_PATH কীভাবে কনফিগার করবেন

ঝুঁকিগুলি জেনেও, আপনি এখনও চান আপনার ব্যবহারকারী পরিবেশে LD_LIBRARY_PATH সংজ্ঞায়িত করুনউবুন্টুর মতো ডিস্ট্রিবিউশনে, ফাইল সম্পাদনা করা সাধারণ ~/.bashrc (ধরে নিচ্ছি আপনি আপনার ডিফল্ট শেল হিসেবে Bash ব্যবহার করছেন)। এটি এমন একটি ফাইল যা প্রতিবার নতুন ইন্টারেক্টিভ টার্মিনাল খুললেই চলবে।

শুরু করতে, ফাইলটি খুলুন আপনার পছন্দের এডিটর দিয়ে .bashrcএটি অনেক টিউটোরিয়ালে ব্যবহৃত হয় nano সরলতার জন্য, কিন্তু আপনি একই কাজ করতে পারেন vi, vim অথবা যেকোনো টেক্সট এডিটর:

ন্যানো ~ /। bashrc

একবার খোলা হলে, ভেরিয়েবল সেট করার জন্য আপনাকে একটি এক্সপোর্ট লাইন যোগ করতে হবে । এখানে গুরুত্বপূর্ণ বিষয় হলো সমান চিহ্নের (equals sign) চারপাশে কোনো স্পেস না রাখা, অন্যথায় ব্যাশ (Bash) এটিকে ভুলভাবে ব্যাখ্যা করবে। একটি সঠিক উদাহরণ হবে:

LD_LIBRARY_PATH=/home/osboxes/mukul রপ্তানি করুন

এক্ষেত্রে, আমরা সিস্টেমকে বলছি যে শেয়ার্ড লাইব্রেরি খোঁজার সময়, এটি যেন স্ট্যান্ডার্ড ডিরেক্টরিগুলোর আগে /home/osboxes/mukul ডিরেক্টরিটিকে বিবেচনা করে । আপনি এটিকে আপনার কাস্টম .so ফাইল বা যে লাইব্রেরিগুলো ব্যবহার করতে চান, সেগুলোর পাথ দিয়ে প্রতিস্থাপন করতে পারেন।

পরিবর্তনগুলি সংরক্ষণ করে এডিটর থেকে বেরিয়ে আসার পর, বর্তমান সেশনে নতুন এনভায়রনমেন্ট ভেরিয়েবলটি কার্যকর করার জন্য আপনাকে শেল কনফিগারেশনটি পুনরায় লোড করতে হবে। এটি সাধারণত নিম্নোক্তভাবে করা হয়:

উত্স ~ / .bashrc

যদি আপনি সবকিছু সঠিকভাবে প্রয়োগ করা হয়েছে কিনা তা পরীক্ষা করতে চান, তাহলে কেবল কমান্ডটি ব্যবহার করুন echo ভেরিয়েবল সম্পর্কে। এটি আপনাকে LD_LIBRARY_PATH-এ বর্তমানে যে পাথগুলি রয়েছে তা দেখাবে:

প্রতিধ্বনি $LD_LIBRARY_PATH

যদি আউটপুট লাইনে আপনার যোগ করা ডিরেক্টরিটি থাকে, তাহলে এর অর্থ হল কনফিগারেশনটি সঠিকভাবে লোড হয়েছে এবং ডায়নামিক লোডার এখন প্রোগ্রাম চালু করার সময় সেই পথটি বিবেচনা করবে।

কোনও কিছু না ভেঙে কীভাবে অতিরিক্ত রুট যোগ করবেন

অনেক সময়, আপনি LD_LIBRARY_PATH-এর বিষয়বস্তু সম্পূর্ণরূপে প্রতিস্থাপন করতে চান না , বরং বিদ্যমান পাথগুলো অপরিবর্তিত রেখে আরেকটি পাথ যোগ করতে চান। এটি গুরুত্বপূর্ণ, বিশেষ করে যদি অন্যান্য লাইব্রেরি আগে থেকেই কনফিগার করা থাকে এবং আপনি অন্য অ্যাপ্লিকেশনগুলোর সাথে নির্ভরতা ভাঙতে না চান।

"চেইন" রুট করার জন্য, সাধারণত রপ্তানির একটি রূপ ব্যবহার করা হয় যা পূর্ববর্তী ভেরিয়েবলের আগে একটি নতুন ডিরেক্টরি যোগ করুনউদাহরণস্বরূপ, যদি আপনি যোগ করতে চান /home/osboxes/sample যা ইতিমধ্যেই সংজ্ঞায়িত করা হয়েছে, আপনি আপনার লেখায় এরকম কিছু লিখতে পারেন .bashrc:

LD_LIBRARY_PATH=/home/osboxes/sample:${LD_LIBRARY_PATH} এক্সপোর্ট করুন

ক্রমটি গুরুত্বপূর্ণ, কারণ ডাইনামিক লোডার প্রথমে /home/osboxes/sample-এ এবং তারপর অন্যান্য ডিরেক্টরিগুলোতে অনুসন্ধান করবে যেখানে ভেরিয়েবলটি আগে থেকেই বিদ্যমান। এর ফলে আপনি বাকি কনফিগারেশন অপরিবর্তিত রেখে শুধুমাত্র নির্দিষ্ট কিছু পরীক্ষার জন্য একটি প্রায়োরিটি লাইব্রেরি অন্তর্ভুক্ত করতে পারেন।

ফাইলটি পরিবর্তন করার পর, আবার মনে রাখবেন "source" কমান্ডটি কার্যকর করুন। উপর ~/.bashrc বর্তমান টার্মিনালে পরিবর্তনগুলি প্রয়োগ করতে, এবং আবার পরীক্ষা করুন echo $LD_LIBRARY_PATH নতুন রুটটি তালিকার শীর্ষে প্রদর্শিত হবে।

এটা সুপারিশকৃত LD_LIBRARY_PATH-তে ধ্রুবক পরিবর্তন এড়িয়ে চলুনপ্রতিটি খারাপভাবে সম্পাদিত পরিবর্তন এমন প্রোগ্রামগুলিকে প্রভাবিত করতে পারে যা আপনি কল্পনাও করতে পারবেন না। সিনট্যাক্সের সাথে "যোগ করুন" প্যাটার্নটি ব্যবহার করুন। ${LD_LIBRARY_PATH} এটি ধারাবাহিকতা বজায় রাখতে সাহায্য করে, তবে এটি অতিরিক্ত ব্যবহার না করাই ভালো।

লাইব্রেরি অনুসন্ধান কীভাবে কাজ করে এবং কেন এটি বিপজ্জনক হতে পারে

LD_LIBRARY_PATH এর পিছনে ডায়নামিক লোডারের একটি খুব নির্দিষ্ট আচরণ রয়েছে: অনুসন্ধানের অগ্রাধিকারএই ভেরিয়েবলে আপনি যে পাথগুলি রেখেছেন সেগুলি আপনার সিস্টেমে প্রি-কম্পাইল করা পাথ এবং স্ট্যান্ডার্ড ডিরেক্টরিগুলির আগে প্রক্রিয়া করা হয়, যেমন /lib, /usr/lib o /usr/lib64.

সমস্যাটি তখন দেখা দেয় যখন এই অতিরিক্ত ডিরেক্টরিগুলোতে সিস্টেম লাইব্রেরির মতো একই নামের কোনো লাইব্রেরি থাকে , কিন্তু সেটির সংস্করণটি ভিন্ন বা বেমানান হয়। ডাইনামিক লোডার কোনো দ্বিধা ছাড়াই LD_LIBRARY_PATH-এ প্রথম যে লাইব্রেরিটি খুঁজে পায়, সেটিই নির্বাচন করে নেয়, এমনকি যদি অ্যাপ্লিকেশনটি মূলত একটি ভিন্ন সংস্করণের সাথে লিঙ্ক করা হয়ে থাকে।

এই পরিস্থিতি বেশ কয়েক ধরনের সংঘাতের পথ খুলে দেয়, যার মধ্যে একটি গুরুতর নিরাপত্তাজনিত সংঘাতও রয়েছে । যদি কোনো বিদ্বেষী ব্যবহারকারী কোনোভাবে আপনাকে বিকৃত LD_LIBRARY_PATH ব্যবহার করে কোনো প্রোগ্রাম চালাতে বাধ্য করে, তাহলে একটি ক্ষতিকর লাইব্রেরি গোপনে ঢুকে বৈধ সংস্করণটিকে প্রতিস্থাপন করে অনাকাঙ্ক্ষিত কোড কার্যকর করার সম্ভাবনা থাকে।

এই কারণে, setuid বা setgid বাইনারিগুলো সাধারণত LD_LIBRARY_PATH-কে পুরোপুরি উপেক্ষা করে। যেহেতু এগুলো উচ্চতর বিশেষাধিকার নিয়ে চলে, তাই ব্যবহারকারীর পরিবেশ থেকে যথেচ্ছ পাথ গ্রহণ করা একটি বিরাট ঝুঁকি হবে; এইসব ক্ষেত্রে সিস্টেমটি কেবল সেই ভেরিয়েবলটি বাতিল করে দেয়।

নিরাপত্তার বাইরেও, একটি দিক আছে কর্মক্ষমতা এবং দক্ষতা মনে রাখা উচিত কিছু। LD_LIBRARY_PATH-এ আপনার যোগ করা প্রতিটি ডিরেক্টরি লোডারকে সেই পথে লাইব্রেরি খোলার চেষ্টা করতে বাধ্য করে, এমনকি যদি সেগুলি আসলে সেখানে নাও থাকে। এর ফলে অনেক ব্যর্থ কল আসে open()যা "ENOENT (কোনও ফাইল বা ডিরেক্টরি নেই)" ফেরত দেয় এবং অ্যাপ্লিকেশনগুলির স্টার্টআপ ধীর করে দেয়।

আপনি যত বেশি পাথ যোগ করবেন, বিশেষ করে যদি সেগুলি রিমোট ডিরেক্টরি (NFS) হয় , আপনার প্রোগ্রামগুলির স্টার্টআপ টাইম তত বেশি বাড়বে এবং ফাইল সিস্টেমের উপর চাপও তত বাড়বে। শত শত ব্যবহারকারী থাকা বড় পরিবেশে, LD_LIBRARY_PATH-এর অতিরিক্ত ব্যবহার একটি অপ্রত্যাশিত প্রতিবন্ধকতা হয়ে উঠতে পারে।

সাধারণ সমস্যা: অসঙ্গতি এবং লুকানো নির্ভরতা

আরেকটি খুব সাধারণ পার্শ্বপ্রতিক্রিয়া হলো বাইনারি এবং লাইব্রেরির মধ্যে অসামঞ্জস্যতা । LD_LIBRARY_PATH একটি প্রোগ্রামকে তার সাথে লিঙ্ক করা লাইব্রেরির সংস্করণ থেকে ভিন্ন কোনো সংস্করণ লোড করতে বাধ্য করতে পারে, এবং এগুলি ABI বা আচরণগত স্তরে সবসময় ১০০% সামঞ্জস্যপূর্ণ হয় না।

সবচেয়ে ভালো ক্ষেত্রে, যদি কোনো স্পষ্ট অসামঞ্জস্য থাকে, তাহলে অ্যাপ্লিকেশনটি চালু হতে ব্যর্থ হবে বা দ্রুত ক্র্যাশ করবে, যা সমস্যার সুস্পষ্ট চিহ্ন রেখে যাবে। কিন্তু আসল বিপদ হলো যখন লাইব্রেরিটি ‘মোটামুটি কাজ করে’, কিন্তু তারপর ভুল ফলাফল দিতে শুরু করে বা সামান্য ভিন্নভাবে আচরণ করে, যা এতটাই সূক্ষ্ম যে ডিবাগ করা কঠিন হয়ে পড়ে।

এর একটি বিশেষভাবে সমস্যাজনক ব্যবহার হলো ব্যবহারকারীর প্রোফাইলে অথবা, আরও খারাপভাবে, সিস্টেম প্রোফাইলে LD_LIBRARY_PATH-কে বিশ্বব্যাপী (globally ) নির্ধারণ করা । যখন এমনটা ঘটে, তখন সেই সেশনে চলমান সমস্ত অ্যাপ্লিকেশন সেই কনফিগারেশনের সংস্পর্শে আসে, এমনকি সেই অ্যাপ্লিকেশনগুলোও যেগুলো এই অতিরিক্ত পাথগুলোর সাথে কাজ করার জন্য কখনও ডিজাইন করা হয়নি।

যখন সেই গ্লোবাল রুটগুলো পরিবর্তিত হয় বা বিলুপ্ত হয়ে যায়, তখন অনেক বাইনারি হঠাৎ কাজ করা বন্ধ করে দিতে পারে , কারণ কারও অজান্তেই তারা তাদের লাইব্রেরিগুলো খুঁজে পাওয়ার জন্য LD_LIBRARY_PATH-এর সেই "প্যাচ"-টির উপর নির্ভর করতে শুরু করেছিল।

এ কারণেই অনেক পেশাগত পরিবেশে ভেরিয়েবলকে শুধুমাত্র এককালীন পরীক্ষার সরঞ্জাম বা জরুরী সমাধান হিসেবে ব্যবহারের উপর এত বেশি জোর দেওয়া হয় , কখনোই দীর্ঘমেয়াদী স্থিতিশীল কনফিগারেশন ব্যবস্থা হিসেবে নয়।

কোন লাইব্রেরিগুলি আসলে ব্যবহৃত হচ্ছে তা কীভাবে দেখবেন

আপনার পরিবর্তনগুলি LD_LIBRARY_PATH-কে কীভাবে প্রভাবিত করে তা সম্পূর্ণরূপে বুঝতে, এটি জানা গুরুত্বপূর্ণ কোন লাইব্রেরিগুলি প্রতিটি এক্সিকিউটেবল ব্যবহার করেএখানে কমান্ডগুলি যেমন lddযা গতিশীল লিঙ্কিংয়ের একটি মোটামুটি স্পষ্ট ধারণা দেয়।

`ldd` কমান্ডটি একটি নির্দিষ্ট বাইনারির জন্য দেখায় যে, এটির কোন কোন ডাইনামিক লাইব্রেরি প্রয়োজন এবং কোন পাথ থেকে সেগুলো লোড করা হচ্ছে। উদাহরণস্বরূপ, যদি আপনি চালান:

ldd /usr/bin/ফাইল

আপনি এই ধরণের লাইনের একটি তালিকা দেখতে পাবেন libmagic.so.1 => /usr/lib64/libmagic.so.1, রেজোলিউশনের সাথে linux-vdso.so.1, libc.so.6 এবং ডাইনামিক চার্জার নিজেই। এই তথ্য আপনাকে একটি স্ট্যাটিক ছবি এক্সিকিউটেবলের প্রধান নির্ভরতাগুলির মধ্যে।

তবে, এমন কিছু ঘটনা আছে যেখানে একটি ভাগ করা লাইব্রেরি রানটাইমে অন্যান্য লাইব্রেরি লোড করে (উদাহরণস্বরূপ, এর মাধ্যমে dlopen()), এবং এগুলো ldd এর আউটপুটে প্রতিফলিত হয় না। আরও সম্পূর্ণ চিত্র দেখার জন্য, কোন .so ফাইলগুলি আসলে একটি চলমান প্রক্রিয়ার ঠিকানা স্থানে ম্যাপ করা হয়েছে তা পরীক্ষা করা প্রয়োজন।

কিছু সোলারিস-সদৃশ সিস্টেমে একটি `pldd` কমান্ড আছে, যা কোনো প্রসেসের PID-এর উপর ভিত্তি করে তার দ্বারা লোড হওয়া ডাইনামিক লাইব্রেরিগুলোর তালিকা দেখায়। ব্যাশের মতো কোনো প্রোগ্রামে এটি ব্যবহার করলে দেখা যায়, `ldd` দ্বারা তালিকাভুক্ত লাইব্রেরিগুলোর সাথে কীভাবে ক্যারেক্টার কনভার্সন মডিউল বা ইউজার ও গ্রুপ রেজোলিউশনের জন্য NSS মডিউলের মতো অন্যান্য লাইব্রেরিও যুক্ত হয় ।

বিশুদ্ধ লিনাক্সে, pldd সবসময় একটি স্ট্যান্ডার্ড বাইনারি হিসেবে পাওয়া যায় না, কিন্তু পার্ল বা অন্যান্য সরঞ্জামগুলিতে স্ক্রিপ্ট রয়েছে যেগুলো থেকে তথ্য বের করে /proc/<PID>/mapsএকই রকম প্রভাব অর্জন করা। এইভাবে আপনি পরীক্ষা করতে পারবেন যে আপনার LD_LIBRARY_PATH সেটিংসের কারণে অপ্রত্যাশিত লাইব্রেরি লোড হয়েছে কিনা।

LD_LIBRARY_PATH এর উপর নির্ভর না করার আরও পরিষ্কার উপায়

যখন আপনি LD_LIBRARY_PATH নিয়ে বিভিন্ন বিকল্প ব্যবস্থা গ্রহণ করতে শুরু করেন, তখন সাধারণ পরামর্শটি খুবই সহজ: এটি যতটা সম্ভব কম ব্যবহার করুন । আপনার যোগ করা প্রতিটি পাথই ত্রুটি, ভার্সন দ্বন্দ্ব এবং পারফরম্যান্স সমস্যার একটি সম্ভাব্য উৎস, তাই আরও নির্ভরযোগ্য বিকল্পগুলো বিবেচনা করা উচিত।

আপনি যদি আপনার অ্যাপ্লিকেশনগুলো কম্পাইল করেন (উদাহরণস্বরূপ, Linux From Scratch অনুসরণ করে ), তাহলে আপনি লিঙ্কারের `-rpath` অপশনটি ব্যবহার করতে পারেন । এই অপশনটি আপনাকে এক্সিকিউটেবলের উপর নির্ভরশীল লাইব্রেরিগুলোর পাথ সরাসরি এক্সিকিউটেবলের মধ্যে যুক্ত করার সুযোগ দেয়, ফলে বাইনারিটি গ্লোবাল এনভায়রনমেন্ট ভেরিয়েবল পরিবর্তন না করেই লাইব্রেরিগুলোকে কোথায় খুঁজে পাবে তা জানতে পারে।

একটি সাধারণ উদাহরণ এরকম কিছু হবে:

cc -o myprog obj1.o … objn.o -Wl, -rpath=/path/to/lib -L/path/to/lib -lmylib

এর সাথে, লিঙ্কার যোগ করে এক্সিকিউটেবলের রানপথে /path/to/libযদি আপনার একাধিক রুটের প্রয়োজন হয়, তাহলে পরিবেশ পরিবর্তনশীল ব্যবহার করা বেশ সুবিধাজনক। LD_RUN_PATHযা লিঙ্কারও বোঝে এবং আপনি কোলন দ্বারা পৃথক করা ডিরেক্টরিগুলির একটি তালিকা দিয়ে পূরণ করতে পারেন।

আপনি করতে পারেন, উদাহরণস্বরূপ:

LD_RUN_PATH=/path/to/lib1:/path/to/lib2:/path/to/lib3 রপ্তানি করুন
cc -o myprog obj1.o … objn.o -L/path/to/lib1 -lmylib1 -L/path/to/lib2 -lmylib2

কম্পাইল করার পরে, আপনি পরীক্ষা করতে পারেন ldd যে বাইনারি এটি তার সমস্ত লাইব্রেরি সঠিকভাবে সমাধান করে LD_LIBRARY_PATH এর উপর নির্ভর না করে। যদি কোন "পাওয়া যায়নি" ত্রুটি দেখা দেয়, তাহলে আপনাকে Makefile এবং LD_RUN_PATH কনফিগারেশন পরীক্ষা করতে হবে।

যখন আপনি পুনরায় কম্পাইল করতে পারবেন না, তখন এক্সিকিউটেবলে আগে থেকেই এমবেড করা রানপাথ পরিবর্তন করার জন্য আপনি chrpath-এর মতো টুল ব্যবহার করতে পারেন । এই কৌশলের কিছু সীমাবদ্ধতা রয়েছে: আপনি কেবল বিদ্যমান স্ট্রিংটি ওভাররাইট করতে পারবেন, এটিকে প্রসারিত করতে পারবেন না, এবং যদি বাইনারিটির কোনো নির্দিষ্ট রানপাথ না থাকে, তবে পরিবর্তন করার মতো কিছুই থাকে না।

র‍্যাপার স্ক্রিপ্ট ব্যবহার করা এবং কমান্ড লাইন থেকে নির্দিষ্ট সমন্বয় করা

যদি -rpath বা chrpath দিয়ে লিঙ্ক করা সম্ভব না হয়, তাহলেও আপনি র‍্যাপার স্ক্রিপ্ট ব্যবহার করতে পারেন যা শুধুমাত্র একটি নির্দিষ্ট অ্যাপ্লিকেশনের জন্য LD_LIBRARY_PATH পরিবর্তন করে এবং অন্য কিছুর জন্য করে না। ব্যবহারকারীর প্রোফাইলে হস্তক্ষেপ করার চেয়ে এটি অনেক কম হস্তক্ষেপমূলক একটি পদ্ধতি।

শেলের মধ্যে একটি সাধারণ মোড়ক দেখতে এরকম কিছু হবে:

#! / বিন / SH
LD_LIBRARY_PATH=/path/to/lib1:/path/to/lib2:/path/to/lib3
LD_LIBRARY_PATH রপ্তানি করুন
এক্সিকিউট /পাথ/টু/বিন/মাইপ্রোগ «$@»

এই পদ্ধতিতে, এনভায়রনমেন্ট ভেরিয়েবলটি শুধুমাত্র myprog এবং এর দ্বারা চালু হওয়া যেকোনো চাইল্ড প্রসেসের জন্য "দূষিত" হয়, কিন্তু আপনার সেশনে চালানো অন্য কোনো কমান্ডের জন্য নয়। যখন কোনো নির্দিষ্ট অ্যাপ্লিকেশনের জন্য আপনাকে বিশেষ লাইব্রেরি সংস্করণ নিয়ে কাজ করতে বাধ্য করা হয়, তখন এটি একটি সম্পূর্ণ গ্রহণযোগ্য সমাধান।

দ্রুত পরীক্ষার জন্য আরেকটি খুব কার্যকরী উপায় হলো `env` কমান্ড ব্যবহার করে শুধুমাত্র একটি এক্সিকিউশনের জন্য `LD_LIBRARY_PATH` নির্ধারণ করা। উদাহরণস্বরূপ:

env LD_LIBRARY_PATH=/path/to/lib1:/path/to/lib2 ./myprog

এইভাবে চলকটি প্রয়োগ করা হয় শুধুমাত্র সেই আহ্বানের জন্য de myprogএবং যখন এটি সম্পন্ন হবে, তখন আপনার শেলটি অক্ষত থাকবে, কোনও অদ্ভুত পথের চিহ্ন থাকবে না যা আপনার পরবর্তী কমান্ডটি প্রভাবিত করতে পারে।

যা এড়িয়ে চলার জন্য জোরালোভাবে সুপারিশ করা হচ্ছে তা হল:

LD_LIBRARY_PATH=/path/to/lib1:/path/to/lib2 রপ্তানি করুন
./মাইপ্রোগ

সেই প্যাটার্নটি LD_LIBRARY_PATH ছেড়ে যায় পরবর্তী সকল অর্ডারের জন্য সংজ্ঞায়িত যেটা তুমি ঐ টার্মিনাল থেকে চালু করো, যার ফলে এমন পার্শ্বপ্রতিক্রিয়া হতে পারে যা পরবর্তীতে ট্র্যাক করা খুব কঠিন। বিচ্ছিন্ন পরীক্ষার জন্য, কল করুন env এটা অনেক বেশি পরিষ্কার।

ভালো অভ্যাস এবং এড়িয়ে চলার জন্য সাধারণ ভুল

একটি বহুল গৃহীত সুবর্ণ সুপারিশ হল লগইন প্রোফাইলে কখনও LD_LIBRARY_PATH সংজ্ঞায়িত করবেন নাব্যবহারকারী বা সিস্টেম ফাইল নয়। অন্য কথায়, এটিকে ফাইলগুলিতে যুক্ত করা এড়িয়ে চলুন ~/.bash_profile, ~/.profile, /etc/profile অথবা অনুরুপ.

যখন এই ধরনের কোনো সংবেদনশীল ভেরিয়েবল বিশ্বব্যাপী সেট করা হয়, তখন সেই ব্যবহারকারীর দ্বারা চালু করা সমস্ত অ্যাপ্লিকেশন সেই অতিরিক্ত পাথগুলো ব্যবহার করবে, এমনকি যেগুলো সিস্টেম লাইব্রেরির সাথে কাজ করার জন্য নিখুঁতভাবে কনফিগার করা আছে সেগুলোও। এর পরিধি নির্দিষ্ট স্ক্রিপ্ট বা এককালীন এক্সিকিউশনের মধ্যে সীমাবদ্ধ রাখা সর্বদা অনেক বেশি নিরাপদ একটি পন্থা।

থার্ড-পার্টি ইনস্টলারদের ব্যাপারেও সতর্ক থাকা বুদ্ধিমানের কাজ , যারা ইনস্টলেশনের সময় আপনাকে আপনার প্রোফাইলে LD_LIBRARY_PATH যোগ করতে বলে অথবা যারা আপনার হয়ে বিশ্বব্যাপী এটি করে দেয়। বেশিরভাগ ক্ষেত্রে, এটি পরিষেবা প্রদানকারীর জন্য একটি সহজ শর্টকাট, কিন্তু এটি মধ্যম মেয়াদে আপনার পরিবেশে সমস্যা সৃষ্টি করবে।

যখনই সম্ভব, আরেকটু বেশি চেষ্টা করা এবং পরিচ্ছন্ন বিকল্প খোঁজা উচিত : যেমন এক্সিকিউটেবলের রানপাথ পরিবর্তন করা, লাইব্রেরিগুলোকে একটি স্ট্যান্ডার্ড ডিরেক্টরিতে ইনস্টল করা, আধুনিক প্যাকেজিং পদ্ধতি ব্যবহার করা, অথবা সাধারণ এনভায়রনমেন্টে হাত না দিয়ে অ্যাপটিকে একটি স্ক্রিপ্ট র‍্যাপার দিয়ে মুড়ে দেওয়া।

যদি আপনাকে ভ্যারিয়েবল ব্যবহার করতেই হয়, তবে পাথগুলো যথাসম্ভব সংক্ষিপ্ত ও সুনির্দিষ্ট রাখার চেষ্টা করুন , ডিরেক্টরির সংখ্যা কমিয়ে আনুন এবং একান্ত প্রয়োজন না হলে রিমোট ফাইল সিস্টেমে অবস্থিত পাথ সর্বতোভাবে পরিহার করুন।

এই সবকিছুর পরিপ্রেক্ষিতে, LD_LIBRARY_PATH একটি শক্তিশালী কিন্তু সংবেদনশীল টুল হিসেবেই রয়ে গেছে : এটি নতুন লাইব্রেরি সংস্করণ পরীক্ষা করতে, পুরোনো .so ফাইল স্থানান্তর করতে, বা বড় অ্যাপ্লিকেশনের জন্য স্বয়ংসম্পূর্ণ পরিবেশ তৈরি করতে খুবই উপযোগী, কিন্তু এর নির্বিচার ব্যবহার নিরাপত্তা ঝুঁকি, পারফরম্যান্সের সমস্যা এবং এমন অসঙ্গতি তৈরি করে যা ডিবাগ করা কঠিন। ডাইনামিক লোডার কীভাবে কাজ করে তা বোঝা, -rpath, LD_RUN_PATH বা র‍্যাপার স্ক্রিপ্টের মতো বিকল্পের উপর নির্ভর করা এবং এই ভেরিয়েবলটিকে খুব নির্দিষ্ট প্রেক্ষাপটে সীমাবদ্ধ রাখাই হলো LD_LIBRARY_PATH-কে আপনার সিস্টেমের জন্য একটি ফাঁদে পরিণত না করে এর সুবিধা নেওয়ার সর্বোত্তম উপায়।