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ó;)
- NevemTeve blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Medvére vadásznál...?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
[fingercross]Ha a PHP forrása deklarál egy ilyen változót, akkor feltételezhetően nem használja a definiált külső makrót, szóval lehet, hogy egy precedáló #undef rem_size megoldja a problémát.[/fingercross]
- A hozzászóláshoz be kell jelentkezni
Köszi, ilyesmivel próbálkozom: egy scriptet tákolok, ami configure-tól 'make install'-ig mindent tartalmaz, most egy ilyen részt tettem bele:
sed_repl '17a\
#undef rem_size
' ext/sockets/sendrecvmsg.c
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
És akkor itt is backupoltad az eredeti forrást? Én még mindig a diff / patch kombóra szavaznék, ha sikerül lebuildelni, akkor amúgy is jó lenne, mind az AIX-nek, mind a PHP projektnek, ha commitelnéd a patchedet...
- A hozzászóláshoz be kell jelentkezni
És íme:
ld: 0711-317 ERROR: Undefined symbol: .zip_encryption_method_supported
collect2: error: ld returned 8 exit statusPró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 hozzászóláshoz be kell jelentkezni
Tuti, hogy a libzip verzió a ludas és nem az, hogy a -lzip nem eredményez találatot, mert nincs benne a pkg_config path-jeiben? Ha igen, akkor megspórolhatnád a cmake-es szopást.
- A hozzászóláshoz be kell jelentkezni
Van libzip, meg is találja, de tényleg kicsit régi, 1.3.2
- A hozzászóláshoz be kell jelentkezni
Fasza, az pont az utolsó verzió, ami nem függ a cmake-től. Valószínűleg nem véletlenül mellékelték akkor azt...
- A hozzászóláshoz be kell jelentkezni
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-3Az 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 )
- A hozzászóláshoz be kell jelentkezni
Objecteket nem generált egy darabot sem? Ha ugyanannyi fájlod van utána, mint előtte, akkor lehet, hogy beakadt, de amúgy lehet, hogy csak kényelmesen elszuttyogott valamin...
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Mindenesetre az új libzip új xz-t is óhajt (5.0.5 a jelenlegi, 5.2.5-öt próbálok)
- A hozzászóláshoz be kell jelentkezni
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 ..- A hozzászóláshoz be kell jelentkezni
OFF
Ezt hogy ejted ki:
AIX-on
?
- A hozzászóláshoz be kell jelentkezni
(én magyarosan: [aikszon])
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni