# 36120 में एक PoC भी देखें।

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

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

LLVM 4.0 में अपग्रेड करने के लिए ट्रैकिंग समस्या https://github.com/rust-lang/rust/issues/37609 है ।

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

@binarycrusader lld का उपयोग करने का एक कारण सोलारिस के लिए निर्माण , सोलारिस पर नहीं।

PR rust-lang/rust#40018 rustc में एक -Z linker-flavor फ्लैग जोड़ता है जिससे LLD को लिंकर के रूप में उपयोग करना संभव हो जाता है। वह पीआर एलएलडी को जंग में एम्बेड नहीं करता है, लेकिन इसके साथ पेड़ के प्रयोग की अनुमति देता है।

@binarycrusader ^ जो सीधे जीसीसी के बजाय सोलारिस 'एलडी का उपयोग करने के आपके प्रयोग में मदद कर सकता है।

ऐसा प्रतीत होता है कि अब हम LLVM 4.0 पर चल रहे हैं। @japaric , क्या इसका मतलब यह है कि लिंकर-स्वाद ध्वज का उपयोग अब सिस्टम लिंकर के साथ एलएलडी की तुलना और इसके विपरीत करने के लिए आसानी से किया जा सकता है?

@bstree #40018 कुछ हफ़्ते पहले उतरा। चूंकि वह उतरा एक लिंकर के रूप में बाहरी एलएलडी बाइनरी का उपयोग करने के लिए -Z linker-flavor=ld -C linker=ld.lld का उपयोग करने में सक्षम है। ध्यान दें कि, gcc के विपरीत, LLD को यह नहीं पता होता है कि सिस्टम लाइब्रेरी कहां हैं, -C link-args='-L ...' यदि आप किसी सिस्टम लाइब्रेरी से लिंक कर रहे हैं तो आपको

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

@japaric एम्बेडिंग ( -lc -lpthread crt0.o जैसी चीज़ों के विरुद्ध सीधे rustc में क्या तर्क हैं? आखिरकार, टूलचैन के कुछ घटकों को उन्हें एम्बेड करना पड़ता है क्योंकि हमारे पास प्लेटफॉर्म के पालन के लिए कोई मानक नहीं है, और बिनुटिल्स इस ज्ञान का एक अच्छा सुनहरा स्रोत नहीं है।

एकमात्र कमी जो मैं सोच सकता हूं वह वह स्थिति है जहां एक ही ट्रिपल के सिस्टम के विभिन्न स्वादों पर अलग-अलग खोज पथ होंगे (जो संभवतः लिनक्स/ग्लिबैक ट्रिपल के लिए विशिष्ट होंगे, और विशेष रूप से मल्टीलिब वाले प्लेटफॉर्म पर खराब होंगे)। उस स्थिति में, मेरा मानना ​​​​है कि क्लैंग ओएस नाम और हार्डकोड ओएस-विशिष्ट सम्मेलनों को देखता है, जो खराब लगता है लेकिन शायद अपरिहार्य है यदि कोई किसी भी लिनक्स पर चलने वाली एक बाइनरी वितरित करना चाहता है (और सिस्टम लिंकर की आवश्यकता नहीं है)।

@ retep998 मैंने कुछ महीने पहले lld पर एक संक्षिप्त नज़र

उम्मीद है कि मैं गलत हूँ।

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

एर, बेंचमार्क लिंक करना भूल गए: https://lld.llvm.org/#performance

(प्रासंगिक आज के बाद से LLVM 5.0 अभी जारी किया गया है।)

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

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

@bstree I-slow खराब रनटाइम परफॉर्मेंस के लिए है, I-compiltime पिछली बार जब मैंने चेक किया था तो कंपाइलर परफ के लिए है

लिनक्स से विंडोज़ तक क्रॉस लिंकिंग के अस्पष्ट विषय में रुचि रखने वाले किसी भी व्यक्ति के लिए अच्छी खबर है। मैंने पहले कहा था कि एलएलडी के साथ यह संभव नहीं था, लेकिन यह केवल एलएलडी के एलडी स्वाद के लिए सच है। यह lld के link.exe फ्लेवर (lld-link) के लिए संभव है।

विशेष रूप से जंग के लिए हम इसे आज कुछ कोड परिवर्तनों के साथ कर सकते हैं।

1. हमें mingw-w64 के CRT के एक बहुत छोटे उपसमुच्चय को .o ऑब्जेक्ट फ़ाइलों में संकलित करने की आवश्यकता है। अर्थात् कुछ थ्रेड लोकल स्टोरेज init. हमें chkstk की भी आवश्यकता है।

2. lld को MinGW की सामान्य आयात लाइब्रेरी पसंद नहीं है। इसके बजाय हमें lld-link या llvm-dlltool का उपयोग करके .def फ़ाइलों को .lib फ़ाइलों में स्वयं बनाने की आवश्यकता है

3. IMPORT_NAME_NOPREFIX को पसंद करने के लिए lld को संशोधित करें
   IMPORT_NAME_UNDECORATE, क्योंकि चरण 2 के साथ भी .libs परिपूर्ण नहीं हैं

4. TYPE_INFO_VTABLE को ptr::null() से बदलने के लिए Rust के seh.rs को संशोधित करें। आवश्यक है क्योंकि प्रतीक ??_7type_info@@6B@ को MinGW में परिभाषित नहीं किया गया है। फिर रस्ट बनाएं और इंस्टॉल करें।

5. कस्टम रैपर स्क्रिप्ट को लिंकर के रूप में निर्दिष्ट करने के लिए .cargo/config का उपयोग करें।

6. हमारी रैपर लिंकर स्क्रिप्ट को एलएलडी-लिंक को ज्यादातर उन मापदंडों का उपयोग करना चाहिए जो इसे पारित किया गया है। हालाँकि हमें कुछ बदलाव करने होंगे:

   a) फ़ाइल नाम आवरण को ठीक करें जैसे AdvAPI32.Lib को advapi32.lib में बदलें

   बी) .def फ़ाइल को संशोधित करें जंग एक अतिरिक्त अंडरस्कोर के साथ उपसर्ग प्रतीकों को उत्पन्न करता है

   ग) प्रवेश बिंदु (/ प्रविष्टि) को ओवरराइड करें। शायद एक नाम मैंगलिंग समस्या के कारण आवश्यक है।

   d) चरण 1 में आपके द्वारा संकलित mingw-crt ऑब्जेक्ट फ़ाइलों को जोड़ें

7. xargo --target=i686-pc-windows-msvc . का उपयोग करके अपना रस्ट प्रोजेक्ट बनाएं

