Intl desteği ile PHP 5.3.0 yüklenirken sorun oluştu

Question

Şu anda bazı Linux test sunucularına PHP 5.3.0 yüklemeye çalışıyorum. Ac/intl için acilen beklediğimizden, sağladığımız özellikleri kontrol etmek istiyoruz. Ben

./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 

yoğun bakımda 4.2 /usr/local/icu bulunan ve PHP 5.2.9 kusursuz derlenmektedir aşağıdaki argümanlarla başarıyla configure koşuyorum (int- ve icu-seçeneksiz). PHP 5.3.0 kaynağını complie Ama ne zaman bir tür

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' 

Ben paylaşılan kütüphaneler görmediklerine ile bir ilgisi vardır eminim hata mesajlarının bir sürü olsun.

ayarı yardımcı olmuyor.

Birisi bana bir çözüm önerebilir mi? Daha doğrusu clueless - ve ben ... Bunlarla hiçbir gerçek uzman değilim

DÜZENLEME:

Sadece tekrar kontrol ve çeşitli icu-kütüphaneler ve ilgili yumuşak bağlantıların tümü olduğundan emin oldum /usr/local/icu/lib bulunan: testlerinin

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 çalışır ton - başarıyla hepsi:

[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' 

DÜZENLEME: cevapları VolkerK ı kaynağından yoğun bakımda 4.2 yüklü ve ben inşa sürecine yukarıda yazdığı gibi, birim testleri ve kurulum tüm iyi gitti questions

. VolkerK en yorumu ile ilgili

/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 

DÜZENLEME:

Hayır, katılan derleyici hiçbir anahtar olmuştur - ben hem doğrudan birbiri ardına süreçlerini inşa koştu. objdump /usr/local/icu/lib/libicuuc.so.42.0.1 çalışmıyor ya ama bu bilgi yardımcı olabilir bilmiyorum

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

çalıştırmak başardı. VolkerK en edit1 and edit2 üzerinde

DÜZENLEME:

Ben ovmak olduğunu düşünüyorum - sytem başka icu sürümü gerçekten vardır; en azından parçalar halinde (örneğin, başka bir icu-config yoktur; sadece /usr/local/icu/bin numaralı telefon).

gcc -lpthread -lm -L/usr/local/icu/lib -licui18n -licuuc -licudata -lpthread -lm -licuio -print-file-name=libicuuc.so döner

/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 döner

libicuuc.so.42 

Yani sorun, nasıl inşa sürecine yeni lib-yolunu almak için görünüyor süre

?? Bu arada, cevaplarınızdan çok şey öğrendim - hepinize teşekkür ederim.

Ayrıca, basit test programınızı derledim - ve muhtemelen aynı nedenleri olmamakla, aynı sonucu aynı tanımsız başvuru hatayla da başarısız oluyor.

Lib-path'daki eski icu kitaplığına yapılan başvurudan nasıl kurtulabilirim veya yeni icu-kitaplık yoluna nasıl öncelik verebilirim?

Answer 1

Sorun, ikili yanlış (paylaşılan) kitaplık dosyalarına bağlı olması gibi görünüyor.
Problemi düşündüğümün uzun, sıkıcı bir açıklaması. Linux uzmanı olmadığımı unutmayın. Düşüncelerimi anlamanızı istiyorum, böylece mümkün olup olmadığına ve/veya yanlış olduğuma karar verebilirsiniz.
İlk (ham) çözüm kolayca geri döndürülebilir. Başka bir ./configure çalıştırın ve tüm değişiklikler tarih. Bence oldukça tasarruf.

Neden icu 4-2 özgü bağımlılıklarınız var? en

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

hiçbir versiyon özel kod var Şimdiye kadar php'nin intl uzantısı (ext/intl/sesletim/grapheme_string.c) kaynağı dosyasına bir göz atalım. icu 3.4 veya icu 4.2'yi kullanmanız durumunda grapheme_string.c aynı görünüyor. Ubrk_close_4_2 nereden geliyor?
"./configure ... --with-icu-dir =/usr/local/icu" komutunu çalıştırdığınızda, ext/intl/config.m4 dosyası çalıştırılır. Bu işlemde php oluşturmak için gerekli olan içerme yolunu ve kitaplık dosyalarını almak için icu-config çağrılır. Icu yüklemenize giden bir yol sağladıktan sonra, bu

yürütülür. Icu-config'u kendiniz denediniz, bu yüzden çıktılarını ve dolayısıyla ICU_INCS ve ICU_LIBS'nin neleri içerdiğini biliyorsunuz. Dosyalar derlendiğinde/bağlandığında ICU_INCS ve ICU_LIBS gcc'ye aktarılır. gcc (apperently) varsayılan dizinde unicode/ubrk.h bulamadı, bu yüzden icu 4.2 içerdiği ICU_INCS tarafından sağlanan ek dizinlerde dosya için arama yapıldı. unicode/ubrk.h unicode/utypes.h içerdiği unicode/urename.h içerir ve yine icu 4.2 başlık dosyaları eklenmiştir. Bu durumda unicode/urename.h #define ubrk_close ubrk_close_4_2 içerir.
Önişlemci tamamlandığında, ubrk_close (bi), ubrk_close_4_2 (bi) ile değiştirilmiştir.

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

Artık bir sürüm belirli bağımlılık, bir referans bazı kütüphane çözmek zorunda olduğu ubrk_close_4_2 gerekiyor.
Bu yüzden bölüm bölümü işe yarar. Gerçekten de icu 4.2 sürümünüzü buldu ve başlık dosyalarını kullandı. Çok uzak çok iyi.
Şimdi bağlantı parçası için. Senin durumunda ICU_LIBS

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

-licuuc gcc söyler içeriyor "Bana 'icuuc' ve onu kullanan denilen bir kütüphane". gcc, "icuuc" ile eşleşen belirli bir adlandırma şemasına sahip dosyalar için LIB yollarını arar.
Bu durumda libicuuc.so. Sadece libicuuc.so sürümüne özel bir dosya adı aramayacağını unutmayın. Böyle bir dosyayı bulduğunda, başka bir tane aramayacaktır. İlk gcc varsayılan yollarını arar. Daha sonra ek kütüphane yollarını arar - gcc'ye sağladıkları sırayla. Yani

gcc -L/usr/lib -L/usr/lib/yerel -licuuc

orada böyle bir dosya olup olmadığını /usr/lib/libicuuc.so bulacaksınız değil/usr/local/lib/libicuuc.so (artık). Varsayılan yolun veya kitaplık yolu yönergelerinin sırasının, sorununun nedeni olabileceği anlamına gelir.
Programınız paylaşılan nesnelere bağlıyken, koda "özel" bir yükleyici eklenir ve paylaşılan nesnenin adı programınızda (bağlantı zamanında) saklanır.
Programınız her yürütüldüğünde, önce (çalışma zamanı) yükleyici paylaşılan nesneyi (adına göre) arar, kodu yükler ve bazı atlama atlama adreslerinin yerine geçer.
Paylaşılan nesne, linker'ı (bağlantı zamanında) yükleyicinin çalışma zamanında (SONAME özelliği) aradığı paylaşılan nesnenin adını "söyler". söz konusu dosya gcc -licuuc sağlandığında arıyor, sen soru metninde

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 sağlanan listeleme dizinde bir göz atın. Bağlayıcı, sembolik bağlantıyı takip eder ve libicuuc.so.42.0.1'i kullanır. Bu dosya (çalışma zamanı) yükleyicisinin libicuuc.so.42'yi arayacağı bağlantıyı "söyler", bkz. http://userguide.icu-project.org/packaging#TOC-ICU-Versions.
Yükleyici symlink'i takip edecek ve libicuuc.so.42.0.1 dosyasını yükleyecektir veya libicuuc.so.42.0.2 ise libicuuc.so.42.0.3, başka bir hata düzeltmesi varsa, libicuuc.so.42.0.3. libicuuc.so.42, icu 4.2 sembollerini dışa aktaran gerçek bir paylaşılan nesneyi her zaman işaretleyecektir/içermelidir. Kod değişmiş/sabitlenmiş olabilir, ancak dışa aktarılan semboller aynı kalır. Sorununuz şu ki gcc, libicuuc.so- > libicuuc.so.42.0.1'i bulamıyor ancak (diyelim) libicuuc.so- > libicuuc.so.34.x.y. Bu libicuuc.so.34.x.y, icu 4.2 sembollerini dışa aktarmaz, ubrk_close_4_2, ancak ubrk_close_3_4 sağlamaz. Yani, hiçbir ubrk_close_4_2 - > çözümlenmemiş referans hatası.

İlk "çözüm" (ham): ./configure sihrini yapsın ve sonra ... sadece Makefile'yi düzenleyin.
Açık bir metin düzenleyicisinde (kaynak üst dizininde) Makefile, INTL_SHARED_LIBADD aramak = ve değiştirme

-licui18n -licuuc -licudata

satırdaki -licuio

/usr/local/icu/lib/libicui18n.so.42 /usr/local/icu/lib/libicuuc.so.42 /usr/local/icu/lib/libicudata.so.42/usr/local/icu/lib/libicuio. So.42

(herhangi bir -lm -predread ... oldukları gibi bırakın). Tekrar derleyin.
Bu "gcc/linker .so dosyaları için değil, belirli olanları aramak için" söyler. Sonuç, kitaplık yolunuzun çalıştığı ile aynı olmalıdır (SONAME için).
Ancak, her çalıştırdığınızda ./configure, "düzeltmeyi" tekrar uygulamanız gerekir.

İkinci çözüm: diğer libicuXY.so sembolik çıkarın (kelime "yedek" akla geldiği yerdir), sadece libicuXY.so- > libicuXY.so.42.0.1 bağlantıları tutun. Eğer başka libicuuc.so-> > libicuuc.so.34.x.y linkleri yoksa gcc/linker onları bulamıyor ve eski versiyonlara karşı bağlantı kurmuyor.
Yine, eski sürümüne zaten bağlanmış olan SONAME özelliği ikili dosyaları nedeniyle, "kendi" yükleyicisi, (hala var olan) libicuXY.so.34 dosyalarını arayacağı için çalışmaya devam edecektir.
Bu, sonraki tüm linker çalışmalarını etkileyecektir, yani, daha eski dahil dosyaları kullanan başka bir proje oluşturursanız, aynı soruna başka bir şekilde gireceksiniz. Üstbilgi dosyaları ve paylaşılan nesneler (bağlantı zamanında) eşleşmelidir.

Answer 2

o zaman şu anda çizdiği yolu üzerine yazıyorsunuz

export LD_LIBRARY_PATH=/usr/local/icu/lib 

çağırdığınızda. Bu yüzden ICU'yu bulabilir, ancak ihtiyaç duyduğu diğer kütüphaneleri bulamaz. Bu yerine deneyin:

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

ben denemek için iki şey düşünebilirsiniz yardımcı olmazsa:

1. doğru yerde kütüphane var mı? Belki de kurulumunuz başka bir yere taşındı, bunun yerine /usr/local/lib/icu gibi?
2. ICU çalışıyor mu? Yoğun bakım için "kontrol çek" hedefini deneyin. ICU ile birlikte gelen test paketini derlemeye/çalıştırmaya çalışın veya önemsiz bir ICU örneğini derlemeye ve çalıştırmaya çalışın. This presentation (PPT)'un birkaç önemsiz örneği vardır.

DÜZENLEME

ben bunu çözdüm. Php-intl sadece libicu 3.6 veya 3.8 ile çalışır gibi görünüyor. Linux distro shipping php-intl için googled ettik ve hepsi libicu 4.0 veya daha sonra da gönderildiklerinde bile libicu 3.8'e bağlı. last changelog before intl became part of php itself, aynı şeyi gösterir.

Libicu 3.8'i yüklemenizi ve tekrar denemenizi öneririm.

Answer 3

ld'un bu kütüphaneleri nerede bulacağını bilmemesi için iyi bir şans var. LD_LIBRARY_PATH (her seferinde) güncellemeniz veya yeni kütüphanenizden ldconfig öğrenmeniz gerekir.

yapabilirsiniz ya:

• /usr/local/lib veya kurun/usr/lib
• /etc/ld.so.conf ve onun yerini Ekle yeniden çalıştırma/sbin// usr/local/iCU/lib kapsamı içinde olmadığı için ldconfig

Şu anda, ldconfig kütüphane yüklü olursa olsun tarafından çalıştırıldı bile, ldconfig konumu düşünceleri yok eder. Kitaplık/usr/local/lib/icu öğesine yüklendiyse, ldconfig bunu nerede bulacağını bilir ve LD yolunu manuel olarak belirtmeniz gerekmez.

Kitaplığı/usr/local/lib dizinine yeniden yüklemeyi ve ld.so.conf dosyasını değiştirmeden önce ldconfig komutunu çalıştırmayı öneririm, ancak çalışmayı istiyorsanız yalnızca bu dosyanın mükemmel bir tabu olmadığını değiştirerek.