Fordítás (GNU és egyéb) - 2

Az élet igazolni akarta előző megérzésemet, miszerint nem valami szerencsés olyasmiket belehardkódolni az exébe, hogy 'PATH=/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/4.0.2' SHOBJ='libgcc_s.a'... ugyanis új gcc verziót telepítettünk, és most az újrainduláskor nem indult, aminek kellett volna...
(Persze akkor sem lett volna jobb, ha az lett volna benne, hogy 'SHOBJ=/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/4.0.2/libgcc_s.a', hiszen a kedves rpm az update alkalmából leszedi a régi, feleslegessé vált libgcc_s.a-t.)

Note to self: az 'ar'-nak linuxon nincs -X32/-X64 opciója... (bár van egy -X32_64, ami egyben alapértelmezés is)

Szerk: 'nm'-re ugyanez igaz

Szerk: és itt külön van a /lib64 meg /usr/lib64

Emlékeztető magamnak: nyomozni kellene, miért lett az openssl-1.0.1-ből openssl.so.1.0.0?

A 'file' nevű komponenst említettem a múltkor, annak meg az a trükkje, hogy használná az 'asprintf'-ben a '%zu' szekvenciát; de mivel az AIX-nek nincs ilyen asprintf-je, hát a saját hozott asprintf-jét használja. Amelyik nem ismeri a '%zu'-t. Jajjanyám.

Ja, és az openssl-nek (illetve a licryptonak) kell a libz.so
Persze ez csak futáskor derül ki: dlopen-t hív, ha az megtalálja valahol (path nincs -- security?), akkor jó, egyébként nem.

Kieg: az nem segít, ha hozzászerkesztjük az executable-hoz a libz.so-t.

Kieg: a forrásban kommentként benne van, hogy a Windows kedvéért csinálja dlopen-nel (illetve LoadLibrary-val, de ez most mindegy),hogy akkor is menjen, ha nincs zlib.dll

vl írta 2011. október 4-én ('install' működésére):

> > Szóval inkább én szépen másolom, ha az nem megy,
> > akkor törlöm+létrehozom (törölni akkor is lehet, ha busy).

> Inkább temp, generált néven ugyanabba a könyvtárba létrehozni + rename.

> - nem fordulhat elő, hogy a törlés után nem tudod megcsinálni a fájlt
> - egyetlen mikroszekundumig sem lesz olyan állapot, amikor nincs ott a fájl

Nagyon jó meglátás, azzal a kiegészítéssel, hogy egy library esetén eleve meg sem szabad próbálni az open-t (outputra), mert az AIX-szal szemben a linux nem ad ETEXTBUSY-t, hanem engedi felülírni a shared-libet, akkor is, ha használatban van -- csak éppen a használó programok döglenek ki...

Az új linux rendszerem (Debian-6) azzal a jó hírrel fogadott, hogy az 'rpm -bb' megszűnt működni, ott az 'rpmbuild'... Ugye nem is kell mondanom, hogy az AIX-en lévő régebbi rpm-hez nincs ilyen rpmbuild... Mennyire megkönnyítik az ilyen inkompatibilis felesztések a scriptek készítését!

Most hallom, hogy valaki xlc-vel fordít/szerkeszt... ez persze az ő szomorú magánügye, de most összehasonlításképp jó lenne tudnom, hogy mi ott a -Wl,-bmap:mapfile megfelelője. (Vagyis átadni a linkernek némi opciókat.)

Szerk: ájulat! A doksi szerint ugyanúgy!

aix-libtool-ban 5648 sor körül járunk, és lassan megérik a béta-tesztre.

Csak a napló kedvéért: most untam meg, hogy nincs 'diff -u', most következik a GNU diffutils telepítésbe. (Persze forrásból, naná)

Az apache-2.4.3 alkalmából ismét egy kis javítás/szépítés: igenis vannak olyan helyzetek, amikor nincs 'lib' a shared object előtt, pl a mod_cache_disk.so használja a mod_cache.so-t.

---

Persze a régi PHP nem megy az új Apache-csal...

