2010-01-08 28 views
20

लिनक्स वितरण में बाइनरी बनाने और इसे उसी आर्किटेक्चर के साथ किसी अन्य वितरण पर चलाने का कोई तरीका? या मुझे संकलन और विभिन्न वितरणों पर इसे बनाना चाहिए?लिनक्स वितरण बाइनरी संगतता

क्या बाइनरी फाइलों के लिए रेडहाट, डेबियन आधारित वितरण के बीच कोई संगतता है? (मैं फेडोरा पर अपनी उबंटू बाइनरी फ़ाइल का उपयोग करना चाहता हूं!)

+7

इतने सारे चर इतना आसान जवाब है कर रहे हैं: यह निर्भर करता है। पुस्तकालय इस अंतर के लिए बहुत अधिक बनाते हैं। – jldupont

उत्तर

17

दर्ज लिनक्स स्टैंडर्ड बेस व्यक्ति लिनक्स वितरण के बीच मतभेदों को कम करने के लिए। देखें

+2

[लिनक्स ऐप चेकर] (http://ldn.linuxfoundation.org/lsb/check-your-app) टूल ** एलएसबी ** पर आधारित है और रेडहाट, डेबियन, एसयूएसई जैसे कई लिनक्स वितरणों के साथ संगतता के लिए आपके आवेदन की जांच कर सकता है और दूसरे। – aponomarenko

+0

@aponomarenko, टूटी हुई लिंक। –

+2

@techtonik, वैकल्पिक लिंक http://www.linuxfoundation.org/collaborate/workgroups/lsb/all-about-linux-application-checker – aponomarenko

2

आम तौर पर लिनक्स वितरण में बाइनरी का उपयोग करना ठीक है जब तक आपके पास पुस्तकालयों का एक ही सेट उपलब्ध न हो। बाइनरी द्वारा कौन सी लाइब्रेरी की आवश्यकता होती है, यह देखने के लिए आप 'ldd' का उपयोग कर सकते हैं। libc निश्चित रूप से शामिल वितरण में एक ही संस्करण होना चाहिए।

3

यह काम करता है। लेकिन यह आपके द्वारा उपयोग की जाने वाली साझा लाइब्रेरीज़ के संस्करण पर भी निर्भर करता है, जिसमें libc, libstdC++ शामिल हैं जो संकलित को कंपाइलर संस्करण द्वारा मजबूर कर दिया गया है जो डिस्ट्रो से distro तक भिन्न हो सकता है।

2

आप पोर्टेबिलिटी के लिए अपने एक्जिक्यूटिव्स को स्थिर रूप से लिंक कर सकते हैं।

+3

नहीं वह नहीं कर सकता। लोगों को यह कब मिलता है कि स्थैतिक रूप से जुड़े निष्पादन योग्य अब समर्थित नहीं हैं। एलएसबी पढ़ें। – Lothar

10

आपकी बाइनरी को स्थिर रूप से जोड़ने से उन्हें कम पोर्टेबल बनाता है क्योंकि कुछ पुस्तकालय तब उस मशीन के लिए सही तरीके से काम नहीं करेंगे (प्रमाणीकरण विधियों को अलग करना आदि)।

यदि आप किसी भी "असामान्य" पुस्तकालयों को स्थिर रूप से लिंक करते हैं और समर्थित डिस्ट्रोज़ का सेट न्यूनतम पर रखते हैं, तो आपको ठीक होना चाहिए।

स्थिर सी पुस्तकालय (या पूरे बाइनरी) लिंक न करें, कि मुसीबत :) क्या (जैसे) गूगल क्रोम के साथ क्या पर

देखो के लिए एक नुस्खा है।

+0

अच्छा, कार्यक्रम के आधार पर यह बिल्कुल सही नहीं है। मैंने कई बार स्टेटिक लिंक्ड बाइनरी सफलतापूर्वक वितरित की है। एक कंपाइलर के बारे में सोचें: यह एक फाइल पढ़ता है और एक फाइल लिखता है। आपको क्या लगता है कि यह स्थिर रूप से जुड़ा नहीं जा सकता है? –

+0

आप अपनी बाइनरी को स्थिर रूप से लिंक कर सकते हैं, लेकिन फिर वे सी लाइब्रेरी के अपडेट से लाभ नहीं उठा सकते हैं, न ही अन्य परिवर्तनों के साथ संगत हो सकते हैं जो वितरण या अंतिम उपयोगकर्ता प्रशासक उदा। कस्टम एनएसएस पुस्तकालयों। – MarkR

6

