PHP8 AIX-on

Nyilván nem elsőre fog lefordulni, de azért menni fog.

Kezdetnek: a --with-gd és -enable-zip configure-opciók megszűntek. Az előbbi helyett --eanble-gd és/vagy --with-external-gd használható, az utóbbi helyett --with-zip.

Aztán valahogy a checking for sqlite3_errstr in -lsqlite3 pillanatában elborul az agya, és hozzáad a LDFLAGS-hoz egy -L/usr/local/lib32-t. (Természetesen 19120-ban (akarom mondani, 2020-ban), nem fordítunk 32-bitre, ez valami rosszkor jelentkező nosztalgia lehet a részéről.)

Szerk: nem, egyéni probléma volt, a PKG_CONFIG_PATH volt rosszul beállítva.
 

Viszont van egy olyan configure-opció, hogy --with-libdir=lib64, ettől némi előrelépést remélek.

Szerk: egy további hiba az lehetett, hogy a Linux-hoz készített fordító-scriptet próbáltam. Az egyik fő különbség ez lenne: https://bugs.php.net/bug.php?id=73002

Szerk: megszűnt az --enable-maintainer-zts opció is. Amúgy se értettem, hogy mire jó;)

Hozzászólások

Szerkesztve: 2020. 08. 14., p - 12:10

Na lenne egy ilyen porbléma:


/usr/local/src/php-8.0.0beta1/ext/sockets/sendrecvmsg.c: In function 'zif_socket_cmsg_space':
/usr/local/src/php-8.0.0beta1/ext/sockets/sendrecvmsg.c:299:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before '.' token
   size_t rem_size = ZEND_LONG_MAX - entry->size;
          ^
/usr/local/src/php-8.0.0beta1/ext/sockets/sendrecvmsg.c:299:10: error: expected expression before '.' token
/usr/local/src/php-8.0.0beta1/ext/sockets/sendrecvmsg.c:300:18: error: 'u2' undeclared (first use in this function)

Szerk: derék IBM szerint ez így oké (sys/xmem.h):


#define rem_liobn       uaddr
#define rem_addr        u1._subspace_id
#define rem_size        u2._subspace_id2

Ez a sed_repl saját script? Mert rákeresvén csak a te blogod jön fel rá. Nem tudom, hogy hogy működik (mi az a '17a'?), de ha csak simán sed lecseréli az érintett

size_t rem_size = ZEND_LONG_MAX - entry->size;

kódrészt arra, hogy

#undef rem_size
size_t rem_size = ZEND_LONG_MAX - entry->size;

akkor azt a sed minden egyes build kísérletnél, amikor a script lefut, ki fogja cserélni és a végén hatvannyolcezerszer lesz benne a megelőző #undef rem_size - nem tudom, hogy hogyan preventálod a scriptedben ezt, de kérdem, hogy biztos célszerű ezt a részt sed-del megoldani patch helyett?

Jogos kérdesek;)

Ugyebár az AIX-os sed nem ismeri a `-i` (helyben lecserélés) opciót, tehát tákoltam helyette ezt a sed_repl-et.

Igényesebb esetekben ilyesmit szoktam tenni a scriptbe a haxolasok elé:


for i in Makefile subdir/foo.c bar.h; do
if [ -f "$i.orig" ]; then cp -p "$i.orig" "$i";
else cp -p "$i" "$i.orig"
fi
done
Szerkesztve: 2020. 08. 14., p - 15:09

És íme:

ld: 0711-317 ERROR: Undefined symbol: .zip_encryption_method_supported

collect2: error: ld returned 8 exit status

Próbálnék libzip-et frissíteni, de örömmel látom, hogy a kis majomparádék `cmake`-re váltottak. (Ami, magunk között mondva, egy újabb fősodratú idealizmus.)

exec(): 0509-036 Cannot load program cmake because of the following errors:
        0509-130 Symbol resolution failed for cmake because:
        0509-136   Symbol _ZNSt6thread4joinEv (number 323) is not exported from
                   dependent module /usr/local/lib64/libstdc++.so.6.
...

A cmake build-processze szerintem kicsit lassan halad, ez a folyamat pl. három óra alatt másfél óra CPU-t elpazarolt, gondolom egy nagyon szép és jó végtelen ciklusra.

# bs2stat 19923094
%PID:      19923094   PPID:  23462038   NOW: 2020-08-14.18:35:06
%USERID:   root       GROUP: system     ELAPSED:        02:56:05
%STATION:  pts/0      PRI:   109 20     CPU-USED:       01:43:48
%SIZE(KB): 3452       %MEM:  0.0        %CPU:  7.4
%STATE:    A Active                     WCHAN: -
%CWD:      /usr/local/src/cmake-3.11.4/
%CMD:      /usr/local/src/cmake-3.11.4/Bootstrap.cmk/cmake /usr/local/src/cmake-3.11.4 -C/usr/local/src/cmake-3