उपरोक्त चरणों को करने से मुझे रस्ट कोड को संकलित करने की अनुमति मिलती है। मैं रस्ट के एसईएच-आधारित अनइंडिंग का उपयोग करके भी घबरा सकता हूं और दहशत पकड़ सकता हूं।

@iainnicol आप मिनजीडब्ल्यू बिट्स के साथ एमएसवीसी लक्ष्य को मिला रहे हैं, यही कारण है कि आपको उन सभी अजीब संशोधनों को करना है। यदि आप मौजूदा वीसी ++ इंस्टॉलेशन से पुस्तकालयों की प्रतिलिपि बनाते हैं तो आप सामान्य रूप से उन सभी संशोधनों या किसी भी मिनीजीडब्ल्यू बिट्स के बिना एलएलडी-लिंक का उपयोग कर सकते हैं।

लेकिन मैं मौजूदा वीसी ++ इंस्टॉलेशन का उपयोग नहीं करना चाहता हूं। जंक को डाउनलोड करने और इंस्टॉल करने जैसे आठ घंटे खर्च किए बिना इसे प्राप्त करने का कोई तरीका भी नहीं है, पुनर्वितरण के लिए बहुत कम।

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

स्टैंडअलोन बिल्ड टूल बहुत हल्के-वजन वाले होते हैं

मुझे एहसास नहीं हुआ कि माइक्रोसॉफ्ट उनको वितरित करता है। क्या आप उनसे लिंक कर सकते हैं? क्या वास्तव में इसे चलाए बिना इंस्टॉलेशन आर्काइव को निकालने का कोई उचित तरीका है यानी यह एक एमएसआई या कुछ इसी तरह का है?

ये रहे: http://landinghub.visualstudio.com/visual-cpp-build-tools

2015 और 2017 दोनों संस्करण पूर्व-निर्धारित हैं, लेकिन आप इसके द्वारा जो चाहते हैं उसे देने के लिए 2017 के एक्सई को समझाने में सक्षम हो सकते हैं: https://docs.microsoft.com/en-us/visualstudio/install/install-vs- असंगत-गुणवत्ता-नेटवर्क

अगर हम वास्तव में विंडोज के लिए यह अधिकार करना चाहते हैं, तो हमें सबसे पहले https://github.com/rust-lang/rust/issues/30027 की आवश्यकता होगी ताकि विंडोज एसडीके या मिनजीडब्ल्यू के आयात पुस्तकालयों की आवश्यकता समाप्त हो सके। फिर हमारे पास CRT बिट्स को अपने शुद्ध रस्ट संस्करणों (गणित/मेमोरी फ़ंक्शंस, एंट्री पॉइंट, कुछ अन्य रनटाइम बिट्स रस्ट की ज़रूरतों) के साथ बदलना है और हमारे पास पूरी तरह से स्व-निहित रस्ट टूलचेन होगा जो कर सकता है विंडोज बायनेरिज़ बनाएं! इसका नकारात्मक पक्ष यह है कि आप C/C++ कोड को स्थिर रूप से लिंक करने में सक्षम नहीं होंगे क्योंकि यह MinGW या VC++ से उपयुक्त CRT में लिंक करने पर बहुत अधिक निर्भर करता है। बेशक, रस्ट का पूरा बिंदु रस्ट में सब कुछ फिर से लिखना है, इसलिए यह वास्तव में कोई बड़ी समस्या नहीं है।

लिनक्स से विंडोज़ तक क्रॉस लिंकिंग के अस्पष्ट विषय में रुचि रखने वाले किसी भी व्यक्ति के लिए अच्छी खबर है। मैंने पहले कहा था कि एलएलडी के साथ यह संभव नहीं था, लेकिन यह केवल एलएलडी के एलडी स्वाद के लिए सच है। यह lld के link.exe फ्लेवर (lld-link) के लिए संभव है।

ऐसा लगता है कि यह अब एलडी स्वाद के साथ भी संभव होना चाहिए: https://reviews.llvm.org/rL312926

नया lld का MinGW-संगत ड्राइवर lld-link लिंकर के लिए एक आवरण है। यह आंतरिक रूप से यूनिक्स-ईश विकल्पों का विंडोज-ईश विकल्पों में अनुवाद करता है और फिर एलएलडी-लिंक के प्रवेश बिंदु को कॉल करता है। मुझे यकीन नहीं है कि आप लोग इसका उपयोग करना चाहते हैं क्योंकि (सिवाय इसके कि रैपर ड्राइवर अधूरा है और उपयोग के लिए तैयार नहीं है) यह चीजों को आसान नहीं बनाता है जब तक कि आपके पास पहले से ही MinGW के लिए Makefiles न हो।

मेरे पास क्रॉस-संकलन के बारे में आप लोगों के लिए एक (शायद मूर्खतापूर्ण) प्रश्न है। विंडोज़ पर, सभी dllimport'ed प्रतीकों में डीएलएल नाम होते हैं जिनसे उन्हें आयात किया जाता है। यदि आपके पास कोई MSVC लाइब्रेरी फ़ाइलें नहीं हैं, तो आप कैसे जानते हैं कि कौन-सी फ़ाइलें dllimport'ed प्रतीकों से आयात की जाती हैं?

मेरे पास क्रॉस-संकलन के बारे में आप लोगों के लिए एक (शायद मूर्खतापूर्ण) प्रश्न है। विंडोज़ पर, सभी dllimport'ed प्रतीकों में डीएलएल नाम होते हैं जिनसे उन्हें आयात किया जाता है। यदि आपके पास कोई MSVC लाइब्रेरी फ़ाइलें नहीं हैं, तो आप कैसे जानते हैं कि कौन-सी फ़ाइलें dllimport'ed प्रतीकों से आयात की जाती हैं?

यदि आपके पास कोई आयात पुस्तकालय नहीं है, तो आपको या तो आयात पुस्तकालय बनाना होगा या https://github.com/rust-lang/rust/issues/30027 लागू करना होगा ताकि winapi पूरी मेहनत कर सकें यह निर्दिष्ट करने का कार्य कि प्रत्येक प्रतीक कौन सा डीएलएल ज़ेननेस जैसे ऑर्डिनल्स के साथ आता है। डीएलएल में प्रतीकों/ऑर्डिनल्स के लिंक समय पर प्रतीकों के मानचित्रण को निर्दिष्ट करने के लिए कुछ है, चाहे वह आपके कोड में आयात पुस्तकालय या एनोटेशन हो।

https://reviews.llvm.org/rL311734 में खींचने के बाद मैं macOS पर lld का उपयोग करके rustc को बूटस्ट्रैप करने में लगभग सक्षम हूं। ऐसा लगता है कि dylib मेटाडेटा के साथ कोई समस्या है, जिसकी मुझे अभी भी जांच करने की आवश्यकता है।

