Erlang 21 - 3. Cross Compiling Erlang/OTP

3 क्रॉस संकलन Erlang / OTP




erlang

3 क्रॉस संकलन Erlang / OTP

विषय - सूची

३.१ परिचय

यह दस्तावेज़ बताता है कि एर्लैंग / ओटीपी -21 को कैसे संकलित किया जाए। आपको Erlang / OTP को पार करने का प्रयास करने से पहले पूरे दस्तावेज़ को पढ़ने की सलाह दी जाती है। हालाँकि, इस दस्तावेज़ को पढ़ने से पहले, आपको $ERL_TOP/HOWTO/INSTALL.md दस्तावेज़ को पढ़ना चाहिए जो सामान्य रूप से Erlang / OTP बनाने और स्थापित करने का वर्णन करता है। $ERL_TOP स्रोत ट्री में शीर्ष निर्देशिका है।

otp_build वर्सेस कॉन्फ़िगर / बनाना

बिल्डिंग Erlang / OTP को $ERL_TOP/otp_build स्क्रिप्ट का उपयोग करके या $ERL_TOP/configure करके make सीधे $ERL_TOP/configure किया जा सकता है। otp_build का उपयोग करना आसान है क्योंकि इसमें कम चरण शामिल हैं, लेकिन otp_build बिल्ड प्रक्रिया उतनी लचीली नहीं है जितनी कि configure / बिल्ड प्रक्रिया। ध्यान दें कि otp_build configure एक डिफ़ॉल्ट कॉन्फ़िगरेशन का उत्पादन करेगा जो डिफ़ॉल्ट रूप से क्या configure करेगा से अलग है। उदाहरण के लिए, वर्तमान में --disable-dynamic-ssl-lib को configure कमांड लाइन के तर्कों में जोड़ा जाता है जब तक कि --enable-dynamic-ssl-lib को स्पष्ट रूप से पारित नहीं किया गया हो। हमारे द्वारा वितरित बाइनरी रिलीज़ को otp_build का उपयोग करके बनाया गया है। otp_build configure द्वारा उपयोग किए गए चूक किसी भी समय पूर्व सूचना के बिना बदल सकते हैं।

क्रॉस कॉन्फ़िगरेशन

$ERL_TOP/xcomp/erl-xcomp.conf.template फ़ाइल में सभी उपलब्ध क्रॉस कॉन्फ़िगरेशन चर शामिल हैं और क्रॉस संकलन कॉन्फ़िगरेशन बनाते समय इसे टेम्पलेट के रूप में उपयोग किया जा सकता है। सभी cross configuration variables भी इस दस्तावेज़ के अंत में सूचीबद्ध हैं। क्रॉस क्रॉस कॉन्फ़िगरेशन के उदाहरणों के लिए $ERL_TOP/xcomp/erl-xcomp-TileraMDE2.0-tilepro.conf फ़ाइल और $ERL_TOP/xcomp/erl-xcomp-x86_64-saf-linux-gnu.conf फ़ाइल देखें। यदि चर का डिफ़ॉल्ट व्यवहार संतोषजनक है, तो चर को सेट करने की आवश्यकता नहीं है। हालाँकि, डिफ़ॉल्ट स्क्रिप्ट का उपयोग करते समय configure स्क्रिप्ट एक चेतावनी जारी करेगा। जब एक चर निर्धारित किया गया है, तो कोई चेतावनी जारी नहीं की जाएगी।

एक क्रॉस कॉन्फ़िगरेशन फ़ाइल को otp_build configure करने के लिए --xcomp-conf कमांड लाइन तर्क का उपयोग करके पास किया जा सकता है। ध्यान दें कि configure इस कमांड लाइन तर्क को स्वीकार नहीं करता है। सीधे configure स्क्रिप्ट का उपयोग करते समय, एक <VARIABLE>=<VALUE> सिंटैक्स का उपयोग करके configure करने के लिए कॉन्फ़िगरेशन चर को तर्क के रूप में पास <VARIABLE>=<VALUE> । चर भी configure करने के लिए पर्यावरण चर के रूप में पारित किया जा सकता configure । हालाँकि, यदि आप वातावरण में कॉन्फ़िगरेशन पास करते हैं, तो इनवॉइस make करने से पहले इन सभी पर्यावरण चर को खोलना make ; अन्यथा, पर्यावरण चर कुछ अनुप्रयोगों, या कुछ अनुप्रयोगों के कुछ हिस्सों में चर बना सकते हैं, और आप एक गलत तरीके से कॉन्फ़िगर किए गए बिल्ड के साथ समाप्त हो सकते हैं।

