új Apache, új gondok...

 ( NevemTeve | 2014. február 6., csütörtök - 12:37 )

Komponensek:

AIX-5.2
httpd-2.4.7
apr-1.5.0
apr-util-1.5.3

Problémás rész:

/usr/local/src/httpd-2.4.7/srclib/apr/libtool --silent --mode=link \
    gcc  -pthread  -mtune=native -maix32 -std=c99 \  
        -Wl,-brtl  -L/usr/local/lib -lcpotlas -Wl,-brtl,-brtllib -lrtl \
        -Wl,-blibpath:/usr/local/lib:/usr/lib:/lib -Wl,-brtl \   
        -o mod_cache_socache.la \
        -Wl,-bI:/usr/local/src/httpd-2.4.7/server/httpd.exp \
        /usr/local/src/httpd-2.4.7/srclib/apr-util/libaprutil-1.la \
        -rpath /usr/local/libexec/apache2 -module -avoid-version \
        mod_cache_socache.lo

Probléma:

ld: 0711-317 ERROR: Undefined symbol: .ap_cache_cacheable_headers_out
ld: 0711-317 ERROR: Undefined symbol: .ap_cache_cacheable_headers_in

A kérdéses függvények a cache_util.c-ben laknak (*/httpd-2.4.7/modules/cache alkönyvtárban vagyunk).

20140206.1158: Arról nem volt szó, hogy linuxon sem fordul! Az 'XML_StopParser' hiányzik neki.
Megnéztem az expat.so -mat, tényleg nincs benne ilyen... Régi lenne a 2.0.1? Akkor majd innen szerzek újat: http://sourceforge.net/projects/expat/files/expat/2.1.0/

20140206.1633: expat oké, linuxon fordul.
a cache-util a mod_cache.so (ill. mod_cache.la) modulba kerül bele, tehát valószínűleg ezt kell függőségként megadni a többi modul linkelésénél. (A másik eset az lenne, ha megengednénk az unresolved externeket, de ez valamiért nem tetszik nekem.) Már csak meg kellene keresni, hogy melyik Makefile illetékes. Természetesen nem az, amelyik ebben a könyvtárban van, az bosszantóan egyszerű lenne.

20140206.1713: */httpd-2.4.7/build/config_vars.mk a nyerő, ezt kellene rajta elkövetni:

s;^MOD_CACHE_.*_LDADD =$;& mod_cache.la;

20140206.1738: És működik! Akkor már csak a PHP-5.4.24 van hátra...

20140207.0855: PHP-5.4.23 működik, házi bővítményekkel együtt. Akkor kész vagyunk.
Illetve majdnem kész, ugyanis az egész frissítés azzal kezdődött, hogy ImageMagick-ot szerettem volna a PHP-be (és ha már hozzányúlunk, akkor frissítsünk is persze). Namostan kiderült, hogy az ImageMagick nem gyógyul bele a PHP-be, mint mondjuk az OCI8, hanem valamilyen további feketemágia szükséges... úgyhogy megyek is olvasgatni.
http://hu.php.net/manual/en/imagick.installation.php
http://hu.php.net/manual/en/install.pecl.intro.php
http://pecl.php.net/package/imagick

20140207.1004 Az imagick-3.1.2 fordítása során csak egy érdekes hiba volt:

libtool --mode=link gcc -o imagick.la ... && \
    mv -f .libs/imagick.so ./imagick.so
libtool --mode=install cp imagick.so /moduledir/

Gondolom, ezzel azt akarta kifejezni, hogy a libtool csak a shared objectet telepítse, de az imagick.la file-t ne... ezt inkább átalakítom ilyesmire:

libtool --mode=link gcc -o imagick.la ...
libtool --mode=install cp imagick.la /moduledir/
rm /moduledir/imagick.la

persze az utolsó sor elhagyása sem akkora gond...

20140207.1044: Viszont egy ponton el kell ismernem a kudarcot: nem tudom szerkesztéskor feloldani a imagick.so unresolved externjeit; mégpedig azért, mert a PHP futhat önállóan, ekkor a főprogramból (/usr/local/bin/php) resolválódnak a 'zend_strndup' szerű elemek, és futhat Apache-pluginként, ekkor a /usr/local/libexec/apache2/libphp5.so-ból.

20140207.1126: Érdekes, most látom, hogy a phpize nevá komponens használja az autoconf-ot is, akármi is az. Vajon honnan van nekem olyan az AIX-on?
Később: nahát, én telepítettem forrásból, kb egy éve...

20140207.1148 Pótkérdés: debian squeeze-ben honnan (milyen csomagból) kellene /usr/lib/libgomp.so legyen? Mert ebben nincs: libgomp1 (Mondjuk symlinket még tudok csinálni.)

20140207.1220 Egész jók vagyunk, betöltődött a PHP-be az imagick is, meg a házi bővítmény is, egy apró trükk van csak, nevezetesen hogy a PHP ext-libjében fordított bővítmények valami istenhátamögötti helyre kerülnek (/usr/local/lib/php/20100525-zts), amit én nem szeretnék a php.ini/extension_dir-ben megadni, mivel verziófüggőnek tűnik. A gond az, hogy a saját bővítmény természetesen nem itt van, hanem a /home/projects/lib-ben.
A megoldás az lesz, hogy az extension_dir-t hagyjuk a csodába (ekkor a default pont a 20100525-zts lesz), hanem a bővítményeknél (ahol írja, hogy nem kell path), megadjuk a path-t is a saját bővítménynél:

extension=imagick.so
extension=/home/projects/lib/libGlobusPni.so

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Egyszer nem lesz munkád, csak meg kell tanulnod gyapjat növeszteni, elsőrangú birka lennél ;)
(Bocs, nem sértésnek szántam, de ilyen mérhetetlen türelmet emberben ritkán találni :) )

Sajnos a hibakeresés egy ilyen ipar: nehéz, de hálátlan munka;)

(Persze ez semmi a régi szép időkhöz képest, amikor BS2000-ben a 'source nincs, hiba van' szerű bugreportokkal kellett foglalkoznom. Az is ment valahogy, olyanokat hibákat találtunk például, hogy a SNI programozója valahol SYMBOL=(R3) helyett SYMBOL='(R3)'-at írhatott, vagyis nem a regiszter által mutatott mezőben kereste a nevet a kernel, hanem az '(R3)'-at vette literálnak, és valahogy nem talált ilyet...)

R22- n PL/I és COBOL programok hibáit volt szerencsém memória dumpok alapján visszakeresni. De azok milliószor egyszerűbb rendszerek voltak. Ahhoz még volt türelmem. Ez már... vagy csak meg kellene ismerni és akkor nem tűnne ennyire bonyolultnak?

Így van... egy hosszú betanulási idő van, amíg semmi látszatja az egésznek, azután lassan kezd azért beindulni a dolog.

CAVE pecl-imagick! Nálam rendszeresen hasaltatja ez a PHP modul az apache-ot. Valamiért verziónként változó. Időnként megjavítják, aztán megint el?%/+"ák.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."