लंबे समय से, RedHat व्युत्पन्न Linux सिस्टम में संकुल जोड़ने को अच्छे कारण के लिए "RPM Hell" कहा गया है। विशेष रूप से यम उपयोगिता के मदद के आने से पहले, आरपीएम को सही काम करने के लिए प्राप्त करना अक्सर एक परेशानी भरा काम रहा है। दो लगभग समान CentOS सिस्टम पर PostgreSQL एक्सटेंशन को संकलित करने का प्रयास करते समय मुझे आज फिर से यह याद दिलाया गया।
PostgreSQL PGXS नाम का एक एपीआई प्रदान करता है जो आपको सर्वर एक्सटेंशन बनाने की सुविधा देता है जो सर्वर की कोड लाइब्रेरी का लाभ उठाता है और इसके साथ संचार करता है। हम अपनी repmgr उपयोगिता को स्थापित करने के लिए PGXS का उपयोग करते हैं, और उस अच्छी तरह से परिभाषित API होने से प्रोग्राम को मुख्य सर्वर कोर से बाहरी रूप से विकसित किया जा सकता है। PostgreSQL ऐड-ऑन के कई लोकप्रिय टुकड़े खुद को बनाने के लिए PGXS पर निर्भर हैं। वास्तव में, योगदान PostgreSQL के साथ आने वाले मॉड्यूल अक्सर इस तरह से बनाए जाते हैं। एक समान योगदान को हथियाना मॉड्यूल और उस पर हैकिंग एक नया पोस्टग्रेएसक्यूएल एक्सटेंशन बनाने की दिशा में एक अच्छा रास्ता है।
PGXS pg_config . पर निर्भर करता है उपयोगिता आपके पथ में है। pg_config postgresql-devel पैकेज के साथ आता है, जिसे आजकल वास्तव में postgresql90-devel नाम दिया गया है . दुर्भाग्य से यह डिफ़ॉल्ट रूप से किसी के लिए पथ में नहीं है। तो PGXS का उपयोग करके आपको जो पहला कदम बनाने की आवश्यकता है, वह है इसे वहां बनाना। ऐसा कुछ अधिकांश UNIX सिस्टम के लिए काम करेगा:
यहां बताया गया है कि भवन प्रतिनिधि कार्य प्रणाली पर कैसा दिखता है:
इसमें शामिल हैं –m64 -mtune=generic , जो कि 64 बिट प्लेटफॉर्म के लिए निर्माण कहने के लिए जीसीसी विकल्प हैं, लेकिन संकलक को यह पता लगाने दें कि आप अन्य प्रतिबंधों के सापेक्ष किस पर हैं। यदि आपके पास 64-बिट सिस्टम है, तो आजकल परिणाम सामान्य रूप से x86_64 के लिए अनुकूलित हो जाता है। जब विकल्प i386, i468, i586, और i686 थे, तब ऑटो-डिटेक्शन अधिक उपयोगी था।
परेशान करने वाली व्यवस्था पर। मैंने सोचा था कि मैं यहां पोस्टग्रेएसक्यूएल को समान रूप से रखूंगा, फिर भी बिल्ड बिल्कुल काम नहीं कर सका:
क्या? यह 32 बिट कोड बनाने की कोशिश कर रहा है: "-m32 -march=i386 -mtune=generic"। उसके कारण, जब यह सर्वर पर सभी 64-बिट पुस्तकालयों जैसे libpq और libtermcap के साथ लिंक करने का प्रयास करता है, तो ऐसा नहीं हो सकता है। दुनिया में यह कैसे हो रहा है?
pg_config का उपयोग करके आप देख सकते हैं कि PGXS बिल्ड कमांड में जाने वाली जानकारी कहां से आ रही है . CFLAGS . से संबंधित भाग की जांच करने का तरीका यहां दिया गया है , वह अनुभाग जहां बिट आकार की जानकारी यहां स्थित है:
अब मैं नाराज हूँ। यह कह रहा है कि 64 बिट्स के लिए भी निर्माण करें, फिर भी यह अभी भी 32-बिट जानकारी ढूंढ रहा है। यह कहाँ से आ रहा है?
कुछ लोग PGXS इंटरफ़ेस में खुदाई करके इसे वापस खोजने की कोशिश कर रहे हैं और अंततः मुझे /usr/pgsql-9.0/lib/pgxs/src/Makefile.global पर जाने देते हैं। और यहाँ क्या सुराग दिखाना शुरू हुआ। वह फ़ाइल सूचीबद्ध 32-बिट संकलक विकल्प! वे कहाँ से आए थे?
इस बिंदु पर मैंने यह देखना शुरू किया कि प्रत्येक सर्वर पर वास्तव में कौन से RPM स्थापित किए गए थे,
क्योंकि उनके बीच कुछ अलग होना था। जानने के लिए यहां एक आसान आदेश दिया गया है:
RHEL5 32 और 64 बिट अनुप्रयोगों को साथ-साथ चलाने में सक्षम है, आपको बस उन्हें संकलित करने के लिए सावधान रहना होगा। तो यह सामान्य है कि डेटाबेस संगतता पैकेज compat-postgresql-libs और postgresql90-libs दोनों आर्किटेक्चर शामिल हैं। आपके पास 32 और 64 दोनों ऐप हो सकते हैं जो एक ही सर्वर से बात करना चाहते हैं। यह अक्सर कष्टप्रद होता है, उदाहरण के लिए जब आप किसी पैकेज को हटाना चाहते हैं और यह बताता है कि आपका अनुरोध एक से अधिक मेल खाता है और कुछ नहीं करता है-आपको –allmatches की आवश्यकता है इसे ठीक करने के लिए।
हम सर्वर पर क्या देखते हैं जो संकलित नहीं होगा? बिल्कुल वही बात नहीं:
postgresql90-devel क्या हैं? i386 और x86_64 दोनों के लिए पैकेज वहाँ कर रहे हैं? इसका कोई मतलब नहीं है!
अब, इसे समझने के लिए परीक्षण करने के बाद, यदि आपके पास या तो -devel पैकेज है और दूसरे को स्थापित करने का प्रयास करते हैं, तो यह उन फ़ाइलों के लिए त्रुटियों की सही श्रृंखला को वापस लाता है जो विरोध करती हैं, जैसे:
पैकेजर अच्छी तरह जानता है कि वे उसी Makefile.global को अधिलेखित कर देते हैं। मैं दोनों के साथ कैसे समाप्त हुआ? सब कुछ मिटा देने के बाद मैंने पाया कि कैसे:
यह निश्चित रूप से ठीक नहीं है! यम उन्हें मिलाने में पूरी तरह से खुश हैं, और मैंने इसे पहले ध्यान दिए बिना किया होगा। यह पता चला है कि यदि आप उन दोनों को इस तरह स्थापित करने देते हैं, तो आपके पास जो कॉपी बची है, वह सही जानकारी को वापस PGXS को रिपोर्ट नहीं कर सकती है-आश्चर्यजनक रूप से, यह भ्रमित है। इस तरह मैंने अपनी समस्या का अंत किया। मैं Makefile.global . का उपयोग कर रहा था i386 संस्करण द्वारा स्थापित किया गया था, लेकिन सिस्टम पर बाकी सब कुछ x86_64 था।
तो सफाई कैसे करें? यहां फाइलों के मिश्रण को देखते हुए, आप वास्तव में भरोसा नहीं कर सकते कि अवांछित को हटाना ही काफी है। तब हो सकता है कि आपके पास स्वीकार की गई हर बात की कोई प्रति न बची हो। केवल सुरक्षित विकल्प उन दोनों को परमाणु बनाना है, फिर बस x86_64 एक स्थापित करें, अब जब हम जानते हैं कि उपरोक्त परीक्षण से बिल्कुल संस्करण उपलब्ध है:
इसे हल करने के साथ, अब मेरा PGXS एक्सटेंशन ठीक हो गया है, और विकास
repmgr पर एक दिन का समय गंवाने के बाद यह सब पता लगाने के लिए फिर से आगे बढ़ता है।
आज के लिए सबक: postgresql90-devel . को इंस्टॉल करते समय सावधान रहें यम के माध्यम से पैकेज करें, और इसे उस फ़ाइल के दोनों आर्किटेक्चर को वहां न रखने दें। केवल उसी का उपयोग करें जो आपके मुख्य postgresql90 . के प्लेटफॉर्म से मेल खाता हो पैकेट। और यदि आप RHEL/CentOS सिस्टम पर PGXS एक्सटेंशन बनाने का प्रयास कर रहे हैं, और आपको असंगत छोड़ना दिखाई देता है लाइब्रेरी संदेश, आपके द्वारा इंस्टॉल किए गए PostgreSQL डेवलपमेंट पैकेज (पैकेजों) को देखकर शुरू करें।
हम शायद इस विशेष खराब संयोजन को PostgreSQL 9.0 पैकेज के भविष्य के अपडेट द्वारा अवरुद्ध कर देंगे। मैंने सोचा कि वैसे भी साझा करना दिलचस्प था, क्योंकि आरपीएम पर इस तरह की समस्या निवारण करने के कई अच्छे उदाहरण नहीं हैं। मैंने एक बार आरएचईएल 5/सेंटोस 5 पर पोस्टग्रेएसक्यूएल 8.2 आरपीएम स्थापित करने का शीर्षक लिखा था जो यहां कुछ और पृष्ठभूमि से गुजरता है। लेकिन वे सरल दिन थे, इससे पहले 64-बिट प्लेटफ़ॉर्म लोकप्रिय थे, और इससे पहले कि आप एक ही समय में RPM के माध्यम से एक से अधिक PostgreSQL संस्करण स्थापित कर सकें। अपने संबंधित आर्किटेक्चर के साथ स्थापित पैकेजों को सूचीबद्ध करने के लिए सही RPM मंत्र को जानना आजकल RPM नरक से बाहर निकलने के लिए एक महत्वपूर्ण चाल है।