क्रॉस संकलित क्या हो सकता है?

Wx एप्लिकेशन को छोड़कर सभी Erlang / OTP अनुप्रयोगों को संकलित किया जा सकता है। क्रॉस कंपाइलिंग होने पर वर्तमान में wx ड्राइवर का निर्माण स्वचालित रूप से अक्षम हो जाएगा।

अनुकूलता

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

पैच

कृपया इस प्रणाली के अनुरूप क्रॉस कंपाइलिंग के लिए कोई भी पैच सबमिट करें। सभी इनपुट का स्वागत है क्योंकि हमारे पास परीक्षण करने के लिए क्रॉस कंपाइलिंग वातावरण का बहुत सीमित सेट है। यदि एक नया कॉन्फ़िगरेशन चर की आवश्यकता है, तो इसे $ERL_TOP/xcomp/erl-xcomp.conf.template , और इसे $ERL_TOP/xcomp/erl-xcomp.conf.template में उपयोग configure.in । अन्य फ़ाइलें जिन्हें अद्यतन करने की आवश्यकता हो सकती है वे हैं:

  • $ERL_TOP/xcomp/erl-xcomp-vars.sh
  • $ERL_TOP/erl-build-tool-vars.sh
  • $ERL_TOP/erts/aclocal.m4
  • $ERL_TOP/xcomp/README.md
  • $ERL_TOP/xcomp/erl-xcomp-*.conf

ध्यान दें कि यह उन फ़ाइलों की अपूर्ण सूची हो सकती है जिन्हें अद्यतन करने की आवश्यकता है।

पैच जमा करने के तरीके के बारे में सामान्य जानकारी यहां पाई जा सकती है: http://wiki.github.com/erlang/otp/submitting-patches

3.2 प्रक्रिया का निर्माण और स्थापित करें

यदि आप Git में निर्माण कर रहे हैं, तो आप आगे बढ़ने से पहले $ERL_TOP/HOWTO/INSTALL.md Building in Git सेक्शन Building in Git पढ़ना चाहते हैं।

हम पहले configure / निर्माण प्रक्रिया से गुजरेंगे, जिसे लोग शायद सबसे परिचित हैं।

बिल्डिंग के साथ कॉन्फ़िगर करें / सीधे करें

(1)

निर्देशिका को Erlang / OTP स्रोत ट्री की शीर्ष निर्देशिका में बदलें।

$ cd $ERL_TOP

Erlang कोड को संकलित करने के लिए, एक छोटी Erlang बूटस्ट्रैप प्रणाली का निर्माण किया जाना है, या एक Erlang / OTP सिस्टम को उसी रिलीज़ के रूप में बनाया जा रहा है जिसे $PATH में प्रदान किया जाना है। लक्ष्य प्रणाली के लिए Erlang / OTP इस Erlang प्रणाली का उपयोग करके बनाया जाएगा, साथ में प्रदान किए गए क्रॉस संकलन उपकरण भी।

यदि आप $PATH में संगत Erlang / OTP सिस्टम का उपयोग करके निर्माण करना चाहते हैं, तो (3) पर जाएं।

बूटस्ट्रैप सिस्टम का निर्माण

(2)

$ ./configure --enable-bootstrap-only
$ make

--enable-bootstrap-only तर्क को configure करने के लिए कड़ाई से आवश्यक नहीं है, लेकिन चीजों को गति देगा। यह केवल बूटस्ट्रैप के लिए आवश्यक अनुप्रयोगों में configure को चलाएगा, और बूटस्ट्रैप सिस्टम द्वारा आवश्यक बहुत सारी चीजों को अक्षम कर देगा। यदि आप बिना configure --enable-boostrap-only रन --enable-boostrap-only रन के चलाते हैं, make bootstrap बनाने के लिए भी रन करना होगा; अन्यथा, पूरी प्रणाली का निर्माण किया जाएगा।

क्रॉस बिल्डिंग सिस्टम

(3)

