Rust: ऐप्पल ऐप स्टोर बिटकोड का समर्थन करें

हम LLVM को गतिशील रूप से लोड करने के लिए rustc को बदलते हैं, एक rust-llvm पैकेज और एक वैकल्पिक rust-llvm-Apple पैकेज बनाते हैं, और उनके बिटकोड से निपटने के लिए Apple LLVM को rustc लोड करते हैं।

एलएलवीएम को गतिशील रूप से लोड करना निश्चित रूप से एक विकल्प नहीं है। LLVM API अपने बिटकोड की तुलना में कम स्थिर है और, यदि हम LLVM xy के विरुद्ध निर्माण करते हैं, तो xy के बजाय LLVM xz होने से लगभग निश्चित रूप से जंग लग जाएगा। बस सिस्टम एलएलवीएम से स्थिर रूप से लिंक करें (जैसे --llvm-root पहले से ही करता है)।

हम एक rustc_llvm_apple क्रेट बनाते हैं और हर समय दो संपूर्ण LLVMs को rustc से जोड़ते हैं। यह शायद उड़ नहीं जाएगा

सेब वितरण के लिए बस सिस्टम एलएलवीएम (स्थिर रूप से) लिंक करें। मेरे अनुभव में यह पहले से ही बहुत अच्छा काम करता है।

हम अपने बिटकोड को उनके बिटकोड में अनुवाद करने के लिए एक बिटकोड सैनिटाइज़र की जांच कर सकते हैं। मुझे लगता है कि रखरखाव के कारण यहां सफलता की संभावना कम है। मेरा मानना ​​है कि रेंडरस्क्रिप्ट ऐसा करता है।

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

मुझे लगता है कि मैंने 2013-ईश में सभी तरह से सुना है कि एलएलवीएम बिटकोड का वितरण प्रारूप के रूप में उपयोग करना बेवकूफी है। मैं निश्चित रूप से सहमत हूं; देशी बाइनरी पुस्तकालयों को वितरित करना अब आईओएस के लिए काम नहीं करता है?

मुझे इस बात में भी बहुत दिलचस्पी है कि क्या होगा जब ऐप्पल एलएलवीएम संस्करण में असंगत बिटकोड प्रारूप के साथ आंतरिक रूप से अपग्रेड करता है और लोग अभी भी पुराने कंपाइलर्स के साथ सामान संकलित करते हैं।

मैंने इसके साथ संक्षेप में प्रयोग किया, यानी कार्गो बिल्ड के दौरान आउटपुट बिटकोड, फिर बिटकोड के साथ एक स्थिर पुस्तकालय बनाने की कोशिश की। जब मैंने बिटकोड लाइब्रेरी के खिलाफ एलएलवीएम-लिंक करने की कोशिश की, तो मुझे बिटकोड से एक असंगत एलएलवीएम संस्करण मिला।

मेरे पास इसे पुन: पेश करने के लिए एक आसान परीक्षण नहीं है, लेकिन मेरा अनुमान है कि केवल एक गूंगा संस्करण है जो विभिन्न एलएलवीएम संस्करणों के बीच लिंक करने से इनकार करता है? या, मैंने अभी कुछ पूरी तरह से गलत किया है। मैं एक परीक्षण मामले के साथ आने की कोशिश करूंगा जब मेरे पास इसे फिर से देखने के लिए कुछ समय होगा।

एलवीएम-लिंक से सटीक त्रुटि संदेश प्राप्त करना उपयोगी होगा।

@bluejekyll LLVM की परीक्षण निर्देशिका में कई बिटकोड फ़ाइलें हैं। इन बिटकोड फ़ाइलों के विरुद्ध परीक्षण लगातार चलाए जाते हैं (llvm-dis-3.8/opt-3.8 उदाहरण के लिए 3.2 से 3 साल पुरानी बिटकोड फ़ाइल को ठीक समझता है), इसलिए यह कुछ सेब सामान होना चाहिए।

सेब वितरण के लिए बस सिस्टम एलएलवीएम (स्थिर रूप से) लिंक करें। मेरे अनुभव में यह पहले से ही बहुत अच्छा काम करता है।

यह करने से कुछ आसान कहा जाता है - जहां तक ​​​​मुझे पता है, ऐप स्टोर अपलोड के लिए एकमात्र धन्य सेब-एलएलवीएम संस्करण वर्तमान एक्सकोड के साथ भेज दिया गया है। इसका संभावित रूप से दो एलएलवीएम संस्करणों के लिए एलएलवीएम बाइंडिंग को बनाए रखना भी है (जरूरी नहीं कि दो पड़ोसी छोटे संस्करण भी हों)। मुझे नहीं लगता कि यह सिर्फ Apple-llvm के पुराने संस्करण का उपयोग करने के लिए मान्य है।

मुझे इस बात में भी बहुत दिलचस्पी है कि क्या होगा जब ऐप्पल एलएलवीएम संस्करण में असंगत बिटकोड प्रारूप के साथ आंतरिक रूप से अपग्रेड करता है और लोग अभी भी पुराने कंपाइलर्स के साथ सामान संकलित करते हैं।

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

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

मुझे लगता है कि सभी अनुशंसित समाधान कुछ हद तक मुश्किल हैं। कम से कम गन्दा तरीका मैं सोच सकता हूं कि अलग-अलग लक्ष्यों को कोडजेन व्यवहार को अधिभारित करने की अनुमति देना और ऐप्पल कोडजन पथ गतिशील क्रेट में होना चाहिए। (जो सिर्फ सेब-एलएलवीएम के खिलाफ संकलित नियमित कोडजन पथ होगा।)

चूंकि यह बग ऐप स्टोर का उल्लेख करता है, क्या यहां अपवाद प्रबंधन कहानी के बारे में बात करना उचित है? (अर्थात panic=abort इस समय सख्ती से आवश्यक है।)

LLVM की परीक्षण निर्देशिका में कई बिटकोड फ़ाइलें हैं। इन बिटकोड फ़ाइलों के विरुद्ध परीक्षण लगातार चलाए जाते हैं (llvm-dis-3.8/opt-3.8 उदाहरण के लिए 3.2 से 3 साल पुरानी बिटकोड फ़ाइल को ठीक समझता है), इसलिए यह कुछ सेब सामान होना चाहिए।

@nagisa मुझे यह बताने के लिए धन्यवाद। यह मुझे आशा देता है कि यहां अभी भी एक समाधान हो सकता है, और शायद मैं कुछ गलत कर रहा था।

@ रिकी26 अच्छे अंक।

जहां तक ​​​​मुझे पता है, ऐप स्टोर अपलोड के लिए एकमात्र धन्य ऐप्पल-एलएलवीएम संस्करण वर्तमान एक्सकोड के साथ भेज दिया गया है।

ऐप्पल पर एक्सकोड एलएलवीएम सिस्टम एलएलवीएम के समान नहीं है? मेरा मतलब तब एक्सकोड एलएलवीएम था। हमें यह सुनिश्चित करना होगा कि रस्टसी ट्रेनों की शिपिंग करते समय xcode हमेशा नवीनतम संस्करण हो।

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

इसका संभावित अर्थ दो LLVM संस्करणों के लिए LLVM बाइंडिंग को बनाए रखना भी है

हम पहले से ही LLVM संस्करण 3.7 से 3.9 (और संभावित ट्रंक) के लिए समर्थन बनाए रखते हैं। जब तक एक्सकोड का एलएलवीएम कुछ प्राचीन संस्करण नहीं है, मुझे लगता है कि हम उस संबंध में अच्छे हैं। यदि एक्सकोड एलएलवीएम वास्तव में कुछ प्राचीन/कस्टम/आदि संस्करण है, तो मुझे नहीं लगता कि हम इस सुविधा का समर्थन करने में सक्षम हैं। खासकर जब से हमारे पास _that_ LLVM में पैच भेजने का कोई विकल्प नहीं है, ताकि हम अपनी जरूरत की सुविधाओं को जोड़ सकें। अगर Apple ने 2038 तक Xcode LLVM को अपडेट नहीं करने का फैसला किया है, तो मैं हमेशा के लिए 3.7 को सपोर्ट करने में rustc को लॉक नहीं करना चाहूंगा।

उत्तर: हालाँकि, यदि rustc को LLVM xy के विरुद्ध बनाया गया था, तो इसे LLVM xy से ठीक से जोड़ा जाना चाहिए।

एलएलवीएम को गतिशील रूप से लोड करना निश्चित रूप से एक विकल्प नहीं है। LLVM API अपने बिटकोड की तुलना में कम स्थिर है और, यदि हम LLVM xy के विरुद्ध निर्माण करते हैं, तो xy के बजाय LLVM xz होने से लगभग निश्चित रूप से जंग लग जाएगा। बस सिस्टम LLVM से स्थिर रूप से लिंक करें (जैसे --llvm-root पहले से ही करता है)।

@nagisa सी ++ एपीआई अस्थिर है, लेकिन हम सी एपीआई का उपयोग करते हैं और एक बार में एलएलवीएम के कई संस्करणों का समर्थन करने में बहुत सफलता मिली है। मुझे एपीआई समर्थन के मामले में अंतर नहीं दिख रहा है।

सेब वितरण के लिए बस सिस्टम एलएलवीएम (स्थिर रूप से) लिंक करें। मेरे अनुभव में यह पहले से ही बहुत अच्छा काम करता है।