Az az érzésem, hogy ez a probléma éledt újjá: https://hup.hu/node/134960
vagyis különféle opciókkal fordított programrészek inkompatibilisek lesznek. A múltkor a -pthreads volt a különbség. (vö http://lzsiga.users.sourceforge.net/aix-linking.html#Q0004 )

Elnézést kérek az alaptalan vádaskodásért, tényleg a pthreads-os libstdc++ inkompatibilitás volt ismét az ok; de most világos, hogy én bénáztam amikor gcc-5.4-et telepítettem: a libstdc++-ből a .../gcc-lib/pthreads/ppc64/libstdc++ -helyett a sima .../gcc-lib/ppc64/libstdc++ -t tettem a /usr/local/lib64

 

Szerk: tehát most a `cmake` saját csodás defaultjai alapján tákolt nekem egy 32-bites libzip-et. Igaz, hogy nem tudom használni, de akkor is hálásnak kell lennem érte.

Szerk: Megtudtam, hogy a CFLAGS változótt figyelembe veszi, így már 64-biten vagyunk. Továbbá szerencsére találtam egy ilyen opciót (a CMakeLists.txt-be tettem):

link_directories(BEFORE /usr/local/lib64 /usr/lib)

Ennél már csak az lenne nagyobb szerencse, ha figyelembe is venné;)

Szerk: Annyit ért el, hogy a 'BEFORE'-t is felvette könyvtárnévnek. Mindjárt kiderül, hogy cmake verziót is növelhetek.

Szerk: Itt lehet fogadásokat kötni, mi ennek a kimenete:

find cmake-3.18.1 -type f | wc -l
a) -1000
b) 1001-3000
c) 3001-8000

Szerk: kiderült, hogy a cmake is használja a pkg-config-ot (vagy legalábbis PKG_CONFIG_PATH változót)

Már maga a cmake fordítása is jóformán mesterséges intelligenciával találja meg a rendszerben a shared-libeket (vagy megtalálja, vagy nem; ha talál valamit, az vagy egyező bitszámú, vagy különböző). Ilyesféle rendkívül kifinomult megoldással probálkozom:

cat >CMakeCache.txt <<DONE
BZIP2_LIBRARY_RELEASE:FILEPATH=/usr/local/lib64/libbz2.so
CURL_LIBRARY_RELEASE:FILEPATH=/usr/local/lib64/libcurl.so
EXPAT_LIBRARY:FILEPATH=/usr/local/lib64/libexpat.so
LIBLZMA_LIBRARY_RELEASE:FILEPATH=/usr/local/lib64/liblzma.so
ZLIB_LIBRARY_RELEASE:FILEPATH=/usr/local/lib64/libz.so
DONE

Jó, hát a libzip egyes komponenseit így is a /usr/local/lib32-be tette a cmake, de bizonyára jószándékúan.

/usr/local/lib32/cmake/libzip/libzip-config-version.cmake
/usr/local/lib32/cmake/libzip/libzip-config.cmake
/usr/local/lib32/cmake/libzip/libzip-targets-noconfig.cmake
/usr/local/lib32/cmake/libzip/libzip-targets.cmake
/usr/local/lib32/libzip.so
/usr/local/lib32/pkgconfig/libzip.pc

Szerk: Na ez hiányzott:

cmake -DCMAKE_INSTALL_LIBDIR=/usr/local/lib64 ..
Szerkesztve: 2020. 08. 17., h - 10:44

Szóval PHP8 oké, de az imagick-3.4.3 nem fordul. Majd megnézem a 3.4.4-et, hátha.
https://pecl.php.net/package/imagick
Szerk: és a httpd sem egészen indult el a php8-cal, úgyhogy egyelőre marad a 7.4.9, folyt köv.

Szerk:

/usr/local/src/php-8.0.0beta1/ext/imagick/php_imagick_file.h:61:108: error: expected ';', ',' or ')' before 'TSRMLS_DC'
zend_bool php_imagick_file_init(struct php_imagick_file_t *file, const char *filename, size_t filename_len TSRMLS_DC);

Szerk: Most pillanatnyilag itt tartunk:

export CPPFLAGS="$COMMON_CPPFLAGS -DTSRMLS_C= -DTSRMLS_CC= -DTSRMLS_D=void -DTSRMLS_DC="

De ez sem elég. Szóval amíg nincs újabb imagick, addig php8 is ráér.

Szerk: de addig is, amíg a kísérletezés tart, megkérem, hogy ne autoaktíválja a libphp.so-t a httpd.conf-ban (Nyomasek Bobó kérésére itt már nem libphp8.so van, hanem libphp.so), majd valahogy összeszedem lelkierőm, és megcsinálom kézi erővel.