$ ./configure --host=<HOST> --build=<BUILD> [Other Config Args]
$ make

<HOST> वह होस्ट / टारगेट सिस्टम है जिसका निर्माण आप करते हैं। यह एक पूर्ण CPU-VENDOR-OS ट्रिपल नहीं है, लेकिन हो सकता है पूरा CPU-VENDOR-OS ट्रिपल $ERL_TOP/erts/autoconf/config.sub <HOST> को निष्पादित करके बनाया जाएगा। यदि config.sub विफल रहता है, तो आपको अधिक विशिष्ट होने की आवश्यकता है।

<BUILD> आपके द्वारा बनाए जाने वाले सिस्टम के CPU-VENDOR-OS ट्रिपल के बराबर होना चाहिए। यदि आप $ERL_TOP/erts/autoconf/config.guess निष्पादित करते हैं, तो यह ज्यादातर मामलों में आपके द्वारा उपयोग किए जाने वाले ट्रिपल प्रिंट करेगा।

<VARIABLE>=<VALUE> सिंटैक्स का उपयोग करके configure करने के लिए कमांड लाइन तर्क के रूप में क्रॉस संकलन चर पास <VARIABLE>=<VALUE>

ध्यान दें

जब आप सीधे configure करते हैं, तो आप --xcomp-conf तर्क का उपयोग करके कॉन्फ़िगरेशन फ़ाइल पास नहीं कर सकते। --xcomp-conf तर्क को केवल otp_build configure किया जा सकता otp_build configure

make सत्यापित करेगा कि निर्माण के दौरान उपयोग की गई एर्लांग / OTP प्रणाली उसी रिलीज़ की है, जिस सिस्टम का निर्माण किया जा रहा है, और ऐसा नहीं होने पर विफल हो जाएगा। हालांकि, यह संभव नहीं है कि क्रॉस संकलन को लागू करने के लिए अनुशंसित किया जाए, भले ही गलत Erlang / OTP सिस्टम का उपयोग किया जाए। इसे इस तरह से make ERL_XCOMP_FORCE_DIFFERENT_OTP=yes : make ERL_XCOMP_FORCE_DIFFERENT_OTP=yes

चेतावनी

make ERL_XCOMP_FORCE_DIFFERENT_OTP=yes को आमंत्रित make ERL_XCOMP_FORCE_DIFFERENT_OTP=yes विफल हो सकता है, चुपचाप make ERL_XCOMP_FORCE_DIFFERENT_OTP=yes कोड का उत्पादन कर सकता है, या चुपचाप गलत कोड का उत्पादन कर सकता है।

स्थापित कर रहा है

आप या तो configure (4) द्वारा निर्धारित अधिष्ठापन पथ का उपयोग करके स्थापित कर सकते हैं, या मैन्युअल रूप से (5) का उपयोग करके स्थापित कर सकते हैं।

कॉन्फ़िगर करके निर्धारित पथों का उपयोग करना

(4)

$ make install DESTDIR=<TEMPORARY_PREFIX>

make install configure करते समय निर्दिष्ट स्थान पर make install हो जाएगा। configure तर्क निर्दिष्ट करें कि इंस्टॉलेशन कहां होना चाहिए, उदाहरण के लिए: --prefix , --exec-prefix , --libdir , --bindir , आदि। डिफ़ॉल्ट रूप से यह /usr/local तहत इंस्टॉल हो जाएगा। आप आम तौर पर अपने क्रॉस मशीन को अपनी बिल्ड मशीन पर /usr/local नीचे स्थापित नहीं करना चाहते हैं। DESTDIR का उपयोग करने से अधिष्ठापन पथ $DESTDIR द्वारा उपसर्ग किया जाएगा। यह बिल्ड मशीन पर इंस्टॉलेशन को स्थापित करने और पैकेज करने के लिए संभव बनाता है, बिना इंस्टॉलेशन को बिल्ड मशीन पर उसी निर्देशिका में रखने के लिए जैसा कि इसे लक्ष्य मशीन पर निष्पादित किया जाना चाहिए।

जब make install समाप्त हो गया है, तो निर्देशिका को $DESTDIR में बदलें, सिस्टम को पैकेज करें, इसे लक्ष्य मशीन में ले जाएं, और इसे अनपैक करें। ध्यान दें कि स्थापना केवल लक्ष्य मशीन पर configure द्वारा निर्धारित स्थान पर काम करेगी।