हम सभी ऐप्पल प्लेटफ़ॉर्म के लिए ऐप्पल के एलएलवीएम को केवल कंबल शिप कर सकते हैं, लेकिन इसका मतलब है कि हमारे एलएलवीएम को डेस्कटॉप मशीन कोड जनरेशन के लिए सेब के साथ जोड़ना, और गैर-ऐप्पल होस्ट पर आईओएस बिटकोड का समर्थन करने के विकल्प को रोकता है।

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

बिटकोड प्रारूप संस्करणों के बीच स्थिर नहीं है।

देशी बाइनरी पुस्तकालयों को वितरित करना अब आईओएस के लिए काम नहीं करता है?

यह आज काम करता है। यह पसंदीदा तरीका नहीं है और यह स्पष्ट नहीं है कि इसका समर्थन जारी रहेगा।

इसका संभावित रूप से दो एलएलवीएम संस्करणों के लिए एलएलवीएम बाइंडिंग को बनाए रखना भी है (जरूरी नहीं कि दो पड़ोसी छोटे संस्करण भी हों)। मुझे नहीं लगता कि यह सिर्फ Apple-llvm के पुराने संस्करण का उपयोग करने के लिए मान्य है।

@ ricky26 हम LLVM के कई संस्करणों के बीच सफलतापूर्वक संगतता बनाए रखते हैं। जब तक ऐप्पल और हमारे बहुत दूर नहीं बहते हैं, यह करने योग्य होना चाहिए, लेकिन इस तरह के बड़े टूटने का खतरा हमेशा होता है कि विभाजन को पार नहीं किया जा सकता है, और मुझे पता है कि बड़े एपीआई परिवर्तन आ रहे हैं।

जब तक एक्सकोड का एलएलवीएम कुछ प्राचीन संस्करण नहीं है, मुझे लगता है कि हम उस संबंध में अच्छे हैं।

इस पेज से https://gist.github.com/yamaya/2924292 :

clang-700.0.72 => LLVM 3.7.0
clang-700.1.76 => LLVM 3.7.0
clang-700.1.81 => LLVM 3.7.0
clang-703.0.29 => LLVM 3.8.0
clang-703.0.31 => LLVM 3.8.0

सी ++ एपीआई अस्थिर है, लेकिन हम सी एपीआई का उपयोग करते हैं और एलएलवीएम के कई संस्करणों को एक साथ समर्थन करने में बहुत सफलता मिली है। मुझे एपीआई समर्थन के मामले में अंतर नहीं दिख रहा है।

यह सच नहीं है। हमारे पास rustllvm के रूप में C++ API के लिए कई बाइंडिंग (काफी बड़ी!) हैं। ऐसे कई मामले हैं जहां हम संकलित एलएलवीएम के संस्करण के आधार पर उस रैपर को संकलित करते हैं। यदि एलएलवीएम का उपयोग किया गया और संकलित संस्करण मेल नहीं खाता है, तो आपको गतिशील लिंकर त्रुटियां मिलेंगी, या इससे भी बदतर, रनटाइम पर समस्याओं में भाग लेंगे।

गैर-ऐप्पल होस्ट पर आईओएस बिटकोड का समर्थन करने के विकल्प को रोकता है।

यदि ऐप्पल एलएलवीएम के अपने कांटे के अलावा किसी और चीज से उत्पन्न बिटकोड नहीं लेना चाहता है, तो मुझे नहीं लगता कि हम एक समान कांटा बनाए रखने और उनके आंतरिक पैच को रिवर्स-इंजीनियरिंग करने के अलावा यहां कुछ भी कैसे कर सकते हैं।

बिटकोड प्रारूप संस्करणों के बीच स्थिर नहीं है।

निश्चित रूप से, लेकिन यह मान लेना काफी उचित है कि एलएलवीएम के विभिन्न संशोधनों के बीच बिटकोड 3.7.0 के रूप में जाना जाता है, उदाहरण के लिए, 3.7.0 श्रृंखला से एलएलवीएम के दूसरे बिल्ड द्वारा खपत के लिए बिटकोड उत्पन्न करने के उद्देश्यों के लिए पर्याप्त रूप से संगत है। यह निश्चित रूप से libLLVM को गतिशील रूप से जोड़ने से बेहतर है।

: विशेष रूप से यह देखते हुए कि 3.2 श्रृंखला से बिटकोड अभी भी 3.8 LLVM के साथ संगत है, भले ही वह बहुत छोटा नमूना हो।

कुछ नोट:

• एक्सकोड एक लिंक करने योग्य libLLVM (स्थिर या गतिशील) के साथ भी नहीं भेजता है, केवल एक libclang.dylib जो एलएलवीएम से स्थिर रूप से लिंक करता है।
• ऐप्पल https://opensource.apple.com पर 'डेवलपर टूल्स' के तहत अपने 'क्लैंग' (एलएलवीएम सहित) के स्रोत को शिप करता है, लेकिन उस साइट को अपडेट होने में हमेशा के लिए समय लगता है।
• कहानी स्विफ्ट के साथ बेहतर हो सकती है, जिसमें रिलीज टैग के साथ एलएलवीएम का अपना कांटा है - लेकिन वे पूरी तरह से एक्सकोड के साथ भेजे गए के अनुरूप नहीं हो सकते हैं। (एक्सकोड के साथ ओपन-सोर्स टूलचेन स्नैपशॉट्स का उपयोग करना संभव है, लेकिन ऐसे टूलचेन के साथ निर्मित प्रोजेक्ट्स को ऐप स्टोर में सबमिट नहीं किया जा सकता है।)

cc @ रस्ट-लैंग/कंपाइलर

यह जानने के लिए उत्सुक होंगे कि अन्य प्रोग्रामिंग भाषाएं इससे निपटने की योजना कैसे बनाती हैं। विशेष रूप से मोनो और जाओ।

इस समस्या का एकता का उत्तर il2cpp है - अपने सभी आईएल असेंबली को सी ++ कोड में बनाना।

प्रासंगिक गोलंग बग: https://github.com/golang/go/issues/12682; ऐसा लगता है कि सुझाव यह है कि वे एलएलवीएम गो टूलचेन का उपयोग कर सकते हैं (जो मानक गो टूलचेन के रूप में प्रदर्शित नहीं है)।

कुल मिलाकर, ऐप्पल के बाहर बिटकोड समर्थन की कहानी खराब है।

मोनो उचित सेब एलएलवीएम के माध्यम से जाता है यह प्रकट होगा: http://tirania.org/blog/archive/2015/Sep-02.html

