intl-support

Question

के साथ PHP 5.3.0 स्थापित करने में समस्या वर्तमान में मैं कुछ लिनक्स परीक्षण सर्वर पर PHP 5.3.0 स्थापित करने का प्रयास कर रहा हूं। जैसा कि हमने एक्सटी/इंटेल के लिए तत्काल इंतजार किया है, हम जो सुविधाएं प्रदान करते हैं, उन्हें देखना चाहते हैं। मैं configure सफलतापूर्वक चल रहा हूँ निम्नलिखित तर्क

./configure 
    --with-apxs2=/usr/local/apache2/bin/apxs 
    --prefix=/usr/local/php 
    --with-zlib-dir=/usr/local/zlib 
    --with-imap=/.../imap-2006k 
    --with-imap-ssl 
    --with-openssl=shared 
    --with-iconv=shared 
    --with-zlib=shared 
    --with-curl=shared 
    --with-curlwrappers 
    --enable-exif 
    --with-ldap=shared,/usr/local/openldap 
    --with-ldap-sasl 
    --enable-mbstring=shared 
    --with-mcrypt 
    --enable-soap=shared 
    --enable-sockets 
    --enable-zip=shared 
    --enable-pdo=shared 
    --with-pdo-sqlite=shared 
    --with-sqlite=shared 
    --with-mysql=shared,/usr/local/mysql 
    --with-pdo-mysql=shared,/usr/local/mysql 
    --with-mysqli=shared,/usr/local/mysql/bin/mysql_config 
    --with-mhash=shared,/usr/local/mhash 
    --with-libxml-dir=/usr/local/libxml2 
    --with-xsl=shared,/usr/local/libxslt 
    --enable-xmlreader=shared 
    --enable-xmlwriter=shared 
    --with-gmp=shared 
    --with-icu-dir=/usr/local/icu 
    --enable-intl 

आईसीयू 4.2 /usr/local/icu पर स्थित है और PHP 5.2.9 दोषरहित संकलित साथ (int- और आईसीयू-विकल्प के बिना)। लेकिन जब मैं PHP 5.3.0 स्रोत complie मैं तरह