Syntax error on line 235 of /usr/local/etc/apache2/httpd.conf:
Cannot load libexec/apache2/libphp5.so into server:
0509-130 Symbol resolution failed for /usr/local/libexec/apache2/libphp5.so because:
0509-136 Symbol ap_log_error (number 1057) is not exported from dependent module httpd.
0509-136 Symbol ap_log_rerror (number 1058) is not exported from ependent module httpd.
0509-136 Symbol ap_get_server_version (number 1068) is not exported from dependent module httpd.
0509-136 Symbol unixd_config (number 1076) is not exported from dependent module httpd.
0509-192 Examine .loader section symbols with the 'dump -Tv' command.

---

Hasonló nevű szimbólumok persze vannak, pl:
ap_log_error_
ap_log_rerror_
ap_get_server_revision
ap_unixd_config

Gondolom, ennyi változás belefér a verzióváltás szabadságába... vagy mibe...

---

Most éppen a php-5.3.13 újrafordítása sem megy a "meta_ccld" hiánya miatt. (Én még a létezéséről sem tudtam, most meg a hiányával kell szembesülnöm...)

---

Ami egyébként van -- vajon melyik komponens nem találja, és miért nem találja?!

---

Én nem találom. Mármint az én libtoolom. A program nevét vizsgálom, hiszen az opciók értelmezése attól függ.

---

Nyomozásom szerint ez azt jelentheti, hogy valahogy(?) érvényre jutott a --enable-maintainer-zts opció a ./configure során... Az ilyesmi megesik...

---

Nem segített a --disable-maintainer-zts sem. Akkor az UFÓK lehetnek a hibásak.

---

Vagy a szerver verziószáma (aszerint ágazik el a ./configure egy ponton):

$ httpd -v
Server version: Apache/2.4.3 (Unix)

Mai utolsó üzenet:

Syntax error on line 271 of /usr/local/etc/apache2/httpd.conf:
Invalid command 'User', perhaps misspelled or defined by a module not included in the server configuration

Az van ott, hogy "User www-data"... ezzel vajon mi a gond?

No, van új pipacs Apache, multithread és multiprocess közül lehet választani, egyelőre multithread-dal megyünk (mpm_worker), de ha valami gyanús jelet látok, visszamegyünk a régi üzemmódba (mpm_prefork).

Erre a nagy örömre most a PHP-5.4.6 intett be: https://bugs.php.net/bug.php?id=63017

holnaptól innen folyt köv

(PS: dtelnet-1.2.7 érdekel valakit? Nem? Gondoltam.)

Az új PHP első eredménye: htmlspecialchars harmadik paraméterének változott az alapértelmezése. Bővebben itt:

Ékezetes FAQ

Ja és egyes configurék ilyeneket írnak ki:

checking for working fcntl.h... no (bad O_NOATIME, O_NOFOLLOW)

Ki kellene vizsálni ezt is...

Még azt mondja meg valaki, hogy a libstdc++ -szal csak akartam valamit kezdeni, vagy csak erősen rágondoltam, és nem csináltam vele semmit -- legalábbis most, úgy látom, nem megy.

Azt olvasom, hogy 7.x-ben már van dirfd. Ez egy másik megfogalmazása annak, hogy 5.x-ben és 6.x-ben nincs.

Azt mondják ugyanis, hogy a readdir_r előtt egy name_max = fpathconf (dirfd (dir), _PC_NAME_MAX) az igazán kúlos, kevésbé menő a name_max = pathconf (dir, _PC_NAME_MAX) -- ugyanis a dir az változhat is (vö: multitaszk, symlink, stb), akár meg is lehet haxorizálni a programot ilyen módon.

Most már ott tartok, hogy linux-ra is meg akarom csinálni a libtool-t... borzasztó, hogy önnön-magamnak generálom a feladatot;)

Most éppen a -Wl,-rpath,uninstalled-la-dir/.libs-et tettem bele, eddig jó is, de egyben észrevettem, hogy a -R opció még nem megy

Következő kötözködés (m4 fordítása):

checking whether rename honors trailing slash on destination... no
checking whether rename honors trailing slash on source... no

Szerintem ez valakinek a fixa ideája, hogy poénból felesleges perjeleket tesz a nevek végére, és ellenőrzi, hogy kap-e hibaüzenetet a különféle rendszerhívásoktól...