मेरे पास एक शाखा है जो https://github.com/rust-lang/rust/pull/36120 को पुनर्जीवित करती है https://github.com/rust-lang/rust/issues/43370 पर अवरुद्ध है

@tamird : #43370 बंद कर दिया गया है।

एलएलडी को https://github.com/rust-lang/rust/pull/48125 में जोड़ा गया है और अब टियर 1 प्लेटफॉर्म (मैक, लिनक्स, विंडोज़) के साथ शिपिंग कर रहा है। आप प्रत्येक प्लेटफ़ॉर्म के लिए -Z linker-flavor साथ इसका परीक्षण कर सकते हैं, हालांकि यह डिफ़ॉल्ट रूप से अधिकांश प्लेटफ़ॉर्म के लिए काम करने की संभावना नहीं है। हालाँकि, यह MSVC पर डिफ़ॉल्ट रूप से काम करता है। उदाहरण के लिए:

$ RUSTFLAGS='-Z linker-flavor=lld-link' cargo build

कार्गो के अपने लिंक समय को 2.5 से घटाकर 1.5 कर दिया, एक अच्छा सुधार!

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

विशेष रूप से वृद्धिशील संकलन के साथ, लिंकिंग प्रदर्शन पहले से कहीं अधिक महत्वपूर्ण होने जा रहा है।

यह शर्म की बात है कि प्रदर्शन अभी भी हमारे लिए इतना महत्वपूर्ण नहीं है कि हम इसका समर्थन करने वाले प्लेटफार्मों पर वृद्धिशील लिंकिंग को सक्षम करने जैसी चीजें करें। https://github.com/rust-lang/rust/issues/37543

@bstree मुझे लगता है कि वे अगले चरण हैं, इसे अन्य प्लेटफॉर्म पर काम कर रहे हैं :)

मुझे यकीन नहीं है कि इसमें क्या शामिल है, लेकिन यह पहले से ही एमएसवीसी पर काम करता है, मुझे लगता है कि यह मिनजीडब्ल्यू/लिनक्स पर काम करने से बहुत दूर है, और हम ओएसएक्स पर बहुत करीब हैं। क्रॉस-आर्किटेक्चर समर्थन के लिए, मुझे भी यकीन नहीं है। मुझे उम्मीद नहीं है कि हम निकट भविष्य में wasm प्लेटफॉर्म के अलावा किसी और चीज के लिए इसे "स्थिर" करेंगे।

@alexcrichton क्या मैं पूछ सकता हूं कि आप "स्थिरीकरण" कैसे निर्दिष्ट करेंगे? अन्य प्रमुख प्लेटफॉर्म रस्ट सपोर्ट के लिए एलएलडी के साथ लिंकिंग को "स्थिर" करना क्यों संभव नहीं होगा? (उदाहरण के लिए macOS के लिए linux से निष्पादन योग्य क्रॉस-कंपाइलिंग)।

अभी, यह क्रॉस-कंपाइल करने के लिए एक ऐसा दर्द है, उदाहरण के लिए लिनक्स से macOS (x86_64-apple-darwin) के लिए एक निष्पादन योग्य को क्रॉस-कंपाइल करने के लिए आवश्यक कार्य के लिए गैर-तुच्छ चरणों की आवश्यकता होती है जैसे कि xcode sdk प्राप्त करना और संपूर्ण टूलचेन का निर्माण करना।

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

उदाहरण के लिए linux से macOS (x86_64-apple-darwin) के लिए एक निष्पादन योग्य को क्रॉस-कंपाइल करने के लिए आवश्यक कार्य के लिए गैर-तुच्छ चरणों की आवश्यकता होती है जैसे कि xcode sdk प्राप्त करना और संपूर्ण टूलचेन का निर्माण करना।

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

एलएलडी के बारे में वास्तव में अच्छी बात यह है कि अब रात में बिल्ट-इन किया जा रहा है कि आप RUSTFLAGS='-Z linker-flavor=ld.lld' cargo build --target x86_64-unknown-linux-musl साथ विंडोज से लिनक्स तक शुद्ध रस्ट परियोजनाओं को आसानी से क्रॉस-कंपाइल कर सकते हैं। लिनक्स मशीनों के लिए छोटे उपकरण लिखने के लिए बढ़िया, आप बस रस्ट को स्थापित नहीं कर सकते।

मुझे उम्मीद नहीं है कि हम निकट भविष्य में wasm प्लेटफॉर्म के अलावा किसी और चीज के लिए इसे "स्थिर" करेंगे।

जैसे @rkarp ने कहा, कंटेनरीकृत लिनक्स वर्कलोड का समर्थन करने के लिए एक बहुत ही सामान्य उपयोग का मामला x86_64-अज्ञात-लिनक्स-मुसल (और अंततः स्टीड) को लक्षित कर रहा है। यह उन चीजों में से एक है जो गो वास्तव में अच्छा करता है और जहां हम रस्ट के बहुत करीब लगते हैं जो इसी तरह करने में सक्षम है। वास्तविक उपयोग के संदर्भ में, मैं शर्त लगाता हूं कि x86_64-अज्ञात-लिनक्स-मुसल के लिए एलएलडी वास्तव में wasm की तुलना में अधिक व्यापक रूप से उपयोग किया जाएगा।

आम तौर पर, जब क्रॉस-बिल्डिंग की बात आती है, तो मुझे नहीं लगता कि "इसे सभी मेजबानों और/या सभी लक्ष्यों के लिए काम करना चाहिए" दृष्टिकोण समझ में आता है। मुझे लगता है कि लक्ष्य-दर-लक्ष्य के आधार पर इसे स्थिर करना समझ में आता है क्योंकि लक्ष्य काम करना शुरू कर देते हैं।

विशेष रूप से, मैं x86_64-अज्ञात-लिनक्स-मुसल लक्ष्य के लिए एलएलडी प्राप्त करने के प्रयास में मदद करना पसंद करूंगा जो ASAP को स्थिर कर देगा।

मेरे प्रोजेक्ट में 37 क्रेट हैं, और बिल्ड लिंक लगभग 70 बायनेरिज़ (बहुत सारे परीक्षण) हैं। अवैज्ञानिक रूप से (नेत्रगोलक top ) निर्माण समय का कम से कम आधा हम केवल एलडी चला रहे हैं। मुझे उम्मीद है कि एलएलडी का उपयोग करने से हमारे निर्माण में काफी तेजी आएगी। हम स्थिर जंग पर हैं और मैं अभी तक काम करने के लिए lld 6.0 प्राप्त करने में कामयाब नहीं हुआ हूं।

@briansmith क्या आपने मस्ल और अपने उपयोग के मामले के लिए LLD का परीक्षण किया है? सिद्धांत रूप में आपको इसका परीक्षण करने के लिए केवल -Z linker-flavor=ld.lld , और यदि यह काम प्रशंसनीय लगता है तो हम डिफ़ॉल्ट स्विच कर सकते हैं!

