आश्रित पुस्तकालयों के साथ मैक ओएस एक्स कैसे वितरित करें?

मेरे पास एक प्रोग्राम है (विशेष रूप से SO DevDays Countdown app challenge के लिए मेरी प्रविष्टि) जो कई गतिशील पुस्तकालयों, अर्थात् libSDL, libSDL_ttf, और अन्य पर निर्भर करता है। मेरे पास मैकपॉर्ट्स के माध्यम से /opt/local/lib के तहत इन पुस्तकालयों को स्थापित किया गया है, और कई लोगों ने इन्हें स्थापित नहीं किया होगा (और कुछ ने उन्हें स्थापित किया हो सकता है, लेकिन उस स्थान पर नहीं)।आश्रित पुस्तकालयों के साथ मैक ओएस एक्स कैसे वितरित करें?

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

स्रोत

2009-09-27 Adam Rosenfield

जैसा कि आपने बताया है कि आप एक्सकोड का उपयोग नहीं कर रहे हैं, इसलिए यह थोड़ा मुश्किल है।

स्विच Xcode करने के लिए: यहाँ वरीयता के अपने आदेश में विकल्प हैं। ढांचे का प्रयोग करें। एसडीएल पुस्तकालय पहले से ही ढांचे के रूप में उपलब्ध हैं, और मैंने ऐप बंडल के अंदर libsdl.framework के साथ कुछ वाणिज्यिक गेम देखे हैं।
ढांचे का उपयोग करें, लेकिन अपनी मेकफ़ाइल रखें। अपने एसडीएल पुस्तकालयों के फ्रेमवर्क संस्करणों को डाउनलोड करें (या स्वयं को बनाएं), और उनके साथ -फ्रेमवर्क लिंकर ध्वज के साथ लिंक करें। अपने ऐप के साथ ढांचे को वितरित करें या नहीं, और अपने उपयोगकर्ताओं को उन्हें ~/लाइब्रेरी/फ्रेमवर्क या/लाइब्रेरी/फ्रेमवर्क में रखने के लिए कहें। मैं इसके लिए एक इंस्टॉलर से परेशान नहीं होगा।
स्थिरता एसडीएल के खिलाफ कड़ी। Makefile में, आप स्थिर पुस्तकालयों के पथ सूची के बजाय -l ध्वज का उपयोग करें, जैसे होगा, तो आप "ld, ऐसा /opt/local/lib/libsdl.a" चलाते हैं। साझा पुस्तकालयों पर स्थिर पसंद करने के लिए मुझे कोई तरीका नहीं है, और मुझे विश्वास है, मैंने देखा है।

तो कोड पुनः उपयोग के लिए बहुत

स्रोत

2009-09-27 04:10:08

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

4. उपरोक्त विकल्प 2 का उपयोग करके, अपने .app बंडल (.dmg फ़ाइल) के अंदर ढांचे को रखें और install_name_tool के साथ पथ निष्पादन योग्य आवश्यकताओं को बदलें। यहां कुछ उदाहरण दिए गए हैं कि install_name_tool का उपयोग कैसे किया जाता है: http://qt-project.org/doc/qt-4.8/deployment-mac.html। डायट्रिच, क्या आप इसे अपने उत्तर में शामिल कर सकते हैं? –

@ मिलानबाबुस्कोव: ऐसा लगता है कि यह पहले से ही नीचे दिए गए उत्तर में शामिल है। मुझे जानकारी डुप्लिकेट करने की कोई आवश्यकता नहीं है। –

पुस्तकालयों को स्थैतिक रूप से लिंक करें।

स्रोत

2009-09-27 03:17:06 wildwobby

। –

स्थैतिक रूप से जुड़े पुस्तकालयों को "कोड पुन: उपयोग" के रूप में गिनती है, क्योंकि लाइब्रेरी कोड को अभी भी केवल एक बार लिखा/परीक्षण/डीबग किया जाना चाहिए, इससे कोई फ़र्क नहीं पड़ता कि इसका उपयोग कितने एप्लिकेशन समाप्त हो जाते हैं। हालांकि यह सच है कि संकलित कोड की कई प्रतियां उपयोगकर्ता की डिस्क पर समाप्त हो सकती हैं, यह उतनी बड़ी समस्या नहीं है जितनी कि अब यह होती थी कि हार्ड ड्राइव इतनी बड़ी होती है। –

इसका मूल दृष्टिकोण उन्हें .app बंडल में भेजना है। इसके बाद आप लिंकर को साझा करने के लिए साझा पुस्तकालयों के स्थान को उस स्थान को संशोधित करेंगे।

कदम हैं:

बनाएं एक नई प्रतिलिपि फ़ाइलों को आपके लक्ष्य के चरण का निर्माण कि .app बंडल के फ़्रेमवर्क निर्देशिका में प्रतियां उन फ़ाइलों।
निर्माण विन्यास "Runpath खोजें पथ" सेटिंग @executable_path/../Frameworks

शामिल करने के लिए संपादित करें आप इन परिवर्तनों के साथ अपने निष्पादन का निर्माण और फिर देखें, तो आप पाएँगे कि dylibs Foo.app/Contents/Framework निर्देशिका और चल रहा है में मौजूद otool -L Foo.app/Contents/MacOS/Foo उन dylibs के लिए @rpath द्वारा prefixed उपज और प्रविष्टि चाहिए।

इस Cocoabuilder post से:

सामान्य तौर पर, @loader_path, @executable_path अधिक पसंद के रूप में यह
एम्बेडेड, दोनों एक निष्पादन और एक बंडल में काम
प्लगइन, या उप-ढांचे के लिए व्यवस्थाएं की अनुमति देता है। केवल नकारात्मक पक्ष यह है कि @loader_path
को 10.4 या नए की आवश्यकता है। यदि आप 10.5 या नए पर हैं, @rpath
@loader_path से बेहतर है।

स्रोत

2009-09-27 03:40:46 nall

मैं एक्सकोड (नहीं .app बंडल) का उपयोग नहीं कर रहा हूं, बस सादा पुराना जीसीसी और बनाना। मैं ओएस एक्स 10.4 का भी उपयोग कर रहा हूं; http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html के अनुसार, runpath खोज पथ केवल 10.5 और ऊपर पर समर्थित हैं। –

मेरा मानना है कि @executable_path 10.4 पर भी काम करेगा (@loader_path और @rpath नहीं होगा)। आप भी इस पढ़ सकता है: आप Xcode उपयोग नहीं कर रहे हैं http://blog.onesadcookie.com/2008/01/installname-magic.html – nall

, आपका सर्वश्रेष्ठ दांव Autotools और दोस्तों के उपयोग करने के लिए हो सकता है। –

आश्रित पुस्तकालयों के साथ मैक ओएस एक्स कैसे वितरित करें?

उत्तर

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