Most értesültem róla, hogy a gcc-nek van egy -v opciója, ami nagyon hasznos lehet, hogy megtudjuk, mi is történik a háttérben. Pl:

(legyen $GPATH=/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.6.2 mert rengetegszer ismétlődik)

collect2 -bpT:0x10000000 -bpD:0x20000000 -btextro -bnodelcsect -bexport:/usr/lib/libg.exp -o executable /lib/crt0.o -L$GPATH -L$GPATH/../../.. -brtl -bnortllib -bernotok -bipath -bmap:executable.map ... /usr/lib/librt.a /usr/lib/libc.a $GPATH/libgcc.a $GPATH/libgcc_eh.a -lg -lc $GPATH/libgcc.a $GPATH/libgcc_eh.a

(dőltbetűvel van, amit én adok meg, a többit ő teszi hozzá)

Ilyen már volt egyszer, de most nem találom...

Pro*C üzeni:

Error at line 148, column 2 in file /usr/include/standards.h
#warning The -qdfp option is required to process DFP code in headers.

gdb-7.5 ezzel örvendeztet meg:

cc1: warnings being treated as errors
bfd.c: In function '_bfd_abort':
bfd.c:1047: error: 'noreturn' function does return

"Némely emberi agy egészen másképp működik, mint ahogy azt elvárnánk" (Váncsa István)

Minek tették a CFLAGS-ba a -Werror-t, ha nem gondolták komolyan?!

Elmentem kicsinyég, remélve, hogy a gdb addig lefordul. Le is fordult. Majdnem jól:


$ dump -H $(which gdb) | grep src
3 /usr/local/src/gdb-7.5/bfd/.libs libbfd-2.22.52.20120718.so
8 /usr/local/src/gdb-7.5/opcodes/.libs libopcodes-2.22.52.20120718.so


Na pontosan ennek nem lenne szabad lennie benne, mert a gdb-nek akkor is mennie kellene, ha a forrást törlöm a /usr/local/src-ből.

PS: Megnéztem egy másik gépen a gdb-7.3.1-et, a hiba ott is fennáll. (Ismét igazolódott a régi mondás, hogy hiba csak ott van, ahová nézünk. Vagy fordítva: ahova nézünk, ott találunk egy hibát.)

Nagyobb kompatibilitás miatt a *.la fájlokban ezentúl két dependency_libs lesz, az egyik a hagyományos libtool-nak, a másik önmagunknak, a különbség a la-nélküli libek tárolásában van:

native_dependency_libs=' /orabin/lib32/libclntsh.so'
dependency_libs=' -L/orabin/lib32 -lclntsh'

Na nem mintha kezdeném megkedvelni a hagyományos libtool-t... nemcsak hogy a major-verziókat nem tárolja (az egész projekt ezzel kezdődött ugyebár), de a relatív path-nevek használata is elég furcsán tud kinézni, pl:

$ ldd .libs/rszig
.libs/rszig needs:
         /home/projects/lib/libubio.so
         /home/projects/lib/libdevel_rt.so
         ./.libs/libird.so
         /home/projects/lib/libboci.so

Azsongya nekem a pkg-config, hogy:

/usr/include/pthread.h:666:19: error: unknown type name 'pthread_spinlock_t'

Ez vajon volt már, vagy új?

Persze, igazából csak átnevezem én is...

És már itt is a következő: openssl-1.0.1c

md4_dgst.c: In function 'md4_block_data_order':
md4_dgst.c:111:2: warning: implicit declaration of function 'asm' [-Wimplicit-function-declaration]
md4_dgst.c:111:2: error: expected ')' before ':' token

gengetopt:

g++: internal compiler error: Segmentation fault (program as)

Lehet, hogy ebből egy 'gas' lesz hamarosan?

findutils:

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

ugyanis az 'alloca' nem externként kellene működjön, hanem 'valahogy speciálisan'
Ez a problémát is a -std=c99 opció okozza valamiképpen...
vagy ha effektíve include-oljuk az alloca.h-t (amolyan kultúrember módjára), akkor sincs baj.