मैन्युअल रूप से स्थापित करना

(5)

$ make release RELEASE_ROOT=<RELEASE_DIR>

make release ने आपके द्वारा लक्षित मशीन के लिए <RELEASE_DIR> प्रतिलिपि बनाई है। Install स्क्रिप्ट नहीं चलाई जाएगी। <RELEASE_DIR> की सामग्री डिफ़ॉल्ट रूप से /usr/local/lib/erlang में समाप्त होती है।

Erlang / OTP स्थापित करते समय उपयोग की जाने वाली स्क्रिप्ट को आपके $PATH में मौजूद होने के लिए sed जैसे सामान्य यूनिक्स टूल की आवश्यकता होती है। यदि आपके लक्ष्य प्रणाली में ऐसे उपकरण नहीं हैं, तो आपको Erlang / OTP से पहले पैकेजिंग मशीन पर अपनी स्क्रिप्ट Install करने की आवश्यकता है। Install स्क्रिप्ट को वर्तमान में उस निर्देशिका में निम्नानुसार लागू किया जाना चाहिए जहां वह रहता है (शीर्ष निर्देशिका):

$ ./Install [-cross] [-minimal|-sasl] <ERL_ROOT>

कहा पे:

  • -minimal एक इंस्टॉलेशन बनाता है जो कम से कम अनुप्रयोगों को शुरू करता है, अर्थात, केवल kernel और stdlib को शुरू किया जाता है। न्यूनतम प्रणाली सामान्य रूप से पर्याप्त है, और वही है जो make install उपयोग करता है।
  • -sasl एक इंस्टालेशन बनाता है जो sasl एप्लीकेशन को भी शुरू sasl है।
  • क्रॉस पार संकलन के लिए। स्थापित स्क्रिप्ट को सूचित करता है कि यह निर्माण मशीन पर चलाया जाता है।
  • <ERL_ROOT> - रन समय पर उपयोग करने के लिए <ERL_ROOT> स्थापना का पूर्ण पथ। यह अक्सर वर्तमान कार्यशील निर्देशिका के समान होता है, लेकिन होना नहीं है। यह फ़ाइल सिस्टम के माध्यम से उसी निर्देशिका में किसी अन्य पथ का अनुसरण कर सकता है।

यदि न तो- -minimal , न ही -sasl तर्क के रूप में पारित किया जाता है तो आपको संकेत दिया जाएगा।

अब आप या तो कर सकते हैं:

(6)

  • तय करें कि स्थापना लक्ष्य मशीन पर कहाँ होनी चाहिए, निर्माण मशीन पर Install स्क्रिप्ट चलाएँ, और स्थापित स्थापना को पैकेज करें। स्थापना को लक्ष्य मशीन पर सही स्थान पर अनपैक करने की आवश्यकता है:

    $ cd <RELEASE_DIR>
    $ ./Install -cross [-minimal|-sasl] <ABSOLUTE_INSTALL_DIR_ON_TARGET>

या:

(7)

  • <RELEASE_DIR> में इंस्टालेशन को पैकेज करें, इसे जहाँ भी आप अपने लक्ष्य मशीन पर रखना चाहते हैं, और अपने टारगेट सूची पर Install स्क्रिप्ट चलाएँ:

    $ cd <ABSOLUTE_INSTALL_DIR_ON_TARGET>
    $ ./Install [-minimal|-sasl] <ABSOLUTE_INSTALL_DIR_ON_TARGET>

Otp_build स्क्रिप्ट के साथ बिल्डिंग

(8)

$ cd $ERL_TOP

(9)

$ ./otp_build configure --xcomp-conf=<FILE> [Other Config Args]

वैकल्पिक रूप से:

$ ./otp_build configure --host=<HOST> --build=<BUILD> [Other Config Args]