आपका आवेदन किस भाषा में कोडित है? यदि यह पाइथन, (और कोई सी बाइंडिंग) या जावा या किसी अन्य वीएम आधारित भाषा जैसी भाषा में है, तो मुझे लगता है कि आप यह सुनिश्चित करने के लिए वीएम पर भरोसा कर सकते हैं कि आपका एप्लिकेशन विभिन्न लिनक्स वितरण पर काम करेगा।

इसके अलावा, Linux Standard Base है जिसका आप उल्लेख कर सकते हैं।

HTH, अमित

4

सबसे अच्छा तरीका है स्रोत कोड वितरित करने के लिए और यह आसान किसी भी उचित Linux वितरण पर स्रोत का निर्माण करने के बनाने के लिए है। यह द्विआधारी वितरण से बेहतर है क्योंकि साझा पुस्तकालयों के साथ बाइनरी को संगत बनाने के लिए पर्याप्त नहीं है। आपको यह सुनिश्चित करने की भी आवश्यकता है कि आप अपने प्रोग्राम को डिस्ट्रीब्यूशन निर्दिष्ट स्थानों और सम्मेलनों जैसे वेब ऐप्स कहां जाते हैं, या कैसे ई-मेल भेजा जाता है, या सेवाओं को कैसे शुरू किया जाता है, या डिफ़ॉल्ट काग़ज़ का आकार कैसे निर्धारित किया जाए, या असंख्य अन्य विवरणों का।

उदाहरण के लिए Debian Policy Manual एक दस्तावेज़ के लिए देखें, जिसमें वितरण की आवश्यकता होती है ताकि वितरण पर चल रहे अनुप्रयोगों के बीच संगतता सुनिश्चित हो सके। आपको इसे पढ़ने या दिल से सीखने की आवश्यकता नहीं है, लेकिन यह उन मुद्दों के दायरे को दिखाता है जो आपको यात्रा कर सकते हैं।

आपको यह सुनिश्चित करने के लिए संभवतः कई प्रमुख वितरणों के साथ मिलकर काम करना चाहिए कि आपका आवेदन उन सभी के साथ अच्छा काम करता है। यदि आप विनम्रतापूर्वक उनसे संपर्क करते हैं तो अधिकांश वितरण डेवलपर्स खुशी से मदद करेंगे। यदि आप भाग्यशाली हैं, तो आप अपने लिए द्विआधारी पैकेजिंग करने के लिए डिस्ट्रोज़ से स्वयंसेवकों को आकर्षित कर सकते हैं, और यह आपके आवेदन को पैकेज करने में आसान बनाने के लिए आपको स्रोत स्तर पर बदलने की आवश्यकता के बारे में प्रतिक्रिया देगा।

Linux Standard Base पहले से ही दूसरों द्वारा वर्णित इन चरों के लिए एक क्रॉस-वितरण समाधान करने का प्रयास करता है, लेकिन यह व्यापक नहीं है और अधिकांश वितरणों द्वारा पूरी तरह से समर्थित नहीं है। हालांकि, अधिकांश वितरण इसे एक समस्या मानते हैं यदि वे गलती से एलएसबी संगतता तोड़ते हैं।

0

एलएसबी निश्चित रूप से जांच करने लायक है। पुस्तकालयों के साथ काम करने का संबंध में हालांकि मैं सबसे यह उत्तर यहाँ अतः https://stackoverflow.com/questions/1209674/shipping-closed-source-application-for-linux/1242738#1242738 पर और rpath तंत्र http://www.eyrie.org/~eagle/notes/rpath.html

5

मुझे पता है यह एक बहुत पुरानी सवाल यह है की इस विस्तृत उपचार से संतुष्ट था, लेकिन यह खोज परिणामों और इस में उच्च ऊपर आता है उल्लेख नहीं किया गया है:

CDE is a tool to create portable Linux applications। यह उपकरण रन-टाइम पर विश्लेषण करके सभी आवश्यक फ़ाइलों (पुस्तकालयों सहित) को संकुल करता है। मैंने इसे कई बार कमांड लाइन टूल्स पर सफलतापूर्वक इस्तेमाल किया है, एक उदाहरण कस्टम वितरण चलाने वाले पुराने हार्डवेयर उपकरण पर चलने के लिए टीसीपीडम्प प्राप्त कर रहा है। सीडीई को स्रोत की आवश्यकता नहीं है, यह सिर्फ एक निष्पादन योग्य पैकेज है जिसे आप चलाने में सक्षम हैं।

एक बिंदु पर मुझे cde कमांड चलाने में त्रुटि हुई जो LD_ASSUME_KERNEL=2.4.1 के साथ कमांड को प्रीपेड करके तय किया गया था, यह हाल के संस्करणों में पिछले कुछ वर्षों से आवश्यक नहीं हो सकता है।

कोड GitHub पर भी है: https://github.com/pgbovine/CDE

संबंधित मुद्दे