@rocallahan सिर्फ पुष्टि करने के लिए, आप वर्तमान में सोने के लिंकर का उपयोग कर रहे हैं, है ना? (जैसा कि afaik यह मानक बिनुटिल्स लिंकर से तेज़ है)। यदि -Z linker-flavor=ld.lld काम करता है (और तेज़ है) तो हम शायद इसे स्थिर करने की कोशिश कर सकते हैं! वह किस प्लेटफॉर्म पर था?

अवैज्ञानिक रूप से (नेत्रगोलक शीर्ष) निर्माण समय का कम से कम आधा हम केवल एलडी चला रहे हैं।

यह डिबग बिल्ड BTW के लिए है।

आप सभी वर्तमान में गोल्ड लिंकर का उपयोग कर रहे हैं, है ना? (जैसा कि afaik यह मानक बिनुटिल्स लिंकर से तेज़ है)

नहीं, यह फेडोरा सिस्टम लिंकर है, मानक जीएनयू लिंकर।

वह किस प्लेटफॉर्म पर था?

फेडोरा 27, एसएसडी के साथ क्वाड-कोर स्काईलेक लैपटॉप। मुझे कुछ प्रदर्शन संख्याएँ मिलेंगी।

आह ठीक है जानना अच्छा है! लिंकर सुधारों के बजाय डिबग बिल्ड को शायद स्प्लिट ड्वार्फ (https://github.com/rust-lang/rust/issues/34651) से लिंक समय में सबसे अधिक लाभ मिलेगा।

समय की जानकारी के लिए, हालांकि, @rocallahan यदि आपको ld.gold और ld.lld साथ दिमाग का परीक्षण करने का मौका मिलता है?

ज़रूर। मुझे यह भी याद दिलाना चाहिए कि लिनक्स डिबग लिंक समय को तेज करने के लिए अंक # 48762 बहुत कम लटका हुआ फल है। (हम पहले से हैक की गई लिंकर स्क्रिप्ट का उपयोग कर रहे हैं जो निष्पादन योग्य से .debug_pubnames / .debug_pubtypes कम हो जाती है।)

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

@briansmith क्या आपने मस्ल और अपने उपयोग के मामले के लिए LLD का परीक्षण किया है? सिद्धांत रूप में आपको इसका परीक्षण करने के लिए केवल -Z लिंकर-फ्लेवर = ld.lld पास करना होगा, और यदि यह काम प्रशंसनीय लगता है तो हम डिफ़ॉल्ट स्विच कर सकते हैं!

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

लेकिन -Z का उपयोग किए बिना ताकि यह स्थिर बिल्ड में काम करे।

आप RUSTC_BOOTSTRAP=1 RUSTFLAGS="-Z linker-flavor=foo" cargo build कोशिश कर सकते हैं

कृपया बूटस्ट्रैप ध्वज की अनुशंसा न करें? मुझे चिंता है कि अगर पर्याप्त परियोजनाएं इस पर भरोसा करती हैं तो चीजें पूरी तरह से स्थिर हो जाएंगी, पूरे स्थिरता तंत्र के बिंदु को हराकर।

क्षमा करें =/

एक डेटा बिंदु के रूप में, रस्ट रेपो में rustc_trans टोकरा को जोड़ने से मेरी स्थानीय मशीन पर 78s लिंक समय से 1s लिंक समय तक गिर गया।

मेरे प्रदर्शन का परिणाम हमारे टोकरा पदानुक्रम के निचले भाग के पास एक टोकरा में एक सफेद स्थान परिवर्तन करने से होता है। क्वाड कोर स्काईलेक लैपटॉप, 16 जीबी रैम, रस्टसी 1.24.0, एलएलडी 7.0.0, जीएनयू एलडी 2.29-13। हम एक कस्टम लिंकर स्क्रिप्ट का उपयोग करते हैं जो .debug_pubnames और .debug_pubtypes ; लिंकर स्क्रिप्ट मौजूद होने पर LLD काफी भिन्न कोड पथों का उपयोग करता है, जिससे कि चीजें प्रभावित हो सकती हैं।

जीएनयू एलडी:

real    2m39.138s
user    8m18.992s
sys 1m37.513s

एलएलडी:

real    2m19.164s
user    6m4.477s
sys 0m56.858s

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

वास्तविक दुनिया के उदाहरण के लिए #50584 देखें जहां GNU ld से lld में स्विच करने से एक सामान्य "मामूली परिवर्तन और पुनर्निर्माण" कार्यभार 2.5x से अधिक तेजी से निष्पादित होता है।

एर https://github.com/rust-lang/rust/issues/50584#issuecomment -400918647 यहां अधिक उपयुक्त है:

एलएलडी को स्थिर करने के लिए अगला कदम एक ध्वज प्राप्त करना होगा, जैसे -Z लिंकर-फ्लेवर = एलएलडी, सभी लक्ष्यों (विंडोज + मैक + लिनक्स) के लिए काम करना। यह विभिन्न प्लेटफार्मों पर काम करने के लिए जो कुछ भी करने की जरूरत है, वह करेगा।

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

हमने कुछ लक्ष्यों के लिए एलएलडी पर स्विच किया है: https://rust-embedded.github.io/blog/2018-08-2x-psa-cortex-m-breakage/

मैं wasm के लिए भी विश्वास करता हूं?

क्या यह समस्या बाहरी lld बाइनरी से लिंक करने और rustc में निर्मित आंतरिक lld समर्थन से लिंक करने दोनों को कवर करती है? या केवल पूर्व?

क्या यह समस्या बाहरी lld बाइनरी से लिंक करने और rustc में निर्मित आंतरिक lld समर्थन से लिंक करने दोनों को कवर करती है? या केवल पूर्व?

जस्ट एक्सटर्नल lld बाइनरी, IIUC।

@nnethercote क्या आंतरिक लिंकर के उपयोग को ट्रैक करने के लिए कोई अन्य समस्या है, या क्या मुझे इसके लिए एक अलग मुद्दा दर्ज करना चाहिए?

मैंने पहले आंतरिक लिंकर विचार के बारे में नहीं सुना है। मुझे इसके लिए एक पीआर की जानकारी नहीं है।

एलएलवीएम को जोड़ने के लिए एलएलडी का उपयोग करने के लिए https://github.com/rust-lang/rust/pull/57514 जमीन तैयार की।

शायद शुरू में "डिफ़ॉल्ट" और "केवल रात में" के बीच एक मध्य मैदान होना चाहिए, एलएलडी का उपयोग करने का कोई तरीका जैसे हम -Z के साथ कर सकते हैं, लेकिन -Z का उपयोग किए बिना ताकि यह स्थिर बिल्ड में काम कर सके।

https://github.com/rust-lang/rust/pull/56351 ने -C linker-flavor जोड़ा।

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

मेरे लिए, यह मुद्दा सभी लक्ष्यों के लिए एलएलडी को डिफ़ॉल्ट लिंकर के रूप में सक्षम करने के बारे में है। मुझे यह पसंद है क्योंकि एलएलडी बेहद तेज है, और लिंकिंग समय अक्सर संकलन समय का एक महत्वपूर्ण घटक होता है, और संकलन गति एक बारहमासी समस्या है।

एफडब्ल्यूआईडब्ल्यू मैंने बीएमओ में मैकोज़ पर बग दायर किया। जाहिरा तौर पर यह WONTFIX है। टिप्पणियों से ऐसा लगता है कि यह "एलएलडी बेहद तेज है" जितना आसान नहीं है, क्योंकि विभिन्न प्लेटफार्मों पर एलएलडी अलग-अलग कार्यक्रम हैं, और मैकोज़ पर एक रुके हुए विकास से टूट गया है।

@briansmith से सहमत हैं कि अलग-अलग लक्ष्यों के लिए इसकी स्थिति को ट्रैक करने के लिए समर्पित मुद्दों को रखना अच्छा होगा, हालांकि इसे बंद करने के बजाय हम इसे मेटाबग में बदल सकते हैं। अगर कोई है जो इस बारे में अधिक जानता है कि किन लक्ष्यों के लिए शुरुआती मुद्दे हैं, तो कृपया बेझिझक महसूस करें, क्योंकि मैं एलएलडी समर्थन स्थिति से बहुत बाहर हूं।

क्या एलएलडी से लिंक करना कहीं भी प्रलेखित है? मेरे पास (लिनक्स पर) rustc -C linker-flavor=ld.lld hello.rs , लेकिन मुझे भाग्य नहीं है। मैंने सोचा था कि एलएलवीएम की हमारी प्रति के साथ एलएलडी वितरित किया गया था, क्या मैं गलत हूं? मैंने एलएलडी को उपयुक्त के माध्यम से स्थापित करने का भी प्रयास किया है, लेकिन जंग अभी भी रहस्यमय है। एलएलडी को रस्ट कोड के साथ आज़माने के लिए आज कौन से कदम उठाए जाने चाहिए?

@bstree आपको अतिरिक्त रूप से -C linker=rust-lld तर्क पारित करना होगा।

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

$ RUSTFLAGS='-C linker=rust-lld' cargo build
   Compiling rust3 v0.1.0 (/home/carado/tmp/rust3)
error: linking with `rust-lld` failed: exit code: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "-L" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.2ualxzb8lqn4ho3y.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.32vfyq64cfbzv618.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.4rbt3m5y8o8cl09t.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.ben0932xzwyt64v.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.fzsdnygvstiwzxo.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.x0rq6ifodcf11zi.rcgu.o" "-o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.1m259ox4uzrzk583.rcgu.o" "--gc-sections" "-pie" "-zrelro" "-znow" "-L" "/home/carado/tmp/rust3/target/debug/deps" "-L" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--start-group" "-Bstatic" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-44988553032616b2.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-607feef6be9150b2.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace-a8dbf6d92401e34a.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace_sys-9a4716f5e8a3e722.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-988a64d96b043c6d.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-cadd6177b8c6d586.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-8f1d8efc92b45369.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-1e76014677816767.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-cc28bce38cb195d9.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-4123e9e89add689a.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-4d259c17788c1fb5.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-9495dbda85bb8f16.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-793d0026c575805f.rlib" "--end-group" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-33c3162edae6574e.rlib" "-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
  = note: rust-lld: error: unable to find library -ldl
          rust-lld: error: unable to find library -lrt
          rust-lld: error: unable to find library -lpthread
          rust-lld: error: unable to find library -lgcc_s
          rust-lld: error: unable to find library -lc
          rust-lld: error: unable to find library -lm
          rust-lld: error: unable to find library -lrt
          rust-lld: error: unable to find library -lpthread
          rust-lld: error: unable to find library -lutil
          rust-lld: error: unable to find library -lutil


error: aborting due to previous error

error: Could not compile `rust3`.

To learn more, run the command again with --verbose.

मुझे कैराडो जैसी ही त्रुटियां मिल रही हैं। लिंकर इनवोकेशन में "शूहॉर्न" -L /usr/lib में प्रबंधित, लेकिन यह छूटे हुए कामों की सूची को -lgcc देता है जो सिस्टम में कहीं भी libgcc रूप में मौजूद नहीं है (एक libgcc_s.a ) मुझे संदेह है कि यह कुछ ग्नू-वाद का परिणाम है, लेकिन यह पता नहीं लगा सकता कि इसे कैसे ठीक किया जाए।

@almindor RUSTFLAGS='-C linker=rust-lld -L /usr/lib -L /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0' या कुछ इसी तरह का प्रयास करें। पथ आपके डिस्ट्रो और कंपाइलर संस्करण पर निर्भर करेगा।

क्या ऊपर मेरी टिप्पणी एलएलडी का उपयोग करने का सही तरीका है? मैं इसे काम पर नहीं ला सकता, क्योंकि प्रत्येक प्रोग्राम SIGSEGV साथ क्रैश हो जाता है:

Reading symbols from target/debug/hello...
(gdb) show directories
Source directories searched: ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/etc:$cdir:$cwd
(gdb) r
Starting program: target/debug/hello 

Program received signal SIGSEGV, Segmentation fault.
core::ops::function::FnOnce::call_once{{vtable-shim}} () at /rustc/a7f28678bbf4e16893bb6a718e427504167a9494/src/libcore/ops/function.rs:231
(gdb) l
226     #[stable(feature = "fn_once_output", since = "1.12.0")]
227     type Output;
228 
229     /// Performs the call operation.
230     #[unstable(feature = "fn_traits", issue = "29625")]
231     extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
232 }
233 
234 mod impls {
235     #[stable(feature = "rust1", since = "1.0.0")] 
(gdb) info reg
rax            0x0                 0
rbx            0x0                 0
rcx            0x0                 0
rdx            0x0                 0
rsi            0x0                 0
rdi            0x0                 0
rbp            0x0                 0x0
rsp            0x7fffffffddb0      0x7fffffffddb0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x0                 0
r13            0x0                 0
r14            0x0                 0
r15            0x0                 0
rip            0x7ffff7ffc000      0x7ffff7ffc000 <core::ops::function::FnOnce::call_once{{vtable-shim}}>
eflags         0x10202             [ IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
(gdb) disassemble 
Dump of assembler code for function core::ops::function::FnOnce::call_once{{vtable-shim}}:
=> 0x00007ffff7ffc000 <+0>: mov    (%rdi),%rax
   0x00007ffff7ffc003 <+3>: mov    (%rax),%rdi
   0x00007ffff7ffc006 <+6>: jmpq   *0x11d4(%rip)        # 0x7ffff7ffd1e0
End of assembler dump.

यहां समाप्त होने वाले किसी भी व्यक्ति के लिए, जादू मंत्र RUSTFLAGS="-C link-arg=-fuse-ld=lld" cargo build यदि आपके पास जीसीसी 9 या क्लैंग आपके कंपाइलर के रूप में है। वैकल्पिक रूप से, -C linker=clang को GCC संस्करण की परवाह किए बिना काम करना चाहिए, इसलिए इसे प्राथमिकता दी जा सकती है।

इसे स्थायी बनाने के लिए, आप इसे किसी विशिष्ट प्रोजेक्ट में ~/.cargo/config या .cargo/config में जोड़ सकते हैं:

[build]
rustflags = ["-C", "linker=clang"]
# rustflags = ["-C", "link-arg=-fuse-ld=lld"]

@lnicola नोट यह केवल जीसीसी 9 या क्लैंग को सीसी के रूप में उपयोग करते समय काम करता है।

@bstree क्या आप जानते हैं कि इसकी वर्तमान स्थिति क्या है? इसके साथ आगे बढ़ने के लिए अवरोधक क्या हैं?

@ mati865 क्या आप पुराने जीसीसी वाले लोगों के लिए वैकल्पिक आमंत्रण जानते हैं?

@lnicola मेरे सभी प्लेटफार्मों में

@jonhoo मैं इस क्षेत्र में किसी भी काम के बराबर नहीं हूं, मुझे लगता है कि आप कंपाइलर टीम से पूछना चाहते हैं।

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

ट्राइएज; @ जंग-लैंग/कंपाइलर क्या किसी को पता है कि इस मुद्दे की वर्तमान स्थिति क्या है?

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

मैंने ऊपर जो आदेश पोस्ट किया है वह लिनक्स पर जीसीसी 9.2.0 और एलएलडी 9.0.0 के साथ काम करता है। मुझे लगता है कि यह कभी-कभी विंडोज़ पर भी काम करता है, लेकिन मैंने किसी ऐसे व्यक्ति को विंडोज़ के लिए जीसीसी 9 के साथ देखा है जो -फ्यूज = एलएलडी का समर्थन नहीं करता था। मैकोज़ पर यहां पोस्ट किए गए कुछ लिंक के मुताबिक कोशिश करने लायक नहीं है।

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

बिल्ली / आदि / सिस्टम-रिलीज़
फेडोरा रिलीज़ 30 (तीस)

सीसी --संस्करण
सीसी (जीसीसी) 9.2.1 20190827 (रेड हैट 9.2.1-1)

ld.lld --संस्करण
एलएलडी 8.0.0 (जीएनयू लिंकर्स के साथ संगत)

उम्मीद है कि यह मदद करता है

लेकिन मैंने किसी ऐसे व्यक्ति को देखा है जिसके पास Windows के लिए GCC 9 है जो समर्थन नहीं करता -fuse=lld

@lnicola
विंडोज जीसीसी 9 -fuse-ld=lld समर्थन करता है (जब तक कि वे इसका समर्थन नहीं करने के लिए पैच किए जाते हैं लेकिन कोई ऐसा क्यों करेगा?)
मुझे लगता है कि rust-mingw घटक स्थापित किया गया था और लिंकर को .cargo/config में ओवरराइड नहीं किया गया था। इस तरह rustc ने सिस्टम एक के बजाय GCC 6 को शिप किया।

विंडोज़ पर एक और मुद्दा हार्डकोडेड लिंकर फ्लैग --enable-long-section-names जो एलएलडी 9 और पुराने का समर्थन नहीं करता है (भविष्य में इसका समर्थन करने की योजना है)। इसके आसपास जाने के लिए आप यह कर सकते हैं:

• रैपर बनाएं जो इस ध्वज को पट्टी करता है
• इस ध्वज को नो-ऑप के रूप में स्वीकार करने के लिए LLD को पैच करें
• स्थानीय पैच वाले रस्ट बिल्ड का उपयोग करें जो इस ध्वज का उपयोग नहीं करते हैं

विंडोज़ पर एक और मुद्दा हार्डकोडेड लिंकर फ्लैग --enable-long-section-names है जो एलएलडी 9 और पुराने का समर्थन नहीं करता है (भविष्य में इसका समर्थन करने की योजना है)।

इस भाग द्वारा तय किया गया है: https://github.com/rust-lang/rust/pull/66257
विंडोज-जीएनयू उपयोगकर्ताओं को अभी भी सी कंपाइलर का उपयोग करने के लिए मैन्युअल काम करना पड़ता है जो -fuse-ld=lld का समर्थन करता है।

@bstree : यह विंडोज- https://github.com/rust-gamedev/wg/issues/50

एक और डेटा बिंदु: का उपयोग कर RUSTFLAGS="-C link-arg=-fuse-ld=lld" जब निर्माण rustc ही है, समय जोड़ने मेरा व्रत 14 कोर लिनक्स बॉक्स पर 41s के लिए 93S से चला जाता है।

@nnethercote: स्थापित करने से है कि अलग है linker=lld (उदाहरण के लिए) में [target.x86_64-unknown-linux-gnu] की धारा config.toml ?

@ हारून 1011 : मेरा अनुमान है कि दो दृष्टिकोणों का एक ही प्रभाव होगा, लेकिन मैंने इसे स्वयं नहीं देखा है।

@Aaron1011 यह बजना चाहिए, https://github.com/rust-lang/rust/issues/39915#issuecomment -538049306 देखें।

@ मति865
क्या आपने लिंकर के रूप में LLD के साथ x86_64-pc-windows-gnu पर rustc बनाने की कोशिश की है?

मैंने आज इसे आजमाया और LLD या तो निर्माण के बीच में लटक गया और कोई काम करना बंद कर दिया, या unknown argument: --version-script=... बारे में शिकायत की।
हैंग तब भी होता है जब LLD का उपयोग केवल LLVM को जोड़ने के लिए किया जाता है

[llvm]
use-linker = "lld"

उपकरण संस्करण:

$ ld.lld --version
LLD 9.0.1 (https://github.com/msys2/MINGW-packages.git 5e3b8820ed9f04221affee4197e458aca2612e87) (compatible with GNU linkers)

$ gcc --version
gcc.exe (Rev2, Built by MSYS2 project) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

@petrochenkov हाँ मैं इसे कुछ हैक्स के साथ बना सकता हूं:

• एलएलडी सीओएफएफ बैकएंड लिंकर स्क्रिप्ट का समर्थन नहीं करता है लेकिन एलडी और एलएलडी दोनों एमएसवीसी शैली .def फाइलों के साथ ठीक हैं; हल करने में आसान
• LLD को उम्मीद है कि पुस्तकालय lib (यह UNIX दुनिया में एक मानक है) लेकिन किसी तरह Rust ने सभी windows-* लक्ष्यों के लिए ऐसा नहीं किया: https://github.com/rust-lang/ जंग/बूँद/9ebf47851a357faa4cd97f4b1dc7835f6376e639/src/libstd/sys/windows/env.rs#L4
  एलडी किसी भी तरह से बुरा नहीं मानता है और मुझे नहीं पता कि एलएलडी या जंग की तरफ इसे ठीक करने के लिए धक्का देना है या नहीं।

मैं यहां भविष्य की कुछ संभावनाएं लिख रहा हूं। हालांकि कुछ कार्यान्वयन प्रयासों की आवश्यकता है, मुझे लगता है कि ये जंग के विकास में कुछ पुराने दर्द बिंदुओं को हल करने में मदद करेंगे:

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

लिंकर कमांड के रूप में lld में बहुत सारे पथ नामों को पास करने के बजाय, वर्चुअल फ़ाइल सिस्टम का उपयोग करें, और जब भी पर्याप्त मेमोरी स्पेस हो तो डिस्क IO का उपयोग करने के बजाय उन डेटा को मेमोरी-टू-मेमोरी से पास करें। बड़ी परियोजनाओं के लिए यह सैकड़ों या हजारों मेगाबाइट डिस्क IO बचा सकता है, और इस प्रकार संकलन समय में सुधार करता है।

यह सिर्फ IO बैंडविड्थ की बात नहीं है। विंडोज जैसे प्लेटफॉर्म पर, विशेष रूप से जब विंडोज डिफेंडर सक्षम होता है, तो जिस फाइल के साथ आप काम करना चाहते हैं, वह काफी महत्वपूर्ण समय जुर्माना जोड़ती है, और रस्ट के कोडजेन यूनिट मॉडल का मतलब है कि क्रेट सैकड़ों छोटी ऑब्जेक्ट फाइलों में विभाजित हो जाते हैं जो बहुत सारे संकलन को जल्दी से रैक कर सकते हैं। समय।

यह बग थोड़ा गड़बड़ है, इसलिए जो लोग इसे आगे बढ़ाना चाहते हैं, उनके लिए वर्तमान स्थिति के त्वरित सारांश में मेरा सबसे अच्छा शॉट है।

एलएलडी क्या है

एक लिंकर जो llvm प्रोजेक्ट का हिस्सा है, जो दो कारणों से वांछनीय है:

• यह संकलन को पार करने के लिए बहुत अनुकूल है (इसलिए एम्बेडेड लक्ष्यों के लिए इसका जोर)
• यह बहुत तेज़ है (अक्सर गोल्ड के रूप में आधे समय में चलता है - बड़ी परियोजनाओं (रस्टसी, सर्वो, आदि) के लिए लिंकिंग में कई मिनट लग सकते हैं और लिंकिंग वृद्धिशील बिल्ड के साथ संकलन का एक बड़ा% हो सकता है, इसलिए इस रनटाइम को रोकना एक है बड़ी बात।)

चीजें रस्ट आज lld के साथ करती है

• रस्ट वर्तमान में अधिकांश प्लेटफार्मों पर lld की अपनी प्रतिलिपि को बाइनरी के रूप में शिप करता है जिसे इसे rust-lld . कहते हैं
• कई बेयर-मेटल लक्ष्यों पर डिफ़ॉल्ट रूप से rust-lld का उपयोग किया जाता है
• डिफ़ॉल्ट रूप से wasm . के लिए rust-lld का उपयोग किया जाता है
• (?) आप स्पष्ट रूप से "-सी लिंकर-स्वाद" का उपयोग करके जंग-एलएलडी का उपयोग करने का अनुरोध कर सकते हैं (गैर-नंगे धातु प्लेटफॉर्म पर यह वास्तव में क्या करता है, नीचे देखें)

अधिक स्थानों पर रस्ट-एलएलडी का उपयोग करने में समस्याएँ (अर्थात डेस्कटॉप linux/mac/windows)

• lld के लिए macOS (Mach-O) बैकएंड टूट गया है और छोड़ दिया गया है
  
  
  
  • खरोंच से एक पुनर्लेखन शुरू हो गया है, लेकिन अभी शुरुआती दिन हैं
  
  
• लिनक्स/यूनिक्स प्लेटफॉर्म पर, आपको सीधे एलडी/एलएलडी का आह्वान नहीं करना चाहिए। आपको अपने सिस्टम सी कंपाइलर (यानी जीसीसी) के माध्यम से लिंकर का आह्वान करना चाहिए, जिसकी जिम्मेदारी crt1.o जैसे सिस्टम प्रतीकों की खोज करना है और उन्हें एलडी को प्रदान करना है। इसका मतलब है कि हम रस्ट-एलएलडी का "सिर्फ" उपयोग नहीं कर सकते; हमें इसे जीसीसी/क्लैंग/जो कुछ भी खिलाना चाहिए। (हम इस प्रणाली प्रतीक तर्क को स्वयं लागू नहीं करना चाहते हैं)
  
  
  
  • आम तौर पर, आप लिंकर को पथ के रूप में प्रदान नहीं कर सकते हैं, आपको इसे सी कंपाइलर के खोज पथ में "एलडी" के रूप में इंजेक्ट करना होगा
  
  
  • वैकल्पिक रूप से, आप वही काम कर सकते हैं लेकिन इसे "ld.lld" के रूप में इंजेक्ट कर सकते हैं, और "-fuse-ld=lld" पास कर सकते हैं
    
    
    
    
    
    • यह महत्वपूर्ण हो सकता है, जाहिरा तौर पर ll क्लैंग-स्टाइल बाइनरी नाम का पता लगाता है कि क्या इसे "ld" या "ld.lld" के रूप में निष्पादित किया जा रहा है (जांच की आवश्यकता है)
    
    
    
    • दुर्भाग्य से -fuse-ld=lld GCC 9 का केवल एक हिस्सा है, इसलिए हमें इसका उपयोग करने के लिए फीचर/संस्करण का पता लगाने की आवश्यकता हो सकती है (क्लैंग में यह लंबे समय से है)
    
    
    
  
  
• windows-msvc स्पष्ट रूप से अच्छी स्थिति में है, और लगता है कि बैकएंड में rust-lld का उपयोग करने के लिए कुछ सीमित समर्थन है, लेकिन मैं स्पष्ट नहीं हूं कि यहां क्या करने की आवश्यकता है।
• विंडोज़-मिंगव लगभग एक ही स्थान पर लिनक्स/यूनिक्स के रूप में प्रतीत होता है, सिवाय इसके कि आप एक प्राचीन जीसीसी प्राप्त करने के लिए उत्तरदायी हैं, और चीजें थोड़ी अजीब हैं क्योंकि छद्म-विंडोज़-लिनक्स बिल्कुल एक अच्छी तरह से परीक्षण कॉन्फ़िगरेशन नहीं है?

इसके अलावा सामान्य तौर पर, lld नया है, यह अधिकांश OSes के लिए डिफ़ॉल्ट नहीं है, यदि हम इसे अधिक स्थानों पर उपयोग करना शुरू करते हैं तो यादृच्छिक संगत बग लगभग निश्चित रूप से सामने आने वाले हैं।

मैंने दो प्लेटफार्मों पर डिफ़ॉल्ट रूप से (जंग-) lld का उपयोग करने पर केंद्रित प्रयासों के लिए दो मेटाबग्स दायर किए हैं:

• #71515 - x64 उबंटू 20.04 एलटीएस (और अधिक व्यापक रूप से सभी x64 ईएलएफ प्लेटफॉर्म)
• #71520 - x64 एमएसवीसी विंडो

windows-msvc स्पष्ट रूप से अच्छी स्थिति में है, और लगता है कि बैकएंड में rust-lld का उपयोग करने के लिए कुछ सीमित समर्थन है, लेकिन मैं स्पष्ट नहीं हूं कि यहां क्या करने की आवश्यकता है।

LLD + windows-msvc बहुत अच्छी स्थिति में है, मैं वर्तमान में rustc विकास के लिए इस सेटअप का उपयोग कर रहा हूं।

lld-link लिए सभी आवश्यक समर्थन rustc बैकएंड में मौजूद हैं, लेकिन https://github.com/rust-lang/rust/issues/68647 जैसे बग हैं

• यह महत्वपूर्ण हो सकता है, जाहिरा तौर पर ll क्लैंग-स्टाइल बाइनरी नाम का पता लगाता है कि क्या इसे "ld" या "ld.lld" के रूप में निष्पादित किया जा रहा है (जांच की आवश्यकता है)

यह करता है, लेकिन ld और ld.lld एक ही मोड हैं: https://github.com/rust-lang/llvm-project/blob/rustc/10.0-2020-02-05/lld/tools/lld/lld। cpp (8.0-2019-01-16 के बाद से ही)

• दुर्भाग्य से -fuse-ld=lld GCC 9 का केवल एक हिस्सा है, इसलिए हमें इसका उपयोग करने के लिए फीचर/संस्करण का पता लगाने की आवश्यकता हो सकती है (क्लैंग में यह लंबे समय से है)

चूंकि ld.lld ld के समान है, और https://patches-gcc.linaro.org/patch/11148/ के अनुसार -fuse-ld=lld के साथ एकमात्र परिवर्तन ld के बजाय ld.lld चलाना है, यदि हम पथ इंजेक्शन का उपयोग करते हैं, यह ठीक होना चाहिए। मुझे लगता है कि इसे जीसीसी 9+ पर लॉक करना अच्छा नहीं है, हालांकि: डेबियन स्थिर में केवल 8.3 है, और बुल्सआई शायद 2021 तक रिलीज़ नहीं होगी।

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

mingw-w64 6.0.0, 2018-09-16 को जारी किया गया, इसमें gcc 8.3.0 है, जिसमें -fuse-ld=lld नहीं है, लेकिन यह अभी भी काफी नया है। mingw-w64 7.0.0, 2019-11-11 को जारी किया गया, इसमें जीसीसी 9.3.0 है, जिसमें -फ्यूज-एलडी = एलएलडी है। डेबियन बस्टर (स्थिर) में 6.0.0, बुल्सआई (परीक्षण) में 7.0.0 है। डेबियन खिंचाव (ओल्डस्टेबल) में जीसीसी 6.3.0 के साथ केवल 5.0.1 है, लेकिन मुझे लगता है कि जीसीसी 6.3 के साथ महत्वपूर्ण मुद्दे होने पर एलएलडी समर्थन के लिए नवीनतम डेबियन स्थिर की आवश्यकता होगी।

मैंने दो प्लेटफार्मों पर डिफ़ॉल्ट रूप से (जंग-) lld का उपयोग करने पर केंद्रित प्रयासों के लिए दो मेटाबग्स दायर किए हैं:

• #71515 - x64 उबंटू 20.04 एलटीएस (और अधिक व्यापक रूप से सभी x64 ईएलएफ प्लेटफॉर्म)
• #71520 - x64 एमएसवीसी विंडो

lld के macOS (Mach-O) पोर्ट के बारे में: यह काम करने लगता है, या बहुत कम से कम, https://github.com/rust-lang/rust/issues/39915#issuecomment -618726211 के बाद से काफी बेहतर स्थिति में है। लिखा गया!

इस एलएलवीएम प्रतिबद्धता का उपयोग करके, मैंने lld और इसे टोकियो-आरएस/ट्रेसिंग के लिए प्रोजेक्ट-विशिष्ट लिंकर के रूप में सेट किया। मैंने तब nightly-x86_64-apple-darwin खिलाफ ट्रेसिंग का निर्माण किया और सभी परीक्षण सफलतापूर्वक चलाए। मैं (डीबग) निर्माण समय के बारे में विशेष रूप से खुश हूं:

• ld , एक साफ cargo build में 35 सेकंड लगे।
• lld , एक साफ cargo build में 20 सेकंड लगे।

ध्यान दें कि:

• ये प्रदर्शन संख्या हाल ही के मैकबुक प्रो से 32GB RAM और 8-कोर i9 के साथ आई है, और
• एलएलडी और मच-ओ के लिए कुछ बकाया मुद्दे हैं ।

@davidbarsky कूल! जिज्ञासा से बाहर, उस प्रदर्शन की तुलना zld कैसे की जाती है? ( https://github.com/michaeleisel/zld )

इसके अलावा, क्या आपने थर्मल का हिसाब दिया? एमबीपी बहुत जल्दी थर्मल थ्रॉटलिंग में चला जाता है, खासकर डिफ़ॉल्ट प्रशंसक गति प्रोफ़ाइल के साथ। एक रन करने से पहले बस काज के पास मशीन के निचले हिस्से को स्पर्श करने के लिए ठंडा होने तक प्रतीक्षा करने से स्थिरता में मदद मिलनी चाहिए।

मैं सिर्फ इस तरह के एक बग, उबंटू 16 i686 पर