एक ठोकर यह होगी कि आप बिटकोड में इनलाइन असेंबली नहीं ले जा सकते :(

मोनो कहानी के लिए मैंने मिगुएल डी इकाज़ा के साथ एक त्वरित आदान-प्रदान किया था कि मोनो जिज्ञासु के लिए क्या करता है: https://twitter.com/mitsuhiko/status/769458873237434368

@mitsuhiko You _can_ में आईओएस और टीवीओएस पर बिटकोड में इनलाइन असेंबली है, लेकिन वॉचओएस नहीं, किसी कारण से।

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

मुझे लगता है कि सभी अनुशंसित समाधान कुछ हद तक मुश्किल हैं। कम से कम गन्दा तरीका मैं सोच सकता हूं कि अलग-अलग लक्ष्यों को कोडजेन व्यवहार को अधिभारित करने की अनुमति देना और ऐप्पल कोडजन पथ गतिशील क्रेट में होना चाहिए। (जो सिर्फ सेब-एलएलवीएम के खिलाफ संकलित नियमित कोडजन पथ होगा।)

यह दृष्टिकोण (@ ricky26 द्वारा) एक जंगली उपयोगकर्ता के रूप में मेरे लिए सबसे स्वाभाविक प्रतीत होता है।

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

क्या इस पर कोई अपडेट हैं?

HackerNews पर यह टिप्पणीकार macOS और iOS पर रस्ट से उत्पन्न बिटकोड का उपयोग करने में सफल रहा है। रस्ट बायनेरिज़ के लिए बिटकोड को सक्षम करने के तरीके के बारे में थ्रेड में कुछ विस्तृत जानकारी है, जो एक अच्छी खबर की तरह लगता है!

https://news.ycombinator.com/item?id=14305084

प्रश्न में टिप्पणीकार के रूप में, त्वरित नोट्स:

• मैंने वर्तमान क्रेट और सभी निर्भरताओं वाली एक .bc फ़ाइल को उत्सर्जित करने के लिए rustc प्राप्त करने के लिए -C lto --emit llvm-bc का उपयोग किया। यह काम करता है, लेकिन अनिवार्य रूप से एक हैक है; विशेष रूप से, यह सी निर्भरताओं के लिए काम नहीं करता है, जिसमें जेमलोक भी शामिल है (हालांकि इसका उपयोग आईओएस पर वैसे भी नहीं किया जाता है)। यह बेहतर होगा यदि rustc "एम्बेडेड बिटकोड" के साथ Mach-Os को उत्सर्जित करने का ठीक से समर्थन करता है; यह कैसे किया जाता है यह देखने के लिए आप क्लैंग स्रोत को देख सकते हैं।

• यदि आप इसे आज़माना चाहते हैं और हैक से कोई आपत्ति नहीं है, तो यह संस्करण के मुद्दे को छोड़कर, 'बस काम' करने लगता है:

• मुख्य व्यावहारिक बाधा यह है कि जंग एलएलवीएम ट्रंक के साथ एक्सकोड की तुलना में अधिक बार सिंक करता है, जो ऐसा लगता है कि ऐसा केवल वार्षिक रूप से होता है। नए एलएलवीएम संस्करण पुराने बिटकोड को लोड कर सकते हैं, लेकिन दूसरी तरफ नहीं, इसलिए आपको या तो पुराने संस्करण का उपयोग करना होगा या पुराने एलएलवीएम के खिलाफ नवीनतम बनाना होगा। (वास्तव में, rustc 1.17 अभी भी Xcode 8.x के साथ काम करता प्रतीत होता है, लेकिन LLVM 4.0 अपग्रेड के बाद से रात में नहीं; हालांकि यह सिर्फ संयोग है।)

• आदर्श रूप से रस्ट एक उपयुक्त एलएलवीएम संस्करण के विरुद्ध निर्मित आधिकारिक बायनेरिज़ को शिप करेगा। व्यवहार में, स्टॉक LLVM के सही संस्करण का उपयोग करना ठीक लगता है, लेकिन यदि आप Apple के कांटे का उपयोग करना चाहते हैं:

  • जैसा कि मैंने पिछली टिप्पणी में कहा था, एक्सकोड एलएलवीएम बाइनरी को किसी भी लिंक करने योग्य रूप में गतिशील रूप से भी नहीं भेजता है; केवल क्लैंग और libclang.dylib (जो क्लैंग एपीआई निर्यात करता है लेकिन एलएलवीएम एक नहीं)।
  • लेकिन, जैसा कि मैंने यह भी कहा, स्रोत कोड आमतौर पर opensource.apple.com (डेवलपर टूल्स -> क्लैंग के तहत; संग्रह में सभी एलएलवीएम शामिल हैं) पर जाता है, बस कुछ हद तक असंगत रूप से/देरी के बाद। हालाँकि, विशेष रूप से @alexcrichton द्वारा नोट की गई विस्तारित पश्चगामी संगतता गारंटी को

(एक परीक्षण के रूप में, मैंने एक्सकोड 8.2.1 क्लैंग के खिलाफ जंग को संकलित करने का प्रयास किया। rustllvm निर्माण में विफल रहता है, क्योंकि इसका घोंसला #if LLVM_VERSION_GE(..) सशर्त है, जो इसे दोनों के खिलाफ संकलित करने की अनुमति देने के लिए है पुराने और नए एलएलवीएम, इस शाखा से भ्रमित हो जाते हैं - जो एलएलवीएम 3.9 एसवीएन होने का दावा करता है, लेकिन एपीआई-वार 3.8 और 3.9 के बीच कहीं है। शायद फिक्सिंग के लायक नहीं है, क्योंकि एक्सकोड लगभग अगले वार्षिक रीफ्रेश के लिए लगभग है।)

क्या इस मोर्चे पर कोई प्रगति हुई है? वैकल्पिक रूप से क्या आप (कोर टीम) इस समस्या को एक ठोस स्थायी समाधान के साथ एक मुद्दे पर विचार करेंगे या क्या आप उम्मीद करते हैं कि यह संस्करण निकट भविष्य के लिए बना रहेगा?

मैं अपने बेहतर प्रकार की प्रणाली और निम्न-स्तरीय शब्दार्थ के लिए रस्ट में एक iOS ऐप के कुछ हिस्सों को लागू करने पर विचार कर रहा हूं और जब भी Xcode या rustc के लिए कोई अपडेट होता है, तो गैर-बिटकोड या नियमित हैक्स/देरी से नहीं फंसना चाहिए।

@regexident

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

सीसी #45684

क्या Apple का बिटकोड अभी भी वास्तव में खतरनाक नहीं है https://medium.com/@FredericJacobs/why -im-not-enable-bitcode-f35cd8fbfcc5 बिल्ड को सत्यापित करना असंभव है। क्रिप्टोग्राफी के लिए मुद्दे। आदि।

@burdges कुछ ऐप्स के लिए यह बिल्कुल एक समस्या है।

लेकिन वॉचओएस और टीवीओएस के लिए ऐप्पल को वास्तव में ऐप स्टोर सबमिशन के लिए बिटकोड की आवश्यकता होती है। आपके पास कोई विकल्प नहीं है। "उन प्लेटफार्मों पर क्रिप्टो या महत्वपूर्ण सामान न करें" के अलावा। भविष्य में किसी बिंदु पर आईओएस के लिए बिटकोड को लागू करने वाले ऐप्पल से भी डरना पड़ता है। मेरे पास उस समय एक ब्रिकेट वाला उत्पाद नहीं होगा।

मैंने -C lto --emit=llvm-bc चाल का उपयोग करके आईओएस के लिए जंग 1.24.0 के साथ निर्माण करने की कोशिश की, लेकिन लिंकर ने निम्नलिखित त्रुटियां दीं:

Undefined symbols for architecture x86_64:
  "_backtrace_create_state", referenced from:
      std::sys_common::gnu::libbacktrace::init_state::h686c3e443c712b0f in Logger(x86_64.o)
  "_backtrace_syminfo", referenced from:
      std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h598a932d5bb0d80b in Logger(x86_64.o)
      core::iter::iterator::Iterator::position::_$u7b$$u7b$closure$u7d$$u7d$::hbf03153d55553502 in Logger(x86_64.o)
  "_backtrace_pcinfo", referenced from:
      std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h598a932d5bb0d80b in Logger(x86_64.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

कोई विचार क्या मुद्दा हो सकता है?

संपादित करें: ऐसा प्रतीत होता है कि मैं प्रत्येक सार्वजनिक बाहरी fn में AssertUnwindSafe साथ सभी कोड लपेटकर उस मुद्दे को कम से कम दबा सकता हूं

libbacktrace एक C लाइब्रेरी है जो रस्ट सोर्स ट्री में शामिल है:

https://github.com/rust-lang/rust/tree/master/src/libbacktrace

आपको इसे किसी भी तरह बिटकोड के रूप में संकलित करना होगा।

मैं उलझन में हूं, क्योंकि मैं केवल अपने लैपटॉप के लिए बनाया गया एक libbacktrace ढूंढ सकता हूं, लेकिन फोन ओएस के लिए नहीं। जंग उन प्रतीकों को stdlib में कैसे सम्मिलित करता है? बैकट्रेस कार्यक्षमता को किसी भी तरह अक्षम करके, ऐसा करने का कोई आसान तरीका है? मैंने RUST_BACKTRACE env var हटा दिया लेकिन इससे कोई फायदा नहीं हुआ। मैंने पढ़ा है कि आप बिना बैकट्रेस के rustc को संकलित कर सकते हैं, लेकिन मैं कुछ आसान की उम्मीद कर रहा था, उदाहरण के लिए मेरे प्रोजेक्ट की कार्गो.टॉमल फ़ाइल में

मूल रूप से आप C कंपाइलर को -fembed-bitcode पास करने के लिए कहते हुए rustc सोर्स ट्री बनाना चाहते हैं। आदर्श रूप से आप इसे केवल CFLAGS जोड़ पाएंगे; दुर्भाग्य से, मैंने अभी कोशिश की है, और यह gcc-rs साथ दो मुद्दों के कारण ठीक से काम नहीं करता है (सी निर्भरता बनाने के लिए rustc के निर्माण प्रणाली द्वारा उपयोग किया जाता है)। हालांकि, मुझे यह एक हैकी प्रक्रिया के साथ काम करने के लिए मिला:

cd /tmp/build
cat >ccwrap.py <<END

#!/usr/bin/env python
import os, sys
os.execv('/usr/bin/xcrun', ['clang', '-fembed-bitcode'] + [arg for arg in sys.argv[1:] if arg not in {'-ffunction-sections', '-fdata-sections'}])

END

chmod 755 ccwrap.py
ln -s /usr/bin/ar ar
export CC_aarch64_apple_ios=`pwd`/ccwrap.py
/usr/src/rust/configure --target=aarch64-apple-ios
make

यह आपको बिटकोड एम्बेडेड के साथ libbacktrace.a ( ./build/aarch64-apple-ios/native/libbacktrace/.libs/ ) प्राप्त करना चाहिए। __LLVM,__bitcode में बिटकोड एम्बेड करने के लिए rustc के लिए है।

(वास्तव में, चूंकि आपके द्वारा उद्धृत त्रुटि एक सामान्य लिंकर त्रुटि की तरह दिखती है, मुझे लगता है कि आप इसे केवल एक नियमित, बिना बिटकोड-एम्बेडेड libbacktrace.a को लिंक करके प्राप्त कर सकते हैं। लेकिन सबसे अच्छा इसका परिणाम आउटपुट फ़ाइल में होगा टूटे हुए एम्बेडेड बिटकोड के साथ।)

उपरोक्त मुद्दे:

• gcc-rs -ffunction-sections और -fdata-sections और उन्हें बंद करने का कोई तरीका नहीं है; -fembed-bitcode के साथ संयुक्त होने पर क्लैंग इनके बारे में शिकायत करता है (भले ही -fno-function-sections बाद में पारित हो जाए)।

मैंने एक समस्या रिपोर्ट दायर

• gcc-rs ar को CC_aarch64_apple_ios (!?) के समान निर्देशिका में खोजने का प्रयास करता है; मैन्युअल रूप से AR_aarch64_apple_ios से कोई प्रभाव नहीं पड़ा

मैं इसे नवीनतम cc-rs ( gcc-rs से बदला गया) के साथ पुन: पेश नहीं कर सका, इसलिए मैंने कोई समस्या दर्ज नहीं की। वर्कअराउंड के रूप में, उपरोक्त प्रक्रिया ar को उसी निर्देशिका में सिम्लिंक करती है।

सुझावों के लिए धन्यवाद! मुझे वास्तव में सिर्फ अपने कोड के लिए बिटकोड की आवश्यकता थी, बैकट्रेस सामान की नहीं, इसलिए मैंने बिना किसी बिटकोड एम्बेडिंग के संकलित लिबबैकट्रेस का उपयोग किया

हैक के साथ मैंने कोशिश की, अब मैं एक और मुद्दा मार रहा हूं: dsymutil segfaults जब मैं इसके लिए एक डीएसवाईएम बनाने की कोशिश करता हूं। dSYM के बिना सामान्य निष्पादन ठीक काम करता है, लेकिन dSYM निर्माण किसी कारण से टूट जाता है। मैंने अपना libbacktrace.a हटा दिया, इसे खाली प्लेसहोल्डर फ़ंक्शंस से बदल दिया, और चीजें ठीक काम कर गईं, इसलिए ऐसा लगता है कि मेरे जंग के साथ कोई समस्या है।

यह dsymutil में एक बग की तरह लगता है, जिसे LLVM को अपस्ट्रीम में रिपोर्ट किया जाना चाहिए। क्या आप एलएलडीबी के तहत dsymutil चलाने और दुर्घटना का बैकट्रैक पोस्ट करने का प्रयास कर सकते हैं? या बेहतर डिबग जानकारी प्राप्त करने के लिए, आप डिबग मोड में LLVM बनाने और उसके साथ इसे पुन: प्रस्तुत करने का प्रयास कर सकते हैं।

(ध्यान दें कि एक शेयर LLVM स्थापना में द्विआधारी कहा जाता है llvm-dsymutil , लेकिन इन दिनों Xcode के dsymutil है सिर्फ एक के लिए सिमलिंक llvm-dsymutil । dsymutil हुआ करता था एक अलग, बंद स्रोत उपयोगिता, लेकिन कुछ वर्षों के लिए उस संस्करण को dsymutil-classic रूप में भेज दिया गया है और डिफ़ॉल्ट रूप से उपयोग नहीं किया गया है।)

@comex जिज्ञासा से बाहर, क्या cc टोकरा -fembed-bitcode साथ सब कुछ संकलित करना चाहिए? या अगर हम "आधिकारिक" क्लैंग का उपयोग कर रहे हैं तो क्या बिटकोड एम्बेड करने से बचना ठीक है?

(क्षमा करें, मैं आईओएस सर्वोत्तम प्रथाओं से बहुत परिचित नहीं हूँ!)

रस्ट कोड के लिए, क्या यह सबसे अच्छा होगा यदि हम ऑब्जेक्ट फ़ाइलों के बजाय केवल बाइटकोड का उत्सर्जन करते हैं? क्या ऐसा कुछ है जिसे क्लैंग/लिंकर समझ सकता है?

@एलेक्सक्रिचटन

क्या cc टोकरा -fembed-bitcode साथ सब कुछ संकलित करना चाहिए? या अगर हम "आधिकारिक" क्लैंग का उपयोग कर रहे हैं तो क्या बिटकोड एम्बेड करने से बचना ठीक है?

आधिकारिक क्लैंग का उपयोग करने से एम्बेडेड बिटकोड की आवश्यकता समाप्त नहीं होती है। इसके बजाय, बिटकोड शामिल हो जाता है - मूल कोड के अलावा - ऐप्पल पर अपलोड किए गए ऐप संग्रह में, और फिर ऐप्पल इसे सर्वर साइड पर पुन: संकलित कर सकता है, उदाहरण के लिए विभिन्न माइक्रोआर्किटेक्चर के लिए अनुकूलित करने के लिए।

आईओएस/वॉचओएस/टीवीओएस पर डिफ़ॉल्ट रूप से -fembed-bitcode पास करना शायद समझ में आता है। यदि ऐसा है, तो डीबग मोड में निर्माण करते समय, -fembed-bitcode-marker पारित किया जाना चाहिए (इसके बजाय या इसके अतिरिक्त, कोई फर्क नहीं पड़ता); यह क्लैंग को किसी भी वास्तविक बिटकोड के बजाय केवल एक डमी बिटकोड अनुभाग को शामिल करने के लिए कहता है, क्योंकि एम्बेडेड बिटकोड केवल अंतिम ऐप अभिलेखागार के लिए आवश्यक है और इसे छोड़ने के लिए संकलन को थोड़ा गति देता है। असल में, एक्सकोड अंतिम ऐप संग्रह बनाने के अलावा अन्य सभी चीज़ों के लिए -fembed-bitcode-marker पास करता है, यहां तक ​​​​कि विकास भी बनाता है जो ऑप्टिमाइज़ेशन के लिए होता है - लेकिन चूंकि cc में "वास्तव में अंतिम रिलीज" की एक अलग अवधारणा नहीं है मोड", इसे शायद इसे डीबग मोड में पास करना चाहिए। ध्यान दें कि बिटकोड को एम्बेड करना सुरक्षित है, भले ही अंतिम निर्माण के लिए इसकी आवश्यकता न हो।

रस्ट कोड के लिए, क्या यह सबसे अच्छा होगा यदि हम ऑब्जेक्ट फ़ाइलों के बजाय केवल बाइटकोड का उत्सर्जन करते हैं? क्या ऐसा कुछ है जिसे क्लैंग/लिंकर समझ सकता है?

क्लैंग और एलडी दोनों इनपुट के रूप में पारित कच्चे बिटकोड फाइलों का समर्थन करते हैं; यह आमतौर पर तब उपयोग किया जाता है जब एलटीओ सक्षम होता है ( -flto ), जिस स्थिति में .o फ़ाइलें क्लैंग जेनरेट करती हैं वास्तव में कच्चे बिटकोड होते हैं, मैक-ओ नहीं। (इन्हें अभी भी सामान्य लाइपो कमांड का उपयोग करके स्थिर पुस्तकालयों में बनाया जा सकता है।) हालांकि, यह "एम्बेडेड बिटकोड" प्रारूप से अलग है, जिसमें __LLVM,__bitcode अनुभाग में भरे हुए बिटकोड के साथ मच-ओ होता है। सामान्य वर्गों में मूल कोड के अलावा। एलटीओ बंद होने पर इस प्रारूप का उपयोग ऑब्जेक्ट फाइलों में किया जाता है, साथ ही एलटीओ सेटिंग की परवाह किए बिना अंतिम लिंक किए गए निष्पादन योग्य या गतिशील पुस्तकालयों में भी। (यदि एलटीओ चालू है, तो लिंकर इस अनुभाग को बनाने के लिए जिम्मेदार है; यदि एलटीओ बंद है, तो लिंकर प्रत्येक ऑब्जेक्ट फ़ाइल से केवल __LLVM,__bitcode अनुभागों को जोड़ देता है, जैसे कि यह किसी एकल संयुक्त को उत्पन्न करने के बजाय किसी अन्य अनुभाग के लिए होता है। बिटकोड मॉड्यूल। ) संपादित करें: वास्तव में, यह कुछ अधिक जटिल करता __LLVM,__bundle नामक अनुभाग में रखता है; वैसे भी, ऐसा कुछ नहीं जिसकी हमें परवाह है।

मुझे लगता है कि आदर्श रूप से rustc को iOS पर डिफ़ॉल्ट रूप से "एम्बेडेड बिटकोड" का उत्पादन करना चाहिए, न कि कच्चे बिटकोड का। यह करना बहुत कठिन नहीं है, और यह वृद्धिशील संकलन को तोड़ने से बचाता है - विशेष रूप से डीबग मोड में जहां आप केवल एक डमी बिटकोड अनुभाग, ala -fembed-bitcode-marker उत्पन्न कर सकते हैं, लेकिन संभावित रूप से रिलीज मोड में भी, क्योंकि लिंकर केवल वस्तुओं को भर देता है ' लिंक समय पर कुछ भी महंगा करने के बजाय बिटकोड अनुभाग एक साथ।

यहां बताया गया है कि क्लैंग कैसे एम्बेडेड बिटकोड उत्पन्न करता है:

https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/BackendUtil.cpp#L1242

अपेक्षाकृत सरल - बैकएंड को लागू करने से पहले, यह वर्तमान एलएलवीएम मॉड्यूल को बिटकोड के रूप में डंप करता है, फिर
सामान जो बाइनरी डेटा के रूप में एक नए वैश्विक चर में (उसी मॉड्यूल में!), __LLVM,__bitcode अनुभाग में रखा गया है। यह एक हैकी डिज़ाइन की तरह लगता है (फ्रंटएंड को इसे मैन्युअल रूप से क्यों करना पड़ता है?), लेकिन इसे जंग में पुन: पेश करना बहुत कठिन नहीं होना चाहिए।

@comex वह दृष्टिकोण समझ में आता है, हालांकि मुझे लगता है कि ऐप्पल के क्लैंग को बैकएंड के रूप में उपयोग करने के लिए कारण हैं (देखें # 48833 जो मैंने अभी बनाया है), जबकि हम इस तरह के बदलावों के बारे में सोच रहे हैं। साथ ही, एम्बेडेड बिटकोड से खुद को संकलित करना कितना आसान है?

@michaeleiselsc क्षमा करें, मुझे समझ में नहीं आता कि "एम्बेडेड बिटकोड से खुद को संकलित करें" से आपका क्या मतलब है।

जैसा कि, ऐप स्टोर को केवल बिटकोड एम्बेडेड के साथ एक बाइनरी देने के बजाय, बिटकोड लेने और ऐप्पल क्लैंग का उपयोग करके इसे स्वयं से बनाने के लाभ भी हैं। जिन दो लाभों में मेरी दिलचस्पी है, वे हैं डाउनस्ट्रीम फिक्स जो कि Apple क्लैंग में हैं और क्लैंग सैनिटाइज़र का उपयोग करने की क्षमता, जैसे कवरेज सैनिटाइज़र।

@comex ठीक है तो थोड़ा सा खोदना, ऐसा लगता है कि rustc में कार्यान्वयन काफी आसान है (अपेक्षाकृत), लेकिन मेरे पास कुछ प्रश्न हैं:

• -fembed-bitcode-marker एक चीज़ क्यों है? क्लैंग का उपयोग स्थानीय रूप से यह सिर्फ एक खाली स्थैतिक को एक खंड में उत्सर्जित करता है। क्या इसका मतलब केवल अनुभाग की उपस्थिति का मतलब कुछ है? क्या आईओएस में सड़क के किनारे कोई उपकरण टूट जाता है यदि अनुभाग नहीं है? (लेकिन यह वास्तव में अनुभाग के अंदर नहीं दिखता क्योंकि यह खाली है?
• क्या आप जानते हैं कि __cmdline अनुभाग आवश्यक है या नहीं? ऐसा लगता है कि -fembed-bitcode बाइनरी में कमांडलाइन के कुछ रूप को भी एम्बेड करता है। मुझे सच में यकीन नहीं है कि हम यहां क्या रखेंगे क्योंकि यह शायद rustc की कमांड लाइन नहीं है, लेकिन क्या कोई टूल इसे देखता है? यदि आईओएस के साथ -fembed-bitcode=bitcode का उपयोग किया जाता है तो क्या संकलन टूट जाता है?
• और अंत में, क्या इसे कभी भी अक्षम करने का कोई कारण है? या क्या हमें बिना शर्त इसे आईओएस लक्ष्यों के लिए सक्षम करना चाहिए और आगे बढ़ना चाहिए?

-fembed-bitcode-marker एक चीज क्यों है?

मुझे लगता है कि इसका उपयोग एक्सकोड द्वारा इंगित करने के लिए किया जाता है कि कुछ बिटकोड का उपयोग करना चाहिए लेकिन बिटकोड वास्तव में संकलित नहीं किया गया था। यदि आप ऐसी परियोजना को बाद में संग्रहीत करने का प्रयास करते हैं तो एलडी एक त्रुटि के साथ विफल हो जाएगा।

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

@mitsuhiko हां, विचार लिंकर पुष्टि कर सकते हैं कि कि निर्माण ठीक से bitcode के लिए सेट किया गया है, भले ही आप वर्तमान परीक्षण कर रहे हैं कि वास्तव में जरूरत नहीं है bitcode बनाता है।

उदाहरण के लिए, यदि आप बिटकोड का उल्लेख किए बिना सी फ़ाइल संकलित करते हैं, तो इसे -fembed-bitcode-marker से जोड़ने का प्रयास करें, आपको मिलता है:

$ clang -c -o test.o test.c
$ clang -dynamiclib -o test.dylib test.o -fembed-bitcode-marker
ld: warning: all bitcode will be dropped because 'test.o' was built
without bitcode. You must rebuild it with bitcode enabled (Xcode
setting ENABLE_BITCODE), obtain an updated library from the vendor,
or disable bitcode for this target.

यदि आप पहली पंक्ति में भी -fembed-bitcode-marker पास करते हैं तो चेतावनी दूर हो जाती है।

@alexcrichton __cmdline ... हम्म ... ऐसा लगता है कि लिंकर को इसे उपस्थित होने की आवश्यकता है ("बिटकोड बनाएं" के लिए खोजें):

https://opensource.apple.com/source/ld64/ld64-274.2/src/ld/parsers/macho_relocatable_file.cpp.auto.html

लेकिन मुझे ऐसा कुछ भी नहीं दिखता जो वास्तविक मूल्य की परवाह करता हो। शायद वहां डमी वैल्यू डालना सबसे अच्छा है।

क्या #48896 को मर्ज करके इस समस्या का समाधान किया गया?

मैं रात के निर्माण पर इसके साथ खेल रहा हूं, और जब तक आप एक्सकोड के साथ संग्रह करने का प्रयास नहीं करते तब तक यह बहुत अच्छा काम करता है। ऐसा लगता है कि यह रस्ट स्टैटिक लाइब्रेरी आउटपुट में fembed-bitcode-marker लेकिन fembed-bitcode नहीं जोड़ रहा है। इसे cargo lipo --release साथ संकलित किया गया है:

$ cargo --version
cargo 1.27.0-nightly (af3f1cd29 2018-05-03)
$ cargo lipo --version
cargo-lipo 2.0.0-beta-2
$ rustc --version
rustc 1.27.0-nightly (565235ee7 2018-05-07)

ld: '/Users/chrisbal/Documents/Beach/rust-universal-template/target/universal/release/libexample.a(example_generic-be72fb1769c1779b.example_generic6-152d14edfb6970f54250733c74e59b7.rs.rcgu.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

जब मैं otool -arch arm64 -l /Users/chrisbal/Documents/Beach/rust-universal-template/target/universal/release/libexample.a | grep bitcode चलाता हूं तो मुझे बहुत सारे sectname __bitcode मिलते हैं, लेकिन मुझे नहीं पता कि यह कैसे जांचा जाए कि यह वास्तविक बिटकोड है न कि केवल मार्कर।

मैं नेस्टेड क्रेट्स का उपयोग कर रहा हूं, इसलिए शायद आंतरिक "जेनेरिक" क्रेट को बिटकोड झंडे नहीं मिल रहे हैं?

संपादित करें: यहां हमारा रेपो इस मुद्दे को प्रदर्शित कर रहा है https://github.com/Raizlabs/rust-universal-template/tree/879e7412d729e8963586c5b083d51b09733aec32

@chrisballinger , यह अतिरिक्त ध्वज के साथ काम करता है, देखें
RUSTFLAGS="-Z embed-bitcode" cargo lipo --release

$ cargo --version
cargo 1.28.0-nightly (f352115d5 2018-05-15)
$ cargo lipo --version
cargo-lipo 2.0.0-beta-2
$ rustc --version
rustc 1.28.0-nightly (952f344cd 2018-05-18)

लेकिन मेरे पास केवल arm7 आर्क के लिए एक और संकलन त्रुटि है:

.rs.rcgu.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture armv7

क्या कोई जानता है कि arm7 arch को कैसे ठीक किया जाए?

अफसोस की बात है कि यह काम भी नहीं कर सकता, @chrisballinger जैसी ही त्रुटि हो रही है:

ld: '/sandbox/target/universal/release/librgame.a(std-da6dba40351cda22.std3-d36cd881bae00a8b5fc36289b5737f78.rs.rcgu.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

मैंने इसे RUSTFLAGS="-Z embed-bitcode" cargo lipo --release साथ संकलित करने और इसे .cargo/config । हालांकि यह ध्वज जोड़ता है:

` Executing: "cargo" "build" "--target" "x86_64-apple-ios" "--lib" "--features" "" "--color" "auto" "--release" "--verbose" Compiling libc v0.2.42 Compiling rand_core v0.2.1 Running `rustc --crate-name libc /Users/aleksandrivanov/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.42/src/lib.rs --crate-type lib --emit=dep-info,link -C opt-level=3 --cfg 'feature="default"' --cfg 'feature="use_std"' -C metadata=dce309634355ac97 -C extra-filename=-dce309634355ac97 --out-dir /Users/aleksandrivanov/Sandbox/Projects/tetris/rgame/target/x86_64-apple-ios/release/deps --target x86_64-apple-ios -L dependency=/Users/aleksandrivanov/Sandbox/Projects/tetris/rgame/target/x86_64-apple-ios/release/deps -L dependency=/Users/aleksandrivanov/Sandbox/Projects/tetris/rgame/target/release/deps --cap-lints allow -Zembed-bitcode` ...

यहां कोई अपडेट? हमारे ऐप के लिए साझा कोर लाइब्रेरी पर भारी विचार करना और इसके बिना निश्चित सी ++ संभावित विकल्प है।

@chrisballinger , क्या यह https://github.com/rust-lang/rust/issues/52686 से संबंधित हो सकता है

@volodg नहीं, यह मुद्दा कुछ समय पहले का है।

#48896 के विलय के साथ, क्या यह लीक से हटकर काम करने वाला है?

मैं 1.29.1 पर हूं और वस्तुओं में अभी भी डिफ़ॉल्ट रूप से बिटकोड नहीं है। जैसा कि पहले @volodg द्वारा उल्लेख किया गया है, आप RUSTFLAGS="-Z embed-bitcode" का उपयोग करके उन्हें एम्बेड करने के लिए जंग प्राप्त कर सकते हैं। लेकिन, जो मैंने अनुभव किया है, उसके बाद आप उस मुद्दे पर आ जाते हैं जहां जंग के अपने libs (compiler_builtins, std) एम्बेड-बिटकोड के साथ संकलित नहीं होते हैं। शायद एम्बेड-बिटकोड के साथ xargo का उपयोग करके आईओएस लक्ष्यों का पुनर्निर्माण करना काम करेगा, लेकिन मैंने कोशिश नहीं की।

जैसा कि आपने प्रस्तावित किया था मैंने xargo का उपयोग करने की कोशिश की लेकिन समस्या अभी भी यहां है :(

इस Xargo.toml का उपयोग करना

[dependencies]
std = {}
[target]
features = ["jemalloc"]

इसे Cargo.toml भी जोड़ना:

[profile.release]
panic = "abort"

मैंने उन सभी लक्ष्यों के लिए xargo build --release --target $TARGET का उपयोग करके संकलित किया:

• aarch64-सेब-डार्विन
• armv7-सेब-डार्विन
• armv7s-सेब-डार्विन
• i386-सेब-डार्विन
• x86_84-सेब-डार्विन

तब मैंने एक स्थिर पुस्तकालय बनाने के लिए lipo का उपयोग किया।

मेरे पास अभी भी एक लिंकर त्रुटि है:

ld: '../../cargo/target/universal/libgreetings.a(greetings-ceeec73d35f7dbe0.greetings.9kcaav8v-cgu.2.rcgu.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

ज़ार्गो पथ के साथ थोड़ा और आगे बढ़े।

मेरा Xargo.toml

[dependencies]
std = {}

मेरा Cargo.toml

[profile.release]
panic = "abort"

यदि आवश्यक हो तो मैं kwow नहीं जानता, लेकिन xargo doc से, आपको स्पष्ट रूप से extern crate compiler_builtins उपयोग करने की आवश्यकता है, जिसे मैंने अपने lib.rs में जोड़ा है।

इसके बाद मैंने संकलित किया: RUSTFLAGS="-Z embed-bitcode" xargo build --target $TARGET --release संकलित करने के लिए। सुनिश्चित करें कि यह core/std/compiler_bultins बनाता है। xargo clean मेरे द्वारा अनुभव किए गए पिछले बिल्ड को सही ढंग से साफ नहीं करता है, इसलिए जब मैंने अलग-अलग Xargo.toml ट्वीक की कोशिश की तो एसटीडी को फिर से कंपाइल करने के लिए rm -rf ~/.xargo आवश्यक था।

लेकिन फिर, एक्सकोड 10 में संग्रह करना, मुझे ( armv7 लिंकिंग पर) मिलता है:

Intrinsic has incorrect argument type!
void (i8*, i8, i32, i1)* @llvm.memset.p0i8.i32
Intrinsic has incorrect argument type!
void (i8*, i8*, i32, i1)* @llvm.memcpy.p0i8.p0i8.i32
Intrinsic has incorrect argument type!
...
(lots of it)
...
LLVM ERROR: Broken module found, compilation aborted!
clang: error: linker command failed with exit code 1 (use -v to see invocation)

क्या इसका मतलब यह है कि बग एलएलवीएम की तरफ निर्भर करता है?

संपादित करें : हम इस मुद्दे में आगे बढ़ने में कैसे मदद कर सकते हैं?

क्या किसी ने हाल ही में यह कोशिश की है? ऐसा लगता है कि armv7 सबसे बड़ा मुद्दा है?

हेलो सब लोग। मैं कुछ समय से इस धागे का अनुसरण कर रहा हूं और मैं ऐप्पल बिटकोड को रस्ट के साथ समर्थित देखकर बहुत उत्साहित हूं। क्या कोई अब तक यह काम कर पाया है? वर्तमान में क्या गुम है और हम कैसे मदद कर सकते हैं?
धन्यवाद!

इस मुद्दे का शिकार करने के कुछ घंटों के बाद, मुझे पता चला कि रस्ट का बिटकोड एम्बेडिंग Xcode में काम नहीं कर रहा है। संक्षिप्त उत्तर यह है कि Xcode का LLVM संस्करण LLVM 6.0 बिटकोड की अपेक्षा कर रहा है, जबकि रस्ट जुलाई 2018 में LLVM 7.0 से टकरा गया है।

अब, लंबा जवाब ...

जैसा कि हम LLVM 7.0 के चैंज में देख सकते हैं, उन्होंने @llvm.memcpy , @llvm.memmove , और @llvm.memset लिए हस्ताक्षर बदल दिए, और Xcode बिल्ड त्रुटि गलत तर्क प्रकार के बारे में स्पष्ट थी जैसा कि देखा गया मेरी पिछली टिप्पणी में ।

वैसे, कोटलिन नेटिव ने अक्टूबर 2018 में एम्बेड-बिटकोड के लिए समर्थन जोड़ा और जाहिर तौर पर एक्सकोड में एलएलवीएम 6.0 का उपयोग करता है।

इसे देखते हुए, मैंने 7.0 से पहले रस्ट के पुराने संस्करण का उपयोग करके संकलन करने का प्रयास किया। मैंने nightly-2018-06-01-x86_64-apple-darwin साथ प्रयास किया, और सफलता, यह संकलित करता है!

मैंने बिना किसी सफलता के Xargo का उपयोग किए बिना संकलन करने का भी प्रयास किया। सभी निर्भरताओं को बिटकोड एम्बेडिंग के साथ संकलित करने की आवश्यकता है।

तो नीचे की रेखा, जब तक कि ऐप्पल अपने एलएलवीएम संस्करण को टक्कर नहीं देता, मुझे नहीं लगता कि हम जल्द ही एम्बेडेड बिटकोड के लिए समर्थन देखेंगे ... जब तक कोई एम्बेडेड बिटकोड को 6.0 के बिटकोड में कनवर्ट करने का एक चतुर तरीका नहीं ढूंढता ...

@appaquet इसकी तह तक जाने के लिए धन्यवाद! यह मेरे लिए काफी रहस्य था और मुझे नहीं लगता कि मैं कभी भी आपके जितना गहरा गोता लगाने जा रहा था। यह जानकर अच्छा लगा कि Apple द्वारा LLVM संस्करण को टक्कर देने के बाद इसे काम करना शुरू कर देना चाहिए।

आपके स्पष्ट उत्तर के लिए धन्यवाद @appaquet । अब मुझे लगता है कि हमें सही काम करने के लिए सिर्फ Apple पर निर्भर रहना होगा

मोबाइल के लिए मल्टीप्लेटफॉर्म में रुचि रखने वाले किसी व्यक्ति से साइडव्यू और अधिकांश आशाजनक समाधानों की तुलना (रिएक्ट नेटिव, स्पंदन, कोटलिन / नेटिव, रस्ट)

प्रतिक्रियाशील मूल निवासी। शुरुआत से बिटकोड का समर्थन करता है, क्योंकि अनिवार्य रूप से ब्रिज C++ में लिखा गया है और यह रनटाइम में JS कोड की व्याख्या कर रहा है।

स्पंदन। अभी तक बिटकोड का समर्थन नहीं करता - https://github.com/flutter/flutter/issues/15288

कोटलिन / मूल निवासी। JetBrains मोबाइल प्लेटफॉर्म को प्राथमिकता के रूप में मान रहा है और हालांकि इसमें उन्हें कुछ समय लगा और यह केवल बिटकोड मार्कर है (अभी तक पूर्ण बिटकोड नहीं है), यह काम करना शुरू करने के लिए पर्याप्त है - देखें https://github.com/JetBrains/kotlin-native/ पुल/1564 और https://github.com/JetBrains/kotlin-native/issues/1202#issuecomment -444022513

जंग। LLVM 7 के लिए बिटकोड का समर्थन करता है, जबकि Apple संस्करण 6 का उपयोग करता है।

अगर मैं बिजनेस लॉजिक और यूआई क्रॉसप्लेटफॉर्म दोनों रखना चाहता हूं, तो मैं रिएक्ट नेटिव या स्पंदन के साथ जाऊंगा। लेकिन कई गंभीर ऐप्स के लिए यह रास्ता बहुत जोखिम भरा है। प्रतिक्रिया मूल निवासी performant पर्याप्त और एपीआई नहीं है और निर्भरता स्थिरता एक मुद्दा है (v1.0 कभी आना वाला है?)। स्पंदन थोड़ा अपरिपक्व है लेकिन अधिक से अधिक कर्षण प्राप्त करने लगता है।

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

आईओएस देवों के लिए बिटकोड बहुत महत्वपूर्ण क्यों है, इसका योग करने के लिए। TVOS या watchOS पर कुछ भी नहीं लिख सकता। कई तृतीय पक्ष ढांचे जो बायनेरिज़ के रूप में वितरित किए गए हैं, उनमें बिटकोड सक्षम है (दर्जनों उदाहरण, मेरे सिर के ऊपर से Google IMA - सबसे लोकप्रिय वीडियो विज्ञापन)। कुछ सुरक्षा ऑडिट के लिए इसकी आवश्यकता होती है। और अंत में, जब भी ऐप्पल कहता है "अगले साल से हम पूरी तरह से एम्बेडेड बिटकोड के बिना ऐप्स स्वीकार नहीं करते हैं", हर किसी को एक टिकिंग टाइमर मिलता है।

अब मुझे लगता है कि हमें सही काम करने के लिए सिर्फ Apple पर निर्भर रहना होगा

हाँ, ठीक है, यही ऐप्पल कुख्यात है;)
मुझे नहीं पता कि सबसे अच्छा समाधान क्या होगा (अस्थायी रूप से एलएलवीएम 6 में अपग्रेड करना विकल्प नहीं है, है ना?), लेकिन रस्ट आईओएस और मोबाइल क्रॉसप्लेटफॉर्म डेवलपर्स को पूरी तरह से खो रहा है।

इस विस्तृत विवरण @oleksandr-yefremov के लिए आपका बहुत-बहुत धन्यवाद। मैं इस विषय पर थोड़ा पढ़ रहा हूं और मुझे यह दिलचस्प टिप्पणी मिली: https://gist.github.com/yamaya/2924292#gistcomment -2738480

एलएलवीएम का संस्करण एक्सकोड में प्रयुक्त स्विफ्ट के संस्करण से जुड़ा हुआ है। अब तक निम्नलिखित समर्थन लागू किया गया था:

Xcode 8.3  --> swift 3.1 --> llvm 4.0.0
Xcode 9.0  --> swift 4.0 --> llvm 4.0.0
Xcode 9.3  --> swift 4.1 --> llvm 5.0.2
Xcode 10.0 --> swift 4.2 --> llvm 6.0.1

swift-5.0-branch , मैंने देखा कि इसमें LLVM का घोषित संस्करण 7.0.0 : https://github.com/apple/swift-llvm/blob/swift-5.0-branch/ CMakeLists.txt#L25 -L33

मुझे नहीं पता कि यहां और अवरोधक हैं या नहीं, लेकिन मुझे ऐसा लगता है कि हम बिटकोड बायनेरिज़ को आउटपुट करने के लिए रस्ट का उपयोग करने में सक्षम हो सकते हैं।

ऐसा लगता है कि Xcode 10.2 में स्विफ्ट 5.0 शामिल होगा और इसे वास्तव में बहुत जल्द जारी किया जाना चाहिए। लेकिन दूसरी तरफ एलएलवीएम 8.0 अगले हफ्ते रिलीज होने वाली है। Apple द्वारा इसका उपयोग शुरू करने से पहले जंग के अपग्रेड होने की काफी संभावना है।

रस्ट के लिए बिटकोड का ठीक से समर्थन करने के लिए, हमें LLVM के पिन किए गए संस्करण का उपयोग करने के लिए Apple ARM आर्किटेक्चर बिल्ड ऑफ़ रस्ट की आवश्यकता होगी (शायद https://github.com/apple/swift-llvm रेपो से - Apple उपयोग नहीं करता है एलएलवीएम पैकेज जारी किया लेकिन उनकी अपनी शाखाएं)। एलएलवीएम का वह संस्करण केवल तभी अपडेट किया जाएगा जब ऐप्पल एक अलग एलएलवीएम संस्करण के साथ एक्सकोड का एक नया अंतिम संस्करण जारी करेगा।

बीटीडब्ल्यू, ऐसा लगता है कि नवीनतम जंग एलएलवीएम 6 के साथ निर्माण योग्य है ताकि निश्चित रूप से करने योग्य प्रतीत हो: https://github.com/rust-lang/rust/blob/master/src/bootstrap/native.rs#L282
एलएलवीएम के आवश्यक संस्करण (एलएलवीएम 6 के लिए एक: https://github.com/rust-lang/rust/issues/55842) को अपडेट करने के लिए कोई समस्या बनने पर आपको निश्चित रूप से लोगों की आवश्यकता होगी।

@vincentisambart Rust 5 महीने IIRC के लिए रात के निर्माण के लिए पहले से ही LLVM 8 का उपयोग कर रहा है।
यदि आप इसे स्वयं बनाना चाहते हैं तो LLVM 6 न्यूनतम समर्थित संस्करण है और इसका CI पर परीक्षण किया गया है: https://github.com/rust-lang/rust/blob/706e67b0a0143d651eb03f2fa2c30645899e81ff/src/ci/docker/x86_64-gnu-llvm-6.0 /डॉकरफाइल

अब मुझे लगता है कि हमें सही काम करने के लिए सिर्फ Apple पर निर्भर रहना होगा

मैं कुछ समय के लिए इन पंक्तियों के साथ कुछ का पीछा कर रहा हूं (और अब बाहर निकल चुका हूं) और मैं प्लेटफॉर्म-वार अनुमान लगा रहा हूं कि ऐप्पल के लिए ऐसा करने का कोई मतलब नहीं है, क्योंकि:

• स्विफ्ट कई तरीकों से रस्ट बनना चाहती है (एक के लिए स्वामित्व घोषणापत्र देखें) लेकिन बहुत पीछे है
• Apple को अपनी मुख्य प्लेटफ़ॉर्म भाषा बने रहने और बने रहने के लिए स्विफ्ट की आवश्यकता है, इसलिए उनके लिए अपने प्लेटफ़ॉर्म पर किसी अन्य बड़ी भाषा को सुविधाजनक बनाने और न ही उनके लिए अन्य वातावरणों में स्विफ्ट को आगे बढ़ाने का कोई मतलब नहीं है।

5 महीने IIRC के लिए रस्ट पहले से ही LLVM 8 का उपयोग रात के निर्माण के लिए कर रहा है।

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

यदि आप इसे स्वयं बनाना चाहते हैं तो LLVM 6 न्यूनतम समर्थित संस्करण है और इसका CI पर परीक्षण किया गया है

फिर एलएलवीएम 6 (या https://github.com/apple/swift-llvm/releases/tag/swift-4.2.2-RELEASE जैसे बेहतर कुछ के साथ रस्ट का आधिकारिक *-apple-ios बिल्ड बनाया जाए - अगर जो काम करता है) बिटकोड समस्याओं को ठीक कर सकता है।

मुझे लगता है कि रस्ट वर्तमान में https://github.com/rust-lang/rust/issues/46819 के विलय के बाद दो एलएलवीएम बैकएंड (एम्सस्क्रिप्टन और मानक) के साथ जहाज करता है
हालाँकि #46819 में बिटकोड के लिए ios LLVM बैकएंड का उल्लेख है, लेकिन इसे लागू नहीं किया गया।

इसे पूरी तरह से पटरी से उतारने के लिए नहीं, लेकिन क्या ऐसे मामलों के लिए सी को ट्रांसपिलिंग सक्षम करने का प्रयास करने के लिए समग्र रूप से अधिक समझदारी नहीं होगी? यह संभावना नहीं है कि रस्ट ऐप्पल की ओर से बिटकोड आवश्यकताओं के साथ अद्यतित रह पाएगा।

यहां तक ​​​​कि अगर वास्तव में असंगति के संभावित स्रोत हैं, तो यह उन परीक्षणों के लिए द्वार खोलता है जहां हम जंग के संगत पुराने संस्करण के साथ संकलन करने का प्रयास कर सकते हैं, जो कि ऐप्पल के लिए सही एलएलवीएम संस्करण को एम्बेड करता है।

एक पूर्ण क्रॉस-प्लेटफ़ॉर्म दृष्टिकोण में, यह अभी भी स्पष्ट रूप से काफी अवरुद्ध है क्योंकि हमें नवीनतम सुधारों से लाभ उठाने के लिए और पुराने से संकलन करने में सक्षम होने के लिए जंग के नवीनतम संस्करण से एक ही स्रोत कोड को संकलित करने में सक्षम होने की आवश्यकता होगी। रस्ट का संस्करण, विशेष रूप से Apple पारिस्थितिकी तंत्र के लिए बिटकोड संगत बायनेरिज़ को आउटपुट करने के लिए। यह करने योग्य है, लेकिन उपयुक्त नहीं है।

मैं अभी भी इसे होते हुए देखने के लिए बहुत उत्साहित हूं क्योंकि यह कम से कम अधिक लोगों के लिए इसका परीक्षण करने के लिए दरवाजे खोलेगा और हम सभी को सही दिशा में आगे बढ़ाएगा।

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

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

भले ही बिटकोड ने काम किया हो, फिर भी रस्ट वॉचओएस या टीवीओएस को वैसे भी लक्षित नहीं कर सकता है?

यह संभावना नहीं है कि रस्ट ऐप्पल की ओर से बिटकोड आवश्यकताओं के साथ अद्यतित रह पाएगा।

यहाँ समस्या यह है कि रस्ट का LLVM बहुत नया है , न कि यह बहुत पुराना है । मैं सहमत हूं कि हमारे यहां एक बेहतर संगतता कहानी होनी चाहिए।

rustc के लिए अनेक LLVMs का समर्थन करना कितना व्यवहार्य है?

संबंधित: टीवीओएस और वॉचओएस (और सिम्युलेटर) लक्ष्यों का समर्थन करें

यह पहले से ही कई एलएलवीएम का उपयोग करता है। एम्सस्क्रिप्टन लक्ष्यों के लिए यह एम्सस्क्रिप्टन के एलएलवीएम फोर्क का उपयोग करता है जो एलएलवीएम 6 एटीएम पर है।

यहाँ समस्या यह है कि रस्ट का LLVM _too new_ है, ऐसा नहीं है कि यह _too old_ है। मैं सहमत हूं कि हमारे यहां एक बेहतर संगतता कहानी होनी चाहिए।

मुद्दा यह नहीं है कि यह बहुत पुराना है या बहुत नया है, लेकिन भले ही जंग LLVM संस्करण से मेल खाता हो, किसी भी iOS रिलीज़ पर यह फिर से टूट सकता है। ऐप्पल (जहां तक ​​​​मुझे पता है) बिटकोड के संबंध में किसी भी तरह की स्थिरता की गारंटी नहीं देता है।

मुद्दा यह नहीं है कि यह बहुत पुराना है या बहुत नया है, लेकिन भले ही जंग LLVM संस्करण से मेल खाता हो, किसी भी iOS रिलीज़ पर यह फिर से टूट सकता है। ऐप्पल (जहां तक ​​​​मुझे पता है) बिटकोड के संबंध में किसी भी तरह की स्थिरता की गारंटी नहीं देता है।

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

मैं यह नहीं कहूंगा कि इसके लिए योजना बनाना विशेष रूप से कठिन है।

चूंकि बिटकोड के बारे में बिल्कुल कोई गारंटी नहीं है जो कि योजना बनाने के लिए बहुत कठिन हो सकता है। कल्पना कीजिए कि वे एक रिलीज से दूसरे रिलीज में अपने स्वयं के बिटकोड प्रारूप का उपयोग करने का निर्णय लेंगे जो एलएलवीएम के ओपन सोर्स रिलीज में समाप्त नहीं होता है।

चूंकि बिटकोड के बारे में बिल्कुल कोई गारंटी नहीं है जो कि योजना बनाने के लिए बहुत कठिन हो सकता है। कल्पना कीजिए कि वे एक रिलीज से दूसरे रिलीज में अपने स्वयं के बिटकोड प्रारूप का उपयोग करने का निर्णय लेंगे जो एलएलवीएम के ओपन सोर्स रिलीज में समाप्त नहीं होता है।

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

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

इसलिए, उनके लिए बिना किसी को देखे या परवाह किए अचानक उस प्रारूप को बदलने के लिए उन्हें अपनी स्विफ्ट और एलएलवीएम रिपॉजिटरी दोनों को निजी लेने की आवश्यकता होगी, है ना? यह निश्चित रूप से संभव है, लेकिन मुझे इसकी बहुत संभावना नहीं है।

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

चूंकि बिटकोड के बारे में बिल्कुल कोई गारंटी नहीं है जो कि योजना बनाने के लिए बहुत कठिन हो सकता है। कल्पना कीजिए कि वे एक रिलीज से दूसरे रिलीज में अपने स्वयं के बिटकोड प्रारूप का उपयोग करने का निर्णय लेंगे जो एलएलवीएम के ओपन सोर्स रिलीज में समाप्त नहीं होता है।

Apple जून की शुरुआत में Xcode बीटा और सितंबर में अंतिम संस्करण जारी करता है। 6-9 महीनों के बाद यह ऐपस्टोर में पुराने Xcode संस्करणों के साथ निर्मित ऐप्स को स्वीकार करना बंद कर देता है।

मुझे लगता है कि उस समय के दौरान बिटकोड परिवर्तन तैयार करने के लिए पर्याप्त समय है।

बस एक्सकोड 10.2 बीटा 3 (जिसमें स्विफ्ट 5 डब्ल्यू/एलएलवीएम 7 शामिल है) के साथ परीक्षण किया गया और मैं एम्बेडेड बिटकोड के साथ हाल ही में एक जंग के साथ लिंक कर सकता था। जाहिर है, यह केवल iOS लक्ष्यों के साथ काम करता है, क्योंकि रस्ट में watchOS/tvOS लक्ष्य नहीं होते हैं ।

मैं इस बात से भी सहमत हूं कि बिटकोड संगतता बनाए रखने के लिए रस्ट को Apple से संबंधित सभी लक्ष्यों के लिए Apple LLVM कांटा का उपयोग करने में सक्षम होना चाहिए।

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

प्रस्तावित संगतता से निपटने का गैर-गारंटीकृत तरीका स्वीकार्य रूप से मुश्किल है, लेकिन मुझे लगता है कि मोबाइल प्लेटफॉर्म अंततः टियर 1 प्लेटफॉर्म बन जाना चाहिए, खासकर उन मामलों के लिए जहां आपने सी ++ का उपयोग किया होगा, जैसे वीडियो गेम विकास के लिए। साथ ही, आप Apple TV के लिए Rust के साथ गेम भी विकसित कर सकते हैं।

मुझे उम्मीद है कि कंपाइलर टीम द्वारा आधिकारिक तौर पर स्वीकृत दृष्टिकोण किसी को इस पर काम करने के लिए प्रोत्साहित करेगा, लेकिन मुझे लगता है कि @brson द्वारा पहले की टिप्पणी झिझक को

हम LLVM के कई संस्करणों के बीच सफलतापूर्वक संगतता बनाए रखते हैं। जब तक Apple और हमारा बहुत दूर नहीं बहते, यह संभव होना चाहिए, लेकिन इस तरह के बड़े टूटने का जोखिम हमेशा होता है कि विभाजन को पार नहीं किया जा सकता है

या हो सकता है कि भविष्य में बिटकोड स्थिर हो जाए और हम सब भूल जाएंगे कि यह बहस कभी हुई 🙏

मैं अब अपनी टोपी खाऊंगा

जिसमें मैंने कहा:

यह विचार कि ऐप्पल एलएलवीएम या उनके बिटकोड प्रारूप को बंद करने वाला है, इसकी संभावना बहुत कम है

जो ज्यादातर @mitsuhiko द्वारा व्यक्त किए गए अविश्वास के जवाब में था:

कल्पना कीजिए कि वे एक रिलीज से दूसरे रिलीज में अपने स्वयं के बिटकोड प्रारूप का उपयोग करने का निर्णय लेंगे जो एलएलवीएम के ओपन सोर्स रिलीज में समाप्त नहीं होता है।

लेकिन अगर आप #48833 अंक को देखें , तो निश्चित रूप से एक मिसाल है। जैसा कि @comex ने पहले लिखा था:

ऐसे मामले हैं जहां एलएलवीएम ट्रंक से पहले एक्सकोड के एलएलवीएम में विशेषताएं दिखाई देती हैं - जैसे कि संपूर्ण आर्म 64 पोर्ट, जब इसे मूल रूप से विकसित किया गया था, क्योंकि ऐप्पल इसे गुप्त रखना चाहता था कि वे आर्म 64 डिवाइस शिप करने की योजना बना रहे थे

और उसी मुद्दे से @michaeleiselsc की कहानी:

जिस ऐप पर मैं काम कर रहा था, वह दिसंबर 2016 में रैंडम रीस्टार्ट से बुरी तरह प्रभावित हुआ, और यह एक विशिष्ट समस्या के कारण होता है जिसे ओपन-सोर्स एलएलवीएम ने केवल दिसंबर 2017 में तय किया था। जब हम दिसंबर 2016 में ओपन-सोर्स एलएलवीएम से ऐप्पल के एलएलवीएम में चले गए, तो समस्या तय था

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

मुझे अभी भी लगता है कि ऐप्पल के एलएलवीएम का उपयोग करना समर्थित होना चाहिए, लेकिन दस्तावेज़ीकरण में स्पष्ट चेतावनियां होनी चाहिए कि कोई गारंटी नहीं है कि चीजें काम करती रहेंगी (ए टियर 1.5 या कुछ)।

कोटलिन / मूल निवासी। JetBrains मोबाइल प्लेटफ़ॉर्म को प्राथमिकता के रूप में मान रहा है और हालाँकि इसमें उन्हें कुछ समय लगा और यह केवल बिटकोड मार्कर है (अभी तक पूर्ण बिटकोड नहीं है), इसके साथ काम करना शुरू करने के लिए पर्याप्त है - JetBrains/kotlin-native#1564 और JetBrains/kotlin-native# देखें। 1202 (टिप्पणी)

इसे इंगित करने के लिए धन्यवाद @ oleksandr-yefremov! मैं थोड़ा आगे खोदा और kotlin / देशी दृष्टिकोण को दोहराने के लिए सक्षम था golang में । मेरा मानना ​​है कि आप लोगों को भी ऐसा करने में सक्षम होना चाहिए, जो बिटकोड-सक्षम आईओएस/टीवीओएस/वॉचओएस ऐप्स में जरूरी बिटकोड उत्सर्जित किए बिना जंग का उपयोग करने की अनुमति देगा।

क्या बिटकोड अब काम करता है? क्या किसी ने कोशिश की?

@volodg मैं एक जंग नौसिखिया हूँ। हालांकि, मैं रात में नवीनतम जंग के साथ इस ट्यूटोरियल के माध्यम से भाग गया ( rustc 1.37.0-nightly (088b98730 2019-07-03) लिखने के समय) और यह काम नहीं किया।

ऐसा लगता है जैसे मार्कर हैं ..

$ otool -arch arm64 -l librust.a  | grep bitcode
  sectname __bitcode
...

लेकिन आईओएस डिवाइस के लिए निर्माण करते समय मुझे निम्न त्रुटि मिलती है (सिम्युलेटर काम करता है):

ld: '/Users/amrox/Documents/Projects/rust-ios-example/hello-rust/libs/librust.a(rust-e6011ffb55678675.rust.8yq9vjk7-cgu.3.rcgu.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

उतना ही मुझे मिला है।

मैं rustc nightly-2019-09-05 aarch64-apple-ios and rustflags = "-C lto -Z embed-bitcode" staticlib को clang-1100.0.33.5 (Xcode 11 beta 7) and -fembed-bitcode ऐप से जोड़ने में सफल रहा। स्रोत कोड https://github.com/saturday06/rust-ios-bitcode-test है ।

• क्या आप जानते हैं कि __cmdline अनुभाग आवश्यक है या नहीं?

दो साल बाद मैं इसका उत्तर दे सकता हूं - भौतिक उपकरणों पर तैनात करने या एक्सकोड अभिलेखागार बनाने के लिए एक खाली सीएमडीलाइन ठीक है, हालांकि ऐप स्टोर सबमिशन के लिए ऐप्पल क्लैंग कमांड लाइन का सत्यापन करता है। मैंने इस पीआर में एक लंबा विवरण दिया है, जिसमें इसे काम करने के लिए एक हैकी पैच शामिल है: https://github.com/getditto/rust-bitcode/pull/7

मैं इसे किसी भी तरह से अपस्ट्रीम करना चाहता हूं लेकिन विकल्प आकर्षक नहीं हैं। आईओएस को लक्षित करते समय क्या हम कुछ क्लैंग विकल्प बनाते हैं? यदि Apple अपने सत्यापन नियमों में परिवर्तन करता है तो क्या हम झूठ बोलने का तरीका चुनने के लिए एक एनवर प्रदान करते हैं? अगर यहां कोई उचित विकल्प है तो मुझे बदलाव करने में खुशी होगी।

-सेम्बेड-बिटकोड = नहीं आईओएस लक्ष्य के लिए काम नहीं करता है। फ़ाइल में अभी भी बिटकोड अनुभाग हैं
बिना बिटकोड के कैसे निर्माण करें?