यदि आपके पास किसी फ़ाइल में आपका क्रॉस संकलन है, तो इसे --xcomp-conf=<FILE> कमांड लाइन तर्क का उपयोग करके पास करें। यदि नहीं, तो पास --host=<HOST> , --build=<BUILD> , और कमांड लाइन पर एक <VARIABLE>=<VALUE> सिंटैक्स का उपयोग करके कॉन्फ़िगरेशन चर (उसी तरह (3))। ध्यान दें कि <HOST> और <BUILD> को एक या दूसरे रास्ते से <BUILD> होगा; कॉन्फ़िगरेशन फ़ाइल में erl_xcomp_host=<HOST> और erl_xcomp_build=<BUILD> का उपयोग करके, या --host=<HOST> , और --build=<BUILD> कमांड तर्क का उपयोग करके।

otp_build configure बिल्ड मशीन और क्रॉस होस्ट सिस्टम पर otp_build configure सिस्टम के लिए otp_build configure करेगा।

(10)

$ ./otp_build boot -a

otp_build boot -a पहले बिल्ड मशीन के लिए बूटस्ट्रैप सिस्टम बनाएगा और फिर सिस्टम का क्रॉस बिल्ड करेगा।

(1 1)

$ ./otp_build release -a <RELEASE_DIR>

otp_build release -a (5) के रूप में ही करेगा, और इसके बाद आपको मैन्युअल इंस्टॉल (6), या (7) करके करना होगा।

3.3 निर्माण और प्रलेखन स्थापित करना

सिस्टम के क्रॉस हो जाने के बाद आप उसी तरह से डॉक्यूमेंटेशन बना और स्थापित कर सकते हैं जैसे सिस्टम के मूल निर्माण के बाद। How to Build the Documentation बनाने के तरीके के बारे में जानकारी के लिए $ERL_TOP/HOWTO/INSTALL.md डॉक्यूमेंट में How to Build the Documentation सेक्शन का निर्माण कैसे देखें।

3.4 क्रॉस संकलित प्रणाली का परीक्षण करना

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

$ make release_tests

या

$ ./otp_build tests

परीक्षण $ERL_TOP/release/tests में जारी किए जाएंगे। परीक्षणों को जारी करने के बाद आपको निर्माण मशीन पर परीक्षण स्थापित करना होगा। आप (9) में / .pp_build के समान xcomp फ़ाइल की आपूर्ति करते हैं।

$ cd $ERL_TOP/release/tests/test_server/
$ $ERL_TOP/bootstrap/bin/erl -eval 'ts:install([{xcomp,"<FILE>"}])' -s ts compile_testcases -s init stop

आपको बहुत सारे प्रिंटआउट प्राप्त करने चाहिए क्योंकि टेस्टकेस संकलित हैं। एक बार जब आप पार मेजबान प्रणाली के लिए पूरे $ERL_TOP/release/tests फ़ोल्डर की प्रतिलिपि बनाना चाहिए।

फिर क्रॉस होस्ट सिस्टम पर जाएं और अपने $PATH में होने के लिए (4) या (5) में स्थापित इरांग को सेटअप करें। फिर पहले क्या $ERL_TOP/release/tests/test_server और निम्नलिखित कमांड जारी करें।

$ erl -s ts install -s ts run all_tests -s init stop

कॉन्फ़िगर को छोड़ दिया जाना चाहिए और सभी परीक्षणों को उम्मीद से पास होना चाहिए। Ts रन erl -s ts help -s init stop का उपयोग कैसे करें के बारे में अधिक जानकारी के लिए

3.5 वर्तमान में प्रयुक्त विन्यास चर

ध्यान दें कि आप क्रॉस संकलन कॉन्फ़िगरेशन फ़ाइल में मनमानी चर को परिभाषित नहीं कर सकते हैं। केवल नीचे सूचीबद्ध लोगों को सभी configure स्क्रिप्ट के पूरे निष्पादन में दिखाई देने की गारंटी होगी। अन्य चर को पर्यावरण में configure या निर्यात करने के लिए तर्क के रूप में परिभाषित किया जाना चाहिए।

केवल otp_build के लिए चर

इस खंड में चर का उपयोग केवल तब किया जाता है, जब $ERL_TOP/otp_build configure का उपयोग करके क्रॉस संकलन के लिए Erlang / OTP को $ERL_TOP/otp_build configure

ध्यान दें

