जीएचसी

द्वारा उत्पादित निष्पादन योग्य आकार को कम करें- जीओसी संस्करण 7.4.2 का उपयोग करते हुए झंडे के साथ -ओ 3, मुझे अभी भी भारी निष्पादन योग्य उत्पाद मिलता है। मैं समझता हूँ कि GHC स्थिर जोड़ने करता है, और बाइनरी की निर्भरता की तरह दिखता है:जीएचसी

linux-vdso.so.1 (0x00007fff49bff000) 
    libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007fe658d6c000) 
    librt.so.1 => /usr/lib/librt.so.1 (0x00007fe658b64000) 
    libutil.so.1 => /usr/lib/libutil.so.1 (0x00007fe658961000) 
    libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fe65875d000) 
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fe658541000) 
    libcurl.so.4 => /usr/lib/libcurl.so.4 (0x00007fe6582e3000) 
    libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007fe658074000) 
    libm.so.6 => /usr/lib/libm.so.6 (0x00007fe657d7a000) 
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fe657b65000) 
    libc.so.6 => /usr/lib/libc.so.6 (0x00007fe6577be000) 
    /lib/ld-linux-x86-64.so.2 (0x00007fe658fca000) 
    libssh2.so.1 => /usr/lib/libssh2.so.1 (0x00007fe657595000) 
    libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007fe65732b000) 
    libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fe656f22000) 
    libz.so.1 => /usr/lib/libz.so.1 (0x00007fe656d0c000

अब तक यह काफी अच्छा लग रहा है, फिर भी बाइनरी अंदर मैं लाइनों देख सकते हैं:

GHCi runtime linker: fatal error: I found a duplicate definition for symbol 
* Specifying the same object file twice on the GHCi command line 

    ....BlockedIndefinitelyOnMVar.......BlockedIndefinitelyOnSTM........AsyncException..base....GHC.IO.FD.......FD......GHC.IO.FD.setSize.

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

स्रोत

2012-09-09 jdevelop

आपको प्रश्न पर एक नज़र रखना चाहिए: http: //stackoverflow.com/questions/6115459/small-haskell-program-compiled-with-ghc-into-huge-binary? Lq = 1 - मैंने आपका फ़्लैग किया है इसके संभावित डुप्लिकेट के रूप में सवाल। – epsilonhalbe

यह वास्तव में सच नहीं है - मैंने फ़ाइल को तोड़ दिया और अप्रतिबंधित संस्करण के साथ कोई अंतर नहीं मिला। तो मैं अभी भी बाइनरी के आकार को कम करने के तरीके की तलाश में हूं। – jdevelop

और क्या आपने गतिशील लिंकिंग करने की कोशिश की - जैसा कि आप @ डॉनस्टवार्ट के जवाब में देखते हैं, इसने बाइनरी तरीके को प्रतीकों को अलग करने की तुलना में अधिक कॉम्पैक्ट बनाया है। लेकिन मैं एक विशेषज्ञ से बहुत दूर हूँ। – epsilonhalbe

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

अद्यतन:

UPX http://en.wikipedia.org/wiki/UPX के साथ अपने निष्पादन संक्षिप्त या निष्पादन के आकार को कम करने के लिए gzexe।

स्रोत

2012-11-09 08:37:45

डायनामिक लिंकिंग का उपयोग कर एक फ़ाइल से दूसरे फ़ाइल में चलने जैसा है। अगर मैं अपने एप्लिकेशन को अंतिम उपयोगकर्ताओं को भेजना चाहता हूं तो मुझे उन सभी डीएलएल को भी पैकेज करना होगा, इसलिए स्थैतिक लिंकिंग बहुत बढ़िया काम करती है।हालांकि निष्पादन योग्य का आकार अभी भी मुझे दुखी कर रहा है। – jdevelop

गतिशील लिंकिंग का भुगतान करता है, अगर आप मान सकते हैं कि आपके ग्राहक के पास पहले से ही डीएलएल स्थापित है, अन्यथा आप अपने आवेदन के साथ डीएलएल वितरित करते हैं और अपने संस्करण (विंडोज़ दृष्टिकोण) को लिंक करते हैं जिसमें स्थिर लिंकिंग के समान स्थान प्रभाव होता है। वास्तव में आपकी चिंता क्या है? जब एप्लिकेशन चल रहा है या डिलिवरेबल का डिस्कस्पेस मेमोरी उपयोग? यदि यह उत्तरार्द्ध है, तो आप अपने निष्पादन योग्य को 'यूपीएक्स' (http://en.wikipedia.org/wiki/UPX) या 'gzexe' के साथ संपीड़ित कर सकते हैं। –

असल में मुझे इस तथ्य को पसंद नहीं है कि निष्पादन योग्य के अंदर बहुत अजीब पाठ डेटा है। – jdevelop

एलएलवीएम अधिकांश अन्य कंपाइलरों की तुलना में लिंक समय पर अधिक अनुकूलन कर सकता है। हो सकता है कि जीएचसी में एलएलवीएम बैकएंड हो और आप कुछ/सभी निर्भरताओं को -4 के साथ पुनः संयोजित और लिंक कर सकें।

स्रोत

2012-11-17 08:59:45

उत्तर

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