লিনাক্সে 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 ব্যবহার করা হয় a সীমিত এবং সময়নিষ্ঠ, একটি নির্দিষ্ট অ্যাপ্লিকেশন বা পরীক্ষার পরিবেশের সাথে সম্পর্কিত, একটি বিশ্বব্যাপী পরিবর্তনশীল হিসাবে নয় যা ব্যবহারকারীর চালিত সবকিছু বা সমগ্র সিস্টেমকে প্রভাবিত করে।

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

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

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

ন্যানো ~ /। bashrc

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

LD_LIBRARY_PATH=/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 এর অত্যধিক ব্যবহার একটি অপ্রত্যাশিত বাধা হয়ে দাঁড়াতে পারে।

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

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

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

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

যখন ঐ বৈশ্বিক রুটগুলি পরিবর্তিত হয় বা অস্তিত্ব বন্ধ করে দেয়, তখন অনেক বাইনারি একদিন থেকে পরের দিন কাজ বন্ধ রাখুন কারণ, কেউ টের না পেয়ে, তারা তাদের লাইব্রেরি খুঁজে পেতে 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`ldd` একটি প্রক্রিয়া দ্বারা লোড করা গতিশীল লাইব্রেরিগুলিকে তার PID এর উপর ভিত্তি করে তালিকাভুক্ত করে। Bash এর মতো প্রোগ্রামে ব্যবহার করা হলে, আপনি দেখতে পাবেন কিভাবে অন্যান্য লাইব্রেরি, যেমন অক্ষর রূপান্তর মডিউল, `ldd` দ্বারা তালিকাভুক্ত লাইব্রেরিগুলিতে যোগ করা হয়েছে। এনএসএস মডিউল ব্যবহারকারী এবং গোষ্ঠী রেজোলিউশনের জন্য।

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

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

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

যদি আপনি আপনার অ্যাপ্লিকেশনগুলি সংকলন করেন (উদাহরণস্বরূপ, নিম্নলিখিতগুলি করে) স্ক্র্যাচ থেকে লিনাক্সআপনার ব্যবহারের সুযোগ আছে লিঙ্কারের -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 রপ্তানি করুন
এক্সিকিউট /পাথ/টু/বিন/মাইপ্রোগ «$@»

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

দ্রুত পরীক্ষার জন্য আরেকটি খুব কার্যকর বিকল্প হল কমান্ডটি ব্যবহার করা প্রায় শুধুমাত্র একটি একক এক্সিকিউশনের জন্য 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 কে আপনার সিস্টেমের জন্য একটি ফাঁদে পরিণত না করে এর সুবিধা নেওয়ার সর্বোত্তম উপায়।