यदि आप सीधे configure स्क्रिप्ट का उपयोग करके कॉन्फ़िगर करते हैं तो इन चर का कोई प्रभाव नहीं पड़ता है।

  • erl_xcomp_build - निर्माण प्रणाली का इस्तेमाल किया। यह मान configure स्क्रिप्ट के लिए --build=$erl_xcomp_build तर्क के रूप में पारित किया जाएगा। यह एक पूर्ण CPU-VENDOR-OS ट्रिपल नहीं है, लेकिन हो सकता है पूरा CPU-VENDOR-OS ट्रिपल $ERL_TOP/erts/autoconf/config.sub $erl_xcomp_build द्वारा बनाया जाएगा। यदि guess लिए सेट किया गया है, तो बिल्ड सिस्टम को $ERL_TOP/erts/autoconf/config.guess का उपयोग करके अनुमान लगाया जाएगा।

  • erl_xcomp_host - निर्माण के लिए क्रॉस होस्ट / लक्ष्य प्रणाली। यह मान configure स्क्रिप्ट के लिए --host=$erl_xcomp_host तर्क के रूप में पारित किया जाएगा। यह एक पूर्ण CPU-VENDOR-OS ट्रिपल नहीं है, लेकिन हो सकता है पूरा CPU-VENDOR-OS ट्रिपल $ERL_TOP/erts/autoconf/config.sub $erl_xcomp_host द्वारा बनाया जाएगा।

  • erl_xcomp_configure_flags - configure स्क्रिप्ट को पास करने के लिए अतिरिक्त कॉन्फ़िगर झंडे।

क्रॉस कंपाइलर और अन्य उपकरण

यदि क्रॉस संकलन उपकरण <HOST>- द्वारा उपसर्ग किए गए हैं <HOST>- तो आपको शायद इन चर को सेट करने की आवश्यकता नहीं है (जहां <HOST> जिसे configure करने के लिए --host=<HOST> तर्क के रूप में पारित किया गया configure )।

देशी संकलन के समय इस खंड के सभी चर का उपयोग किया जा सकता है।

  • CC - सी संकलक।

  • CFLAGS - C संकलक झंडे।

  • STATIC_CFLAGS - स्टेटिक सी संकलक झंडे।

  • CFLAG_RUNTIME_LIBRARY_PATH - इस ध्वज को साझा लाइब्रेरी के लिए रनटाइम लाइब्रेरी खोज पथ सेट करना चाहिए। ध्यान दें कि यह वास्तव में एक लिंकर ध्वज है, लेकिन इसे संकलक के माध्यम से पारित करने की आवश्यकता है।

  • CPP - सी प्री-प्रोसेसर।

  • CPPFLAGS - C प्री-प्रोसेसर झंडे।

  • CXX - C ++ कंपाइलर।

  • CXXFLAGS - C ++ कंपाइलर झंडे।

  • LD - लिंकर।

  • LDFLAGS - लिंकर झंडे।

  • LIBS - पुस्तकालय।

गतिशील Erlang चालक लिंकिंग
ध्यान दें

या तो DED_LD* चर के सभी या कोई भी सेट करें।

  • DED_LD - गतिशील लोड किए गए Erlang ड्राइवर्स के लिए लिंकर।

  • DED_LDFLAGS - DED_LDFLAGS साथ उपयोग करने के लिए लिंकर ध्वज।

  • DED_LD_FLAG_RUNTIME_LIBRARY_PATH - इस ध्वज को DED_LD लिंक करते समय साझा लाइब्रेरी के लिए रनटाइम लाइब्रेरी खोज पथ सेट करना चाहिए।

बड़ी फ़ाइल समर्थन
ध्यान दें

या तो LFS_* चर के सभी या कोई भी सेट करें।

  • LFS_CFLAGS - बड़ी फ़ाइल समर्थन सी संकलक झंडे।

  • LFS_LDFLAGS - बड़ी फ़ाइल समर्थन लिंकर झंडे।

  • LFS_LIBS - बड़ी फ़ाइल समर्थन लाइब्रेरी।

अन्य उपकरण
  • RANLIB - ranlib आर्काइव इंडेक्स टूल।

  • AR - ar संग्रह उपकरण।

  • GETCONF - getconf सिस्टम कॉन्फ़िगरेशन निरीक्षण उपकरण। getconf का उपयोग वर्तमान में बड़े फ़ाइल समर्थन फ़्लैग का उपयोग करने के लिए और लिनक्स सिस्टम पर यह पता लगाने के लिए किया जाता है कि क्या हमारे पास NPTL थ्रेड लाइब्रेरी है या नहीं।