ext/intl/grapheme/.libs/grapheme_util.o(.text+0xbab):/.../php-5.3.0/ext/intl/grapheme/grapheme_util.c:208: undefined reference to `ubrk_close_4_2' 

मैं काफी यकीन है कि यह साझा पुस्तकालयों नहीं मिल के साथ कुछ है कर रहा हूँ की त्रुटि संदेशों में से एक पूरी बहुत कुछ मिलता है।

export LD_LIBRARY_PATH=/usr/local/icu/lib 

की सहायता नहीं करता है।

क्या कोई मुझे कुछ समाधान के लिए इंगित कर सकता है? मैं नहीं बल्कि पता कर रहा हूँ - और मैं इन बातों में कोई वास्तविक विशेषज्ञ हूँ ...

संपादित करें:

मैं सिर्फ फिर से जांचा और है कि विभिन्न आईसीयू-पुस्तकालयों और संबंधित सॉफ्ट लिंक सभी कर रहे हैं सुनिश्चित किया /usr/local/icu/lib में स्थित:

lrwxrwxrwx 1 root root  20 Jul 1 09:56 libicudata.so -> libicudata.so.42.0.1 
lrwxrwxrwx 1 root root  20 Jul 1 09:56 libicudata.so.42 -> libicudata.so.42.0.1 
-rw-r--r-- 1 root root 16015140 Jul 1 09:56 libicudata.so.42.0.1 
lrwxrwxrwx 1 root root  20 Jul 1 09:56 libicui18n.so -> libicui18n.so.42.0.1 
lrwxrwxrwx 1 root root  20 Jul 1 09:56 libicui18n.so.42 -> libicui18n.so.42.0.1 
-rwxr-xr-x 1 root root 2454770 Jul 1 09:56 libicui18n.so.42.0.1 
lrwxrwxrwx 1 root root  18 Jul 1 09:56 libicuio.so -> libicuio.so.42.0.1 
lrwxrwxrwx 1 root root  18 Jul 1 09:56 libicuio.so.42 -> libicuio.so.42.0.1 
-rwxr-xr-x 1 root root 65299 Jul 1 09:56 libicuio.so.42.0.1 
lrwxrwxrwx 1 root root  18 Jul 1 09:56 libicule.so -> libicule.so.42.0.1 
lrwxrwxrwx 1 root root  18 Jul 1 09:56 libicule.so.42 -> libicule.so.42.0.1 
-rwxr-xr-x 1 root root 356125 Jul 1 09:56 libicule.so.42.0.1 
lrwxrwxrwx 1 root root  18 Jul 1 09:56 libiculx.so -> libiculx.so.42.0.1 
lrwxrwxrwx 1 root root  18 Jul 1 09:56 libiculx.so.42 -> libiculx.so.42.0.1 
-rwxr-xr-x 1 root root 75110 Jul 1 09:56 libiculx.so.42.0.1 
lrwxrwxrwx 1 root root  18 Jul 1 09:56 libicutu.so -> libicutu.so.42.0.1 
lrwxrwxrwx 1 root root  18 Jul 1 09:56 libicutu.so.42 -> libicutu.so.42.0.1 
-rwxr-xr-x 1 root root 159330 Jul 1 09:56 libicutu.so.42.0.1 
lrwxrwxrwx 1 root root  18 Jul 1 09:56 libicuuc.so -> libicuuc.so.42.0.1 
lrwxrwxrwx 1 root root  18 Jul 1 09:56 libicuuc.so.42 -> libicuuc.so.42.0.1 
-rwxr-xr-x 1 root root 1660769 Jul 1 09:56 libicuuc.so.42.0.1 

make check रन परीक्षण की टन - उन सभी को सफलतापूर्वक:

[All tests passed successfully...] 
Elapsed Time: 00:00:25.000 
make[2]: Leaving directory `/.../icu-4.2/source/test/cintltst' 
--------------- 
ALL TESTS SUMMARY: 
All tests OK: testdata intltest iotest cintltst 
make[1]: Leaving directory `/.../icu-4.2/source/test' 
make[1]: Entering directory `/.../icu-4.2/source' 
verifying that icu-config --selfcheck can operate 
verifying that make -f Makefile.inc selfcheck can operate 
PASS: config selfcheck OK 
make[1]: Leaving directory `/.../icu-4.2/source' 

संपादित करें: के लिए जवाब VolkerK के questions

मैं स्रोत से आईसीयू 4.2 स्थापित किया है और जैसा कि मैंने निर्माण प्रक्रिया ऊपर लिखा था, यूनिट-परीक्षण और स्थापना सब ठीक चला गया। VolkerK की टिप्पणी के बारे में

/usr/local/icu/bin/icu-config --version 
4.2.0.1 

/usr/local/icu/bin/icu-config --prefix 
/usr/local/icu 

/usr/local/icu/bin/icu-config --cppflags-searchpath 
-I/usr/local/icu/include 

/usr/local/icu/bin/icu-config --ldflags --ldflags-icuio 
-lpthread -lm -L/usr/local/icu/lib -licui18n -licuuc -licudata -lpthread -lm -licuio 

objdump -C /usr/local/icu/lib/libicuuc.so.42.0.1 
// doesn't work because of unrecognized argument -C 

संपादित करें:

नहीं है, शामिल संकलक का कोई स्विच कर दिया गया है - मैं दोनों प्रक्रियाओं सीधे एक के बाद एक का निर्माण भाग गया। objdump /usr/local/icu/lib/libicuuc.so.42.0.1 काम नहीं करता है या तो, लेकिन मैं

objdump -t /usr/local/icu/lib/libicuuc.so.42.0.1 | grep ubrk_close 
00000000000d2484 g  F .text 000000000000002d    ubrk_close_4_2 

चलाने के लिए अगर यह जानकारी मदद कर सकते हैं पता नहीं है में कामयाब रहे। VolkerK के edit1 and edit2 पर

संपादित करें:

मुझे लगता है कि वहाँ रगड़ है - वहाँ वास्तव में है sytem पर एक और आईसीयू-संस्करण; कम से कम भागों में (उदाहरण के लिए कोई अन्य आईसीयू-कॉन्फ़िगर नहीं है; केवल /usr/local/icu/bin में से एक)।

gcc -lpthread -lm -L/usr/local/icu/lib -licui18n -licuuc -licudata -lpthread -lm -licuio -print-file-name=libicuuc.so रिटर्न

/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../lib64/libicuuc.so 

gcc -lpthread -lm -L/usr/local/icu/lib -licui18n -licuuc -licudata -lpthread -lm -licuio -print-file-name=libicuuc.so.42 रिटर्न

libicuuc.so.42 

तो समस्या हो, कैसे निर्माण प्रक्रिया में नए lib-पथ प्राप्त करने के लिए जा रहा है, जबकि ?? वैसे, मैंने आपके उत्तरों से बहुत कुछ सीखा - आप सभी को धन्यवाद।

मैंने आपके सरल परीक्षण कार्यक्रम को संकलित करने का भी प्रयास किया - और यह भी अपरिभाषित संदर्भ त्रुटि के साथ विफल रहता है, संभवतः PHP उसी संकलन के कारण संकलित नहीं होगा।

मैं lib-path में पुरानी आईसीयू-लाइब्रेरी के संदर्भ से कैसे छुटकारा पा सकता हूं या मैं नए आईसीयू-लाइब्रेरी-पथ को प्राथमिकता कैसे दूं?

Answer 1

समस्या यह प्रतीत होती है कि बाइनरी गलत (साझा) लाइब्रेरी फ़ाइलों के विरुद्ध जुड़ा हुआ है।
सबसे पहले, मुझे लगता है कि समस्या क्या है, इसकी एक उबाऊ व्याख्या। ध्यान रखें कि मैं एक लिनक्स विशेषज्ञ नहीं हूं। मैं वास्तव में चाहता हूं कि आप मेरी विचारों की ट्रेन को समझें ताकि आप यह तय कर सकें कि यह संभव है और/या जहां मैं गलत हूं।
पहला (कच्चा) समाधान आसानी से उलटा हो सकता है। एक और चलाएं ./configure और सभी परिवर्तन इतिहास हैं। मुझे लगता है कि यह बहुत बचा है।

आपके पास पहली जगह आईसीयू 4-2 विशिष्ट निर्भरता क्यों है? के

#include <unicode/ubrk.h> 
... 
PHP_FUNCTION(grapheme_substr) 
{ 
    ... 
    ubrk_close(bi); 
    ... 

अब वहाँ कोई संस्करण विशिष्ट कोड है जब तक php के intl विस्तार (एक्सटेंशन/intl/ग्रफीम/grapheme_string.c) के एक स्रोत फ़ाइल पर एक नज़र डालते हैं। grapheme_string.c वही दिखता है चाहे आप आईसीयू 3.4 या आईसीयू 4.2 का उपयोग करें। Ubrk_close_4_2 कहां से आता है?
जब आप "./configure ... --with-icu-dir =/usr/local/icu" चलाते हैं तो फ़ाइल ext/intl/config.m4 निष्पादित किया जाता है। इस प्रक्रिया में आईसीयू-कॉन्फ़िगरेशन को PHP बनाने के लिए आवश्यक पथ और लाइब्रेरी फ़ाइलों को शामिल करने के लिए कहा जाता है। आपने अपने आईसीयू इंस्टॉलेशन के लिए एक रास्ता प्रदान किया है जो

ICU_CONFIG="$PHP_ICU_DIR/bin/icu-config" 
ICU_INCS=`$ICU_CONFIG --cppflags-searchpath` 
ICU_LIBS=`$ICU_CONFIG --ldflags --ldflags-icuio` 

निष्पादित किया गया है। आपने खुद को आईसीयू-कॉन्फ़िगर करने का प्रयास किया है, इसलिए आप जानते हैं कि यह क्या आउटपुट करता है और इसलिए ICU_INCS और ICU_LIBS में क्या होता है। फ़ाइलों को संकलित/लिंक किए जाने पर ICU_INCS और ICU_LIBS जीसीसी को पास कर दिए जाते हैं। जीसीसी (अपरिवर्तनीय) को इसकी डिफ़ॉल्ट निर्देशिका में यूनिकोड/ubrk.h नहीं मिला, इसलिए यह आईसीयू_INसीएस द्वारा प्रदान की गई अतिरिक्त निर्देशिका में फ़ाइल की खोज की गई जहां इसे आईसीयू 4.2 में फाइलें शामिल थीं। यूनिकोड/ubrk.h में यूनिकोड/utypes.h शामिल है जिसमें उसके बाद यूनिकोड/urename.h शामिल है - और फिर आईसीयू 4.2 हेडर फाइलें शामिल हैं। इस मामले में यूनिकोड/urename.h में #define ubrk_close ubrk_close_4_2 शामिल है।
जब प्रीप्रोसेसर किया जाता है तो ubrk_close (bi) को ubrk_close_4_2 (bi) द्वारा प्रतिस्थापित किया गया है।

PHP_FUNCTION(grapheme_substr) 
{ 
    ... 
    ubrk_close_4_2(bi); 
    ... 

अब आप एक संस्करण विशिष्ट निर्भरता, एक संदर्भ है कि कुछ पुस्तकालय को हल करने के लिए किया ubrk_close_4_2 किया है।
तो इसमें भाग शामिल था। यह वास्तव में आपके आईसीयू 4.2 संस्करण को मिला और इसकी हेडर फाइलों का इस्तेमाल किया। अब तक सब ठीक है।
अब लिंकर भाग के लिए। आपके मामले में ICU_LIBS शामिल

-lpthread -lm -L/usr/local/icu/lib -licui18n -licuuc -licudata -lpthread -lm -licuio 

-licuuc जीसीसी कहता है "मुझे एक पुस्तकालय 'icuuc' और इसका इस्तेमाल करते हैं कहा जाता है लगता है"। जीसीसी फिर एक निश्चित नामकरण योजना वाली फाइलों के लिए एलआईबी पथ की खोज करता है जो "icuuc" से मेल खाते हैं।
इस मामले में libicuuc.so। ध्यान दें कि यह एक संस्करण विशिष्ट फ़ाइल नाम की तलाश नहीं करता है, बस libicuuc.so। एक बार यह ऐसी फाइल पाई जाने के बाद यह किसी और की तलाश नहीं करेगा। पहली जीसीसी अपने डिफ़ॉल्ट पथ में खोज करता है। फिर यह अतिरिक्त लाइब्रेरी पथों की खोज करता है - क्रम में वे जीसीसी को प्रदान किए जाते हैं। अर्थात।

जीसीसी एल/usr/lib एल/usr/स्थानीय/lib -licuuc

अगर वहाँ इस तरह के एक फ़ाइल है और /usr/lib/libicuuc.so मिलेगा नहीं/usr/स्थानीय/lib/libicuuc.so (अब और)। मतलब यह है कि या तो डिफ़ॉल्ट पथ या लाइब्रेरी पथ निर्देशों का क्रम आपकी परेशानी का कारण हो सकता है।
जब आपका प्रोग्राम साझा ऑब्जेक्ट्स से जुड़ा होता है तो कोड में "विशेष" लोडर जोड़ा जाता है और साझा ऑब्जेक्ट का नाम आपके प्रोग्राम (लिंक समय पर) में संग्रहीत होता है।
हर बार जब आपका प्रोग्राम निष्पादित होता है, तो पहले (रनटाइम) लोडर साझा ऑब्जेक्ट (इसके नाम से) के लिए खोज करता है, कोड लोड करता है और कुछ स्टब जंप पतों को प्रतिस्थापित करता है।
साझा ऑब्जेक्ट लिंकर (यानी लिंक समय पर) साझा ऑब्जेक्ट का नाम "बताएं" लोडर को लोडटाइम पर (SONAME प्रॉपर्टी) के लिए दिखाना चाहिए। निर्देशिका पर एक नज़र आप अपने प्रश्न पाठ में

lrwxrwxrwx 1 root root  18 Jul 1 09:56 libicuuc.so -> libicuuc.so.42.0.1 
lrwxrwxrwx 1 root root  18 Jul 1 09:56 libicuuc.so.42 -> libicuuc.so.42.0.1 
-rwxr-xr-x 1 root root 1660769 Jul 1 09:56 libicuuc.so.42.0.1 

libicuuc.so प्रदान की लिस्टिंग ले लो, उस फ़ाइल जीसीसी जब -licuuc प्रदान की जाती है की तलाश कर रहा है। लिंकर symlink का पालन करता है और libicuuc.so.42.0.1 का उपयोग करता है। यह फ़ाइल लिंकर को "बताती है" कि (रनटाइम) लोडर libicuuc.so.42 की तलाश करनी चाहिए, http://userguide.icu-project.org/packaging#TOC-ICU-Versions देखें।
लोडर symlink का पालन करेगा और libicuuc.so.42.0.1 लोड करेगा, या यदि कोई अन्य बगफिक्स libicuuc.so.42.0.2 है, libicuuc.so.42.0.3, जो भी libicuuc.so.42 इंगित कर रहा है। libicuuc.so.42 हमेशा एक वास्तविक साझा ऑब्जेक्ट को इंगित करना चाहिए जो आईसीयू 4.2 प्रतीकों को निर्यात करता है। कोड बदल गया/तय हो सकता है लेकिन निर्यातित प्रतीक समान रहते हैं। आपकी समस्या अब यह है कि gcc libicuuc.so- > libicuuc.so.42.0.1 नहीं मिला है (लेकिन मान लें) libicuuc.so- > libicuuc.so.34.x.y। यह libicuuc.so.34.x.y आईसीयू 4.2 प्रतीकों को निर्यात नहीं करता है, यह ubrk_close_4_2 प्रदान नहीं करता है लेकिन ubrk_close_3_4 प्रदान करता है। तो, कोई ubrk_close_4_2 - > अनसुलझे संदर्भ त्रुटि।

पहला "समाधान" (कच्चा): चलो/कॉन्फ़िगर करें उसका जादू करें और फिर ... मेकफ़ाइल संपादित करें।
ओपन Makefile (स्रोत शीर्ष निर्देशिका में) एक पाठ संपादक में, INTL_SHARED_LIBADD के लिए खोज = और की जगह

-licui18n -licuuc -licudata -licuio

द्वारा उस लाइन में

/usr/स्थानीय/आईसीयू/lib/libicui18n.so.42 /usr/local/icu/lib/libicuuc.so.42 /usr/local/icu/lib/libicudata.so.42/usr/local/icu/lib/libicuio। तो.42

(किसी भी -एलएम-पाथ्रेड को छोड़ दें ... जैसा कि वे हैं)। फिर संकलित करें।
यह जीसीसी/लिंकर को "एसओ फाइलों को खोजने के लिए नहीं बल्कि विशिष्ट लोगों का उपयोग करने के लिए" बताता है। परिणाम वही होना चाहिए जैसे आपका लाइब्रेरी पथ काम कर रहा था (SONAME का बेक्यूज)।
लेकिन हर बार जब आप चलाते हैं ./configure आपको फिर से "ठीक करें" लागू करना होगा।

दूसरा समाधान: अन्य libicuXY.so symlinks को हटाएं (यही वह जगह है जहां "बैकअप" शब्द दिमाग में आता है), केवल libicuXY.so- > libicuXY.so.42.0.1 लिंक रखें। यदि कोई अन्य libicuuc.so-> > libicuuc.so.34.x.y लिंक करता है तो gcc/linker उन्हें नहीं ढूंढ सकता है और पुराने संस्करणों के खिलाफ लिंक नहीं करेगा।
फिर से पुराने संस्करण के खिलाफ जुड़ा हुआ SONAME संपत्ति बाइनरी के कारण अभी भी कार्य करेगा क्योंकि "उनका" लोडर libicuXY.so.34 फ़ाइलों (अभी भी मौजूद) की खोज करेगा।
यह बाद के सभी लिंकर रनों को प्रभावित करेगा, यानी यदि आप एक और प्रोजेक्ट बनाते हैं जो पुरानी फ़ाइलों का उपयोग करता है तो आप उसी समस्या में दूसरी तरफ दौड़ेंगे। हेडर फाइलें और साझा ऑब्जेक्ट्स (लिंक समय पर) मेल खाना चाहिए।

Answer 2

जब आप

export LD_LIBRARY_PATH=/usr/local/icu/lib 

फोन तो आप वर्तमान में सेट पथ अधिलेखित कर रहे हैं। तो यह हो सकता है कि इसे आईसीयू मिलेगा लेकिन इसे अन्य पुस्तकालयों में से कोई भी नहीं मिलेगा। ऐसा करें:

export LD_LIBRARY_PATH=/usr/local/icu/lib:${LD_LIBRARY_PATH} 

कि मदद नहीं करता है अगर मैं दो बातों के बारे में सोच की कोशिश कर सकते हैं:

1. सही जगह में पुस्तकालय है? शायद आपकी स्थापना कहीं और, /usr/local/lib/icu की तरह चली गई?
2. क्या आईसीयू काम करता है? आईसीयू के लिए "चेक करें" लक्ष्य आज़माएं। आईसीयू के साथ शामिल परीक्षण सूट को संकलित/चलाने का प्रयास करें, या एक छोटा आईसीयू उदाहरण संकलित करने और चलाने का प्रयास करें। This presentation (PPT) में कुछ छोटे उदाहरण हैं।

संपादित

मुझे लगता है कि मैं इसे समझ से बाहर। ऐसा लगता है कि php-intl केवल libicu 3.6 या 3.8 के साथ काम करता है। मैंने कभी भी लिनक्स डिस्ट्रो शिपिंग php-intl के लिए googled किया है और वे सभी libicu 3.8 पर भी निर्भर करता है जब भी वे libicu 4.0 या बाद में शिपिंग कर रहे हैं। last changelog before intl became part of php itself समान इंगित करता है।

मैं libicu 3.8 स्थापित करने और फिर से प्रयास करने का सुझाव देता हूं।

Answer 3

एक अच्छा मौका है कि ld नहीं जानता कि उन पुस्तकालयों को कहां मिलना है। आपको या तो LD_LIBRARY_PATH (प्रत्येक बार) अपडेट करना होगा, या ldconfig को अपनी नई लाइब्रेरी सीखना होगा।

आप या तो:

• /usr/स्थानीय/lib या में यह स्थापित करें/usr/lib
• इसके स्थान /etc/ld.so.conf और में जोड़े दोबारा चला/sbin/ldconfig

अभी, भले ही ldconfig जो कुछ भी स्थापित पुस्तकालय द्वारा चलाया गया था, ldconfig अपने स्थान का पता नहीं है क्योंकि/usr/स्थानीय/आईसीयू/lib इसके दायरे में नहीं है होगा। यदि पुस्तकालय/usr/local/lib/icu में स्थापित किया गया था, ldconfig को पता चलेगा कि इसे कहां ढूंढना है, और आपको मैन्युअल रूप से एलडी पथ निर्दिष्ट नहीं करना होगा।

मैं ld.so.conf को संशोधित करने से पहले लाइब्रेरी को/usr/local/lib में चलाने और ldconfig चलाने की अनुशंसा करता हूं, हालांकि यह संशोधित करने के लिए कि आप इसे काम करना चाहते हैं, तो फ़ाइल को कोई बड़ा वर्जित नहीं है।