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

• MinGW और MSVC वास्तव में stdcall/dllimport के समान उपयोगों के लिए अलग-अलग प्रतीक सजावट का उपयोग करते हैं, जिससे लिंक करना शुरू करने के लिए हेडर (या कंपाइलर को अतिरिक्त झंडे पास करना) में संशोधन की आवश्यकता होती है।
• MSVC के साथ निर्मित एक स्थिर .lib को MinGW द्वारा ld.exe के साथ उत्पन्न फ़ाइलों को ऑब्जेक्ट करने के लिए लिंक करना शायद ही कभी काम करेगा, यहां तक ​​​​कि उनके स्वयं के दस्तावेज़ीकरण के अनुसार भी। मेरा व्यक्तिगत अनुभव यह है कि आम तौर पर ld.exe एक छोटे से उदाहरण से अधिक कुछ भी करने का प्रयास करते समय segfault होगा। विंडोज़ पर rustc का उपयोग link.exe (MSVC) करना मौजूदा VC++ कोड के साथ इंटरऑप की दिशा में एक बड़ा कदम होगा।
• डीएलएल के साथ स्थिति बेहतर है, लेकिन फिर भी गड़बड़ है। आयात पुस्तकालय शायद ही कभी "बस काम करते हैं", और आपको .def फ़ाइलों को निकालने/लिखना होगा या सीधे .dll से लिंक करना होगा; reimp.exe और --out-implib ध्वज जैसी चीज़ों के साथ खिलवाड़ करने में एक घंटा बिताने के बाद, आपको आश्चर्य होगा कि आप पहली बार में MinGW का उपयोग क्यों कर रहे हैं, और यदि आप इसे किसी भी तरह से टाल सकते हैं।
• यहां तक ​​कि अगर आप लिंक करने के लिए डीएलएल प्राप्त करने का प्रबंधन करते हैं, तो मिनजीडब्ल्यू डीएलएस msvcrt.dll और वीसी ++ 10 लिंक के खिलाफ msvcr100.dll के खिलाफ लिंक करता है, जिससे जब डेटा डीएलएल सीमा पार करता है और विभिन्न रनटाइम के साथ उपयोग किया जाता है तो सूक्ष्म बग होता है। यह सीमा मिनीजीडब्ल्यू के माध्यम से विंडोज़ पर संकलित बहुत सारे लिनक्स सॉफ़्टवेयर को पीड़ित करती है। उदाहरणों में GTK+ शामिल है जिसके लिए पुराने VC++6 कंपाइलर या MinGW का उपयोग करने के लिए इसके विरुद्ध कोड लिंकिंग को संकलित करने की आवश्यकता होती है, और Qt में MinGW और विभिन्न MSVC संस्करणों के लिए अलग-अलग वितरण होते हैं।

निश्चित रूप से यह आखिरी मुद्दा एक कंपाइलर (यानी वीएस2005/वीएस -2010) के असंगत संस्करण के साथ संकलित किसी भी कोड पर लागू होता है, हालांकि मुद्दा यह है कि एमएसवीसी के पुराने संस्करण के साथ मिंगव लिंक है कि यह आज नए कोड को संकलित करने के लिए उपयोगी नहीं है। मैंने msvcr100.dll के साथ काम करने के बारे में MinGW मेलिंग सूची में गतिविधि देखी है, इसलिए यह जल्द ही गायब हो सकता है। हालांकि, यह अभी भी खड़ा है कि मिनजीडब्ल्यू टूलचेन के साथ एमएस टूलचेन के साथ निर्मित स्थिर/साझा libs का उपयोग कहीं परेशानी और असंभव के बीच है। यदि .c कोड (जैसे # 1850) को MSVC के साथ संकलित किया जाता है, और फिर llvm द्वारा उत्पन्न rustc ऑब्जेक्ट्स के साथ लिंक किया जाता है, तो यह परेशानी बच जाएगी।

ध्यान दें कि मुझे llvm के साथ बहुत कम अनुभव है, इसलिए मुझे यकीन नहीं है कि LLVM का ABI (जंग की वस्तुओं के लिए प्रयुक्त) MSVC के साथ कितना संगत है। मुझे पता है कि यह संगत होना संभव है, क्योंकि इंटेल का कंपाइलर (आईसीसी) एमएसवीसी के साथ निर्मित .lib/.def/.dll का ठीक आयात करता है। यदि llvm cl.exe/link.exe के साथ icc के समान संगत कहीं भी है तो rustc उन लाभों को प्राप्त करेगा।

मैं यादृच्छिक धारणा पर टिप्पणी करना चाहता हूं कि मिंगव "विंडोज़ पर एक बहुत ही दुर्लभ टूलचेन" है।

तथ्य:
समीकरण.कॉम साइलैब के लिए एक मिंगव टूलचेन रखता है
mingw-w64 समायोजन और सुधार करता है
Google गो को मिंगव के साथ संकलित किया जा सकता है
रिएक्टोस एक मिंगव वातावरण का उपयोग करता है
कई एफओएसएस परियोजनाएं मिंगव को गले लगाती हैं

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

मिंगव कई स्क्रिप्टिंग भाषाओं के साथ इंटरऑपरेबल है, कई पूर्ण भाषाएं जैसे फ्रीपास्कल/मोनो/डी और गो। इस संबंध में मैं आपको वीएस के साथ मिंगव बनाए रखने या मिंगव रखने और क्लैंग + मिंगव लिब जोड़ने के लिए कहना चाहता हूं।

समस्या: जेमलोक को मिंगव की आवश्यकता है।

फ़ायरफ़ॉक्स MSVC के साथ विंडोज़ पर जेमलोक का उपयोग करता है: http://glandium.org/blog/?p=2581

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

@thestinger यह वास्तव में उतना कठिन कोडित नहीं है जितना लगता है। फ़ंक्शन पास के रूप में लाइब्रेरी कॉल और उनके बारे में कुछ जानकारी की केवल एक सूची है। एलएलवीएम को नियमित कॉल के समान ही जेई_ प्रीफिक्स्ड संस्करणों के लिए ऑप्टिमाइज़ेशन करने देने के लिए हमें उचित डेटा प्रदान करने के लिए इसे विस्तारित करने में सक्षम होना चाहिए।

@Aatch : इसके अलावा और भी बहुत कुछ है - free और malloc से संबंधित विशिष्ट अनुकूलन हैं

http://llvm.org/docs/doxygen/html/InstructionCombining_8cpp_source.html#l01378
http://llvm.org/docs/doxygen/html/Local_8cpp_source.html#l00269

बग ट्राइएज के लिए विजिट करना, 2013-08-05 से ईमेल करें

हम fdim जैसे कुछ c99 कार्यों का उपयोग करते हैं लेकिन यह msvcrt रनटाइम में नहीं है। #8663 इंगित करता है कि mingw/mingw-w64 उन्हें मैन्युअल रूप से कार्यान्वित करता है, इसलिए एमएसवीसी के लिए हमें उनसे कुछ भाग आयात करना होगा।

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