क्रॉस सिस्टम रूट स्थान

  • erl_xcomp_sysroot - क्रॉस संकलन वातावरण के सिस्टम रूट का पूर्ण पथ। वर्तमान में, crypto , odbc , ssl और ssl अनुप्रयोगों को सिस्टम रूट की आवश्यकता है। यदि सिस्टम रूट सेट नहीं किया गया है तो ये एप्लिकेशन स्किप हो जाएंगे। अन्य चीजों के लिए भी सिस्टम रूट की आवश्यकता हो सकती है। यदि यह मामला है और सिस्टम रूट सेट नहीं किया गया है, तो configure विफल हो जाएगा और आपको इसे सेट करने का अनुरोध करेगा।

  • erl_xcomp_isysroot - क्रॉस संकलन वातावरण के लिए सिस्टम रूट के लिए निरपेक्ष पथ। यदि सेट नहीं किया जाता है, तो यह मान $erl_xcomp_sysroot , अर्थात, केवल इस मान को सेट करें यदि सिस्टम रूट पथ शामिल नहीं है सिस्टम रूट पथ के समान है।

वैकल्पिक सुविधा, और बग टेस्ट

इन परीक्षणों को (हमेशा) स्वचालित रूप से नहीं किया जा सकता है जब क्रॉस संकलन। आपको आमतौर पर इन चर को सेट करने की आवश्यकता नहीं होती है।

चेतावनी

इन चर को गलत सेट करने से रनटाइम त्रुटियों का पता लगाने में कठिनाई हो सकती है। यदि आपको इन मूल्यों को बदलने की आवश्यकता है, तो वास्तव में सुनिश्चित करें कि मान सही हैं।

ध्यान दें

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

डिफ़ॉल्ट मान का उपयोग किए जाने पर configure स्क्रिप्ट चेतावनी जारी करेगा। जब एक चर निर्धारित किया गया है, तो कोई चेतावनी जारी नहीं की जाएगी।

  • erl_xcomp_after_morecore_hook - yes|no | no लिए चूक। यदि yes , तो लक्ष्य प्रणाली में एक __after_morecore_hook काम होना चाहिए जो कि प्रयुक्त __after_morecore_hook malloc() कार्यान्वयन कोर मेमोरी उपयोग पर नज़र रखने के लिए उपयोग किया जा सकता है। यह वर्तमान में केवल असमर्थित सुविधाओं द्वारा उपयोग किया जाता है।

  • erl_xcomp_bigendian - yes|no । डिफ़ॉल्ट नहीं। यदि yes , तो टार्गेट सिस्टम बड़ा एंडियन होना चाहिए। यदि no , तो छोटे एंडियन। यह अक्सर स्वचालित रूप से पता लगाया जा सकता है, लेकिन हमेशा नहीं। यदि स्वचालित रूप से पता नहीं लगाया गया है, तो configure विफल हो जाएगा जब तक कि यह चर सेट न हो। चूंकि कोई डिफ़ॉल्ट मान का उपयोग नहीं किया जाता है, configure इसे स्वचालित रूप से जानने का प्रयास करेगा।

  • erl_xcomp_double_middle - yes|no no लिए चूक। यदि yes , तो "मध्य-एंडियन" प्रारूप में लक्ष्य प्रणाली दोगुनी होनी चाहिए। यदि no , तो इसकी "नियमित" समाप्ति है।

  • erl_xcomp_clock_gettime_cpu_time - yes|no no लिए चूक। यदि yes , तो टारगेट सिस्टम में एक वर्किंग clock_gettime() कार्यान्वयन होना चाहिए जो कि प्रोसेस सीपीयू समय को पुनः प्राप्त करने के लिए उपयोग किया जा सकता है।

  • erl_xcomp_getaddrinfo - yes|no | no लिए चूक। यदि yes , तो टारगेट सिस्टम में वर्किंग getaddrinfo() कार्यान्वयन होना चाहिए जो IPv4 और IPv6 दोनों को संभाल सके।

  • erl_xcomp_gethrvtime_procfs_ioctl - yes|no | no लिए चूक। यदि yes , तो लक्ष्य प्रणाली में एक कार्यशील gethrvtime() कार्यान्वयन होना चाहिए और इसका उपयोग procfs ioctl() साथ किया जाता है।

  • erl_xcomp_dlsym_brk_wrappers - yes|no | no लिए चूक। यदि yes , तो टारगेट सिस्टम में एक कार्यशील dlsym(RTLD_NEXT, <S>) कार्यान्वयन होना चाहिए जो उपयोग में brk और sbrk प्रतीकों पर इस्तेमाल किया जा सकता है malloc() कार्यान्वयन में उपयोग किया जाता है, और इस ट्रैक द्वारा malloc() कार्यान्वयन कोर मेमोरी उपयोग को ट्रैक करता है । यह वर्तमान में केवल असमर्थित सुविधाओं द्वारा उपयोग किया जाता है।

  • erl_xcomp_kqueue - yes|no no लिए चूक। यदि yes , तो लक्ष्य प्रणाली में एक काम करने वाला kqueue() कार्यान्वयन होना चाहिए जो एक फाइल डिस्क्रिप्टर लौटाता है जिसे poll() और / या select() द्वारा उपयोग किया जा सकता है। यदि no और लक्ष्य प्रणाली को epoll() या /dev/poll नहीं मिला है, तो कर्नेल-पोल सुविधा अक्षम हो जाएगी।

  • erl_xcomp_linux_clock_gettime_correction - yes|no । लिनक्स पर yes लिए चूक; अन्यथा, no । यदि yes , लक्ष्य प्रणाली पर clock_gettime(CLOCK_MONOTONIC, _) काम करना चाहिए। इस चर को 2.6 से कम कर्नेल संस्करणों के साथ लिनक्स सिस्टम पर no सेट करने की सिफारिश की गई है।

  • erl_xcomp_linux_nptl - yes|no | लिनक्स पर yes लिए चूक; अन्यथा, no । यदि yes , तो लक्ष्य प्रणाली में NPTL (मूल निवासी POSIX थ्रेड लाइब्रेरी) होना चाहिए। पुराने लिनक्स सिस्टम में एनपीटीएल (लिनक्स कर्नेल संस्करण आमतौर पर 2.6 से कम) के बजाय लिनक्सट्रेड होते हैं।

  • erl_xcomp_linux_usable_sigaltstack - yes|no | लिनक्स पर yes लिए चूक; अन्यथा, no । यदि yes , लक्ष्य प्रणाली पर sigaltstack() प्रयोग करने योग्य होना चाहिए। लिनक्स कर्नेल संस्करण पर sigaltstack() 2.4 से कम टूटे हुए हैं।

  • erl_xcomp_linux_usable_sigusrx - yes|no | yes चूक। यदि yes , तो SIGUSR1 और SIGUSR2 सिग्नल ERTS द्वारा उपयोग करने योग्य होने चाहिए। पुराने LinuxThreads थ्रेड लाइब्रेरी (लिनक्स कर्नेल संस्करण आमतौर पर 2.2 से कम) ने इन संकेतों का उपयोग किया और उन्हें ERTS द्वारा अनुपयोगी बना दिया।

  • erl_xcomp_poll - yes|no । डार्विन / MacOSX पर no लिए चूक; अन्यथा, yes । यदि yes , तो लक्ष्य प्रणाली में एक कार्य poll() कार्यान्वयन होना चाहिए जो उपकरणों को भी संभाल सके। यदि no , तो poll() बजाय select() का उपयोग किया जाएगा।

  • erl_xcomp_putenv_copy - yes|no no लिए चूक। यदि yes , तो लक्ष्य प्रणाली में एक putenv() कार्यान्वयन होना चाहिए जो कुंजी / मान युग्म की एक प्रति संग्रहीत करता है।

  • erl_xcomp_reliable_fpe - yes|no no लिए चूक। यदि yes , तो लक्ष्य प्रणाली में विश्वसनीय फ़्लोटिंग पॉइंट अपवाद होना चाहिए।

  • erl_xcomp_posix_memalign - yes|no | posix_memalign सिस्टम कॉल मौजूद होने पर yes चूक; अन्यथा no । यदि yes , तो लक्ष्य प्रणाली में एक posix_memalign कार्यान्वयन होना चाहिए जो पृष्ठ आकार संरेखण से बड़ा हो।