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

Fórumok

Egy kis BLOG, ha nem zavar senkit.

Hozzászólások

Aktuális célom a Midnight Commander 4.7.0.7 fordítása. Ehhez a következő lépéseket találtam hasznosnak megtenni:

A gcc által telepített /usr/local/lib/gcc-lib/*/*/include/ -ból a stdlib.h és stdio.h törlése: bizonyára valamiféle segítségképpen települtek, de csak zavarnak; a stdlib-ből például hiányzik az atoll deklarációja.

libiconv-1.13.1: fordítás+telepítés
gettext-0.17: fordítás+telepítés
libiconv-1.13.1: fordítás+telepítés

itt némi ismétlődés látszik lenni, de ennek megvan az oka: ez a két csomag kölcsönösen függ egymástól, bizonyíték:

$ ldd $(which gettext)
/usr/local/lib/libiconv-1.13.1.a(libiconv.so.2)
/usr/local/lib/libintl-0.17.a(libintl.so.8)

$ ldd $(which iconv)
/usr/local/lib/libiconv-1.13.1.a(libiconv.so.2)
/usr/local/lib/libintl-0.17.a(libintl.so.8)

libidn-1.9: fordítás+telepítés
pcre-8.01: fordítás+telepítés
pkg-config-0.23: fordítás+telepítés
glib-2.16.6: fordítás+telepítés
slang-2.2.2: fordítás+telepítés, használva a USE_TERMCAP opciót, mert a TERMINFO-val nem megy jól
mc-4.7.0.7: fordítás+telepítés

tesztelés:
$ ldd $(which mc)
/usr/lib/libdl.a(shr.o)
/usr/lib/libcurses.a(shr42.o)
/usr/local/lib/libslang-2.2.2.a(libslang.so.2.2.2)
/usr/local/lib/libpcre-8.01.a(libpcre.so.0)
/usr/local/lib/libintl-0.17.a(libintl.so.8)
/usr/local/lib/libgcc_s.a(shr.o)
/usr/local/lib/libiconv-1.13.1.a(libiconv.so.2)
/usr/local/lib/libcpotlek-0.0.0.a(libcpotlek-0.0.0.so)
/usr/local/lib/libglib-2.0-2.16.6.a(libglib-2.0.so.0)
/usr/lib/libpthreads.a(shr_xpg5.o)
/usr/lib/libpthreads.a(shr_comm.o)
/usr/local/bin/mc
/usr/lib/libcrypt.a(shr.o)
/usr/lib/libc.a(shr.o)
$ mc
működik, keretek szépek, ékezetes betűk működnek
$ LC_ALL=hu_HU.ISO-8859-2 mc
mint az előbb, csak magyar szöveggel

Ja, a gcc-lib mappa alatti stdio az azert van ott, hogy az implicite forditott printf meg ilyenek is mukodjenek. Ezert van az peldaul, hogy a gcc nem szol be egy ilyen forrasra, csak warningol:


int main(int argc, char **argv) {
    printf("Hello, implicit printf!\n");
}

--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Közben elgondolkodtam, mit is kellene tenni ahhoz, hogy ne csak *.a könyvtárakban lévő shared objekthez lehessen linkelni, hanem standalone *.so fájlokhoz is.

Elsőre ezt a megoldást találtam:

$ gcc -Xlinker -bdynamic -Xlinker -brtl -o exe3 main.o -L$HOME/lib -lrutd
$ ldd exe3
exe3 needs:
/home/zsiga/lib/librutd.so
/usr/lib/libc.a(shr.o)
/usr/lib/librtl.a(shr.o)
/unix
/usr/lib/libcrypt.a(shr.o)

Ez persze még nem maga a végső tökély, ha egyszer az összes szoftver (de főleg a libtool) abban a meggyőződésben él, hogy AIX-en shared object csak ar-library-ban lehet.... Lehetőleg verziószám nélküli library-ban.

Az unzip-5.52 azzal lepett meg, hogy probléma nélkül lefordult. kb ennyi:

# gtar -xzvf unzip552.tar.gz
# cd unzip-5.52
# cp unix/Makefile .
# make generic
# make install

Milyen vason , milyen AIX -en próbálkozol ?

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

Valóban, lehet standalone shared libeket használni, ez igen jó dolog, valami ilyesmi a kulcs hozzá: ./configure előtt (a libiconv-ot választottam a teszthez):

export LDFLAGS="\
-Wl,-brtl\
-Wl,-blibpath:/usr/local/lib:/usr/lib:/lib"

(az utóbbi csak azért, mert a gcc szeretné a saját borzasztóságos könyvtárait is belehardkódolni a programba, csak hogy színesítse a dolgokat)

De azért így sem papsajt: a keletkező iconv használja a libiconv-ot, valahogy így:

$ ldd /usr/local/bin/iconv
/usr/local/bin/iconv needs:
/usr/local/lib/libiconv.so
/usr/lib/libc.a(shr.o)
/usr/lib/librtl.a(shr.o)
/usr/local/lib/libcpotlek.a(libcpotlek.so.0)
/unix
/usr/lib/libcrypt.a(shr.o)

ugyanez linuxon:
linux-gate.so.1 => (0xb788b000)
libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0xb7797000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb763c000)
/lib/ld-linux.so.2 (0xb788c000)

Vagyis (a linuxtól eltérően) az exébe nem kerül be a verziószám (illetve annak 'major'-része)...

A telepített shared libek azonosak a két gépen:

$ ls -l /usr/local/lib/libiconv*
/usr/local/lib/libiconv.so -> libiconv.so.2.5.1
/usr/local/lib/libiconv.so.2 -> libiconv.so.2.5.1
/usr/local/lib/libiconv.so.2.5.1

Linux-ban ez úgy történik, hogy a shared-lib-ben van egy SONAME mező, az executable-ban meg egy NEEDED mező, és ennek alapján találnak egymásra:

$ readelf -a /usr/local/lib/libiconv.so | grep SONAME
0x0000000e (SONAME) Library soname: [libiconv.so.2]
$ readelf -a /usr/local/bin/iconv | grep NEEDED
0x00000001 (NEEDED) Shared library: [libiconv.so.2]
0x00000001 (NEEDED) Shared library: [libc.so.6]

Ha egy alverzió-változás történik (2.6.7, mondjuk), akkor az exék a libiconv.so.2 szimlinket követve automatikusan a friss libet fogják használni, ha viszont a főverzió változik (3.0.1, pl), azt csak az újonnak fordított programok érik el.

Pillanatnyilag nem látom, hogyan tudnám ezt AIX-ben megvalósítani (libtool-lal, hiszen minden shared produkt azt használja)... [Pontosabban, egyszer már megcsináltam egy apró kerülővel (lásd a legelső hozzászólást), de hátha menne egyszerűbben is]

AIX-on 'readelf'-hez hasonló eszköz a 'dump -H', két példa:

1. 'házigányolt' iconv, a shared objectek verziószámos könyvtárban:

***Import File Strings***
INDEX PATH BASE MEMBER
0 /usr/local/lib:/usr/lib:/lib
1 libc.a shr.o
2 libpthread.a shr_comm.o
3 libpthread.a shr_xpg5.o
4 libintl-0.17.a libintl.so.8
5 libiconv-1.13.1.a libiconv.so.2

(a legelső nyilván a libpath. Hogy a pthread hogy ment bele, arra nincs ötletem.)

2. -brtl opcióval fordított iconv, standalone shared object

***Import File Strings***
INDEX PATH BASE MEMBER
0 /usr/local/lib:/usr/local/lib:/usr/lib:/lib
1 libiconv.so
2 libc.a shr.o
3 librtl.a shr.o

(Látszik, hogy az iconv-hoz nem tárol semminemű verzószámot, még annyit sem, mint az előbb, vagyis hogy libiconv.so.2. Meg az is, hogy az intl nincs benne (vö: kölcsönös hivatkozás)).

Arra gondolok, hogy amikor a libtool végrehajt egy olyan parancsot, hogy

../libtool --mode=link gcc -L/usr/local/lib -Wl,-brtl -g -O2 iconv.o ../srclib/libicrt.a /usr/local/lib/libiconv.la -o iconv

abból azt generálja, hogy

gcc -Wl,-brtl -g -O2 -o iconv iconv.o ../srclib/libicrt.a -L/usr/local/lib -liconv

Na akkor a saját jó édes /usr/local/lib/libiconv.la fájljából belekeverhetné a major-verziószámot, és generálhatná azt is, hogy

gcc -Wl,-brtl -g -O2 -o iconv iconv.o ../srclib/libicrt.a -L/usr/local/lib -liconv.2

(Persze igaz, hogy nincs is /usr/local/lib/libiconv.2.so, csak usr/local/lib/libiconv.so.2, dehát ezek az apró különbségek amúgy sem számítanak, ha egyszer úgyis arról beszélünk, hogy nem csinálja így.)

E blog létrejöttét hajlamos vagyok annak tanúságaként értékelni, hogy a linuxoid fejlesztők eddig is szartak, és ezután is szarnak a hordozhatóságra. Nagyon szomorú, hogy a gcc-t egyáltalán fel kellett tenni. (Az erőfeszítés előtt persze le a kalappal.)

Emiatt nemrég volt egy parázs vitám egy fejlesztő komával. Kifejtettem neki, hogy amikor "szabad akaratomból" fejlesztek, akkor mindig az a felhasználó van előttem, aki egy UNIX(R)-tanúsított proprietary OS-en rendelkezik mezei user account-tal, a rendszergazdához esetleg nem is nagyon szólhat, és azzal kell főznie, ami van. (Ami persze egyáltalán nem kevés, lásd SUSvX!) Sajnos nem találom most a linket, de valamelyik GNU eszköz dokumentációja explicite kijelenti, hogy minden más rendszerre fütyülni kell; a fő szempont a GNU userland minél teljesebb kihasználása és a kényelmes fejlesztés. A GNU projekt politikai céljaként ezt elfogadom, de független hobbifejlesztésben ezzel azonosulni nagyon gáz.

Az autoconf-ot a unix háborúk alatt kezdték fejleszteni. 95 óta van rendes UNIX műszaki szabvány (SUSv4.2), de persze miért is alapoznánk olyan specifikációra a hordozhatóságot, amelyben a unix vendor-ok megegyeztek, maradjunk inkább az összetákolt dinamikus felfedezőszkriptnél. Modnom, tőlem aztán használja a GNU a saját projektjeiben, de amikor egy független pkg megpróbál ./configure-ral indulni, és vagy elfekszik maga a script, vagy lefut a script és a make esik utána pofára, akkor kicsit megkérdőjeleződik előttem a független fejlesztő épelméjűsége.

Ezt most nem igazán értem... ahogy én látom, minden UNIX változat egyéni hisztikkel rendelkezik a shared librarykat illetően (lásd pl itt: http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html), de az AIX még így is különösen egzotikusnak számít közöttük a *.a-libekbe helyezett *.so objektekkel.

Talán nem volt elég világos, de a következő (szerinted talán elvetemült linoxid és GNU-mániás) célom van:

Ha lefordítom a foobar-2.3-t, akkor keletkezzen a /usr/local/lib-ben:
- libfoobar.a # statikus linkhez
- libfoobar.2.3.so # dinamikus könyvtár
- libfoobat.2.so # szimlink az előzőre, ez van belekódolva az exébe
- libfoobar.so # szintén szimlink az előzőre, dinamikus linkeléshez

Sőt, ez még semmi, azt is akarom, hogy ha telepítem a foobar-3.4-et, akkor az új elemek települjenek ugyanoda, de a régi verzióból az alábbi kettő változatlanul megmaradjon, hogy a régi exék zavartalanul működjenek tovább:
- libfoobar.2.3.so
- libfoobat.2.so

Nem hiszem, hogy ezek olyan furcsa és szokatlan igények lennének.

Hát igen, igen, elég összefüggéstelen volt a hozzászólásom. A legfontosabb, hogy egyáltalán nem a postodat vagy a tevékenységedet kritizáltam, hanem annak apropóján felugrottam a kedvenc vesszőparipámra, és azon nyargalásztam egy kicsit.

A shared lib-ek elkészítése, plusz a telepítés cakk-pakk nem részei a SUS-nak. Vagyis ezek nincsenek szabványosítva. A .so-khoz való C nyelvű hozzáférés (dlopen() és tsai) igen, de a telepítés teljesen adminisztrátori téma; arról nem szól a SUS.

Amin én pörgök, az inkább az, hogy a programozók a C és sh forrásaikba mit írnak. A libtool-lal akár még el is lennék (persze csak akkor, ha szabványkövetően használná a platform fordítóját, azoknál a feladatoknál, ahol a szabvány igenis nyilatkozik, pl. fordítás és végső linkelés), de az autoconf arról szól, hogy megvan-e ez vagy az a függvény, meg milyen szignatúrával.

Okulási célzatú kérdés, autoconf-ot, libtool-t ismerő embertől.
Ha portábilisen szeretne hobby-fejleszteni valaki, akkor szerinted milyen eszközökkel álljon neki egy fájdalommentesebb portolás érdekében? Mondjuk cmake-ről mi a véleményed? Te mit kedvelsz (mármint programozáshoz)?

Üdv:
Dw.

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

Nem hiszem, hogy tudnék neked olyat mondani, amiből tanulhatnál :)

Én a forrás (C és sh, awk, lex, yacc stb) elkészítésénél valamelyik SUS-ra hagyatkoznék. A fordítást egy teljesen explicit, pedáns Makefile vezérli. A Makefile-hoz a függőségeket gcc-vel generálom, de az nem baj, mert az fejlesztési időben történik, a végfelhasználóra nem ró terhet. Shared lib-ek létrehozásával nem foglalkozom. Ami nem fér bele a SUS által adott keretekbe, az nekem már nem hobbi, hanem vagy 0x00, vagy pedig munkahelyi feladat. Munkahelyen pedig van (legyen) forrás a portolásra, ott akármit lehet használni, csak jól meg kell gondolni.

C++ természetesen szóba sem jöhet hobbira. Egyszerűen nem létezik szabvány, amely a UNIX(R) API-t ötvözné a C++ nyelvvel. (Valamivel szerényebben: nem tudok ilyenről.)

Arról nem is beszélve, hogy C++-ban C++-ban programozunk, nem C-ben, tehát kezdhetjük az összes OS-szintű erőforrást wrapper-ekbe csomagolni, hogy részt tudjanak venni a RAII-ben, kivételkezelésben stb. Akkor mindjárt használhatnánk Qt-t vagy boost-ot is. Sok sikert bármelyik lefordításához egy 1999-es, SUSv2-re certifikált, olyan-amilyen C++ fordítóval rendelkező rendszeren. (A C++ nem része a SUS-nak, így a tanúsítványhoz egyáltalán nem kell a C++ fordítónak jónak lennie.)

Az autotools, gnulib hiába veszi célba ugyanazt, amire én vágyok (akárhol vagyok, kicsomagolom és forduljon), gyakran a saját kód méretének többszöröse az autotools sallangja. Sok extra kód, sok hibalehetőség, sok frissíteni való függőség. A GNU projektnek ez belefér, mert egy kézben van az egész projekt-csokor, ők ezekkel az eszközökkel időt és nyűgöt takarítanak meg, ahogy akármelyik cég is, amely saját keretrendszert fejleszt 12 alkalmazásához. Hobbira túlzásnak, és sok szerencsétlen esetben aktívan károsnak tartom.

Ha belekerül a hobbiprojekt valamelyik GNU/Linux disztróba, vagy valamelyik proprietary UNIX(R) felhasználói gyűjteményébe, akkor amúgy is a packager fogja hozzáidomítani a rendszerhez. Lehet az ember maga a packager (ha van hozzá idegzete és rendszerhozzáférése, az a legjobb), de akkor a disztró-specifikus cruft a disztró-specifikus patchset-ben van. Az én hobbi-makefile-jaimban nincs is install target, van viszont a tarball-ban lehetőleg részletes INSTALL ésvagy README.

A +1000 általában igaz, csak AIX esetében van még egy momentum: elméletileg a linuxoidok szarhatnak is, mert elméletileg az L betű azt jelentené, hogy AIX alatt a linuxoidok kódjait gyerekjáték futtathatóba áttenni - a gyakorlat meg az, hogy az egyáltalán nem egységsugarú NevemTeve kartácsnak mindig van ezzel kapcsolatban érdemi mondani- vagy kérdeznivalója.

Nahát, köszönöm, mindig is fúrta az oldalamat, mi az az L. Ezek szerint a "Linux affinity".

Hogy ezen nem fordul néhány csomag helyből, az azért is különösen gáz, mert a fentebb linkelt, tanúsított rendszerek listájában az AIX 5L megkapta a UNIX 98 Server-t, a UNIX 98-at, illetve a UNIX 03-at is. (Utóbbit az AIX 6 is megszerezte, úgy látom.)

Ha emlékeim nem csalnak, blogoltál te hasonlókat már index-fórumon is, meg itt is. (Lehet, másutt is, én itt futottam beléjük.)
Helyes, subscribe.

Ahogy így nézelődtem itt hup.hu-n, nem én vagyok az egyetlen, aki beleszaladt AIX-on a shared library-kba, legfeljebb az egyetlen, aki próbál valamit tenni az ügyben (de legalább az álszerénység nem tartozik a hibáim közé)...

Persze szívesen venném, ha mások is írnának a tapasztalataikról... mittomén, pl hogy a Midnight Commanderben mit kell haxolni, hogy a menükben magyar ékezetes betűk megjelenjenek (a gyári isprint-et saját változatra cserélni), a keretrajzoló karakterek jól jelenjenek meg (a slang-ot megkérni, hogy a termcap-ot használja, mert a terminfo nem megy neki), vagy hogyan szerezzünk egy BSD-kompatibilis install-t (a coreutils csomagból természetesen, de ha óvatosak akarunk lenni, nevezzük át ginstall-ra, a programok úgyis megtalálják, és nem ütközik a gyárival).

PS: persze minden hozzászólásnak örülük, annak is, aki szerint a bash, az Apache, a PHP meg a többi csupa hobby-projekt.

PS: persze minden hozzászólásnak örülük, annak is, aki szerint a bash, az Apache, a PHP meg a többi csupa hobby-projekt.

Valamit nagyon elronthattam, ha így értetted az általam írottakat.

Azt próbáltam kifejteni, hogy kisebb kaliberű hobbiprojektnél az autotools overkill, sokszor pedig nem is segít. Semmit sem állítottam a fent nevezett programokról. Ahogy említettem, a hozzászólásod eszembe juttatta a kedvenc vesszőparipámat, és onnan szabad asszociációk útján egy teljesen független hozzászólással spammeltem meg a blogodat.

Azzal egyetértek, hogy ha szervezeti szinten fejlesztünk egy komoly projektet, akkor valószínűleg van rá forrás, és van rá igény is, hogy azokat a funkciókat is ellássuk valahogy, amelyeket a SUS nem fed le. Például shlib-ek készítése, vagy telepítés. Viszont az autotools (pontosabban itt talán libtool) kudarcát mi sem jelzi jobban, mint az, hogy a fenti projektek (+ mc) rendes felrakásához kézzel kellett tempóznod, és elkezdtél írni egy saját eszközt.

Ennyi. Én nem az AIX-ról beszéltem, és nem is az mc-ről / apacsról. Az autotools-t kritizáltam, önmagában. (Kiegészítés: plusz természetesen azt, hogy a GNU/Linux-on nevelkedett fejlesztők csak az autotools ill. GNU/Linux által nyújtott felülettel foglalkoznak.)

Tegnap este unalmamban elkezdtem egy projektet (ami valószínűleg félbemarad, de hátha...), ami egy libtool-klón lenne C-ben, kifejetten AIX-hez, de verziókezeléssel. Jelenleg 772 sor, de még nem tud semmit, csak annyit, hogy ismerkedik a paramétereivel, pl:

be:
./aix-libtool --mode=link gcc -L/usr/local/lib -l cpotlek -Wl,-brtl\
-Wl,-blibpath:/usr/local/lib:/usr/lib:/lib -g -O2 -fvisibility=hidden\
-o libcharset.la -rpath /usr/local/lib -version-info 1:0:0 -no-undefined\
localcharset.lo relocatable.lo

ki:

mode='link' 2
in1='localcharset.lo'
out='libcharset.la'
ver='1:0:0' 1:0:0
rel=''
>>> rpath-list:
1: /usr/local/lib
>>> ldir-list:
1: /usr/local/lib
>>> lib-list:
1: cpotlek

0 'gcc'
1 '-L/usr/local/lib'
2 '-lcpotlek' (problémás, ok=#6)
3 '-Wl,-brtl'
4 '-Wl,-blibpath:/usr/local/lib:/usr/lib:/lib'
5 '-g'
6 '-O2'
7 '-fvisibility=hidden'
8 '-o'
9 'libcharset.la' (problémás, ok=#4)
10 '-no-undefined'
11 'localcharset.lo' (problémás, ok=#1)
12 'relocatable.lo' (problémás, ok=#1)

Ebből a vége az a paraméterlista, amit majd a gcc-nek át kell adni (látható, hogy kimaradt a -rpath meg a -version-info), az eleje pedig az, amit ő maga megértett az egészből:
mode = mit is kellene csinálni (string-ként és számikusan)
in1 = első input (fordításnál hiányozhat az output, ebből kell kitalálni)
out = output
ver = -version-info (string-ként és számikusan)
rel = -release
rpath,ldir,lib listák: a parancssorban talált összes -rpath, -L és -l értéke

Verziószámok:
a libtool-nak két opciója van, ami releváns lehet, a -release és a -version-info. Az utóbbi szerkezete a következő:
-version-info CURRENT:REVISION:AGE
például a libiconv-1.4 esetében ez 7:1:5 aminek a jelentése valami olyasmi, hogy ez a 7-es főverzió, de kompatibilis a 7-5=2-vel (és attól felfelé), és azon belül 1-es alverzió. Szóval végső soron ebből lesz a

/usr/local/lib/libiconv.so.2.5.1
/usr/local/lib/libiconv.so.2 -> libiconv.so.2.5.1
/usr/local/lib/libiconv.so -> libiconv.so.2.5.1

(vagyis a major verziószám lesz a 7-5=2, a minor pedig az age+'.'+revision = 5.1)

Keletkezik továbbá a libiconv.la, benne ilyesmik:

dlname='libiconv.so.2.5.1'
library_names='libiconv.so.2.5.1 libiconv.so.2 libiconv.so'
old_library='libiconv.a'
inherited_linker_flags=''
dependency_libs=' -L/usr/local/lib -lcpotlek'
current=7
age=5
revision=1
installed=yes
libdir='/usr/local/lib'

Ebből a kiemelt részek tűnnek most fontosnak, vagyis ha azt látom az inputban, hogy '-liconv', akkor megkeresem a libconv.la-t (ha van egyáltalán), abból kisakkozom, hogy '/usr/local/lib/libiconv.so.2' és azt passzolom tovább a linkelésnek, aki belehardkódolja az exébe ezt a nevet, és megvalósul a verziókezelés... talán...

Még nem nagyon vagyunk sehol (1045 programsor), egyelőre ennyi a jelenség:

be:

./aix-libtool --mode=compile --tag=CC gcc -pedantic -Idevel/src -Iserver3/src -Iisode/src -D__UNIX__ -D__unix__=1 -Dnl_langinfo=local_nl_langinfo -Disprint=local_isprint -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_ALL_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -g -W -Wall -Wno-long-long -mpowerpc -maix32 -c ./aix-patch.c

ki:

libtool: gcc -pedantic -Idevel/src -Iserver3/src -Iisode/src -D__UNIX__ -D__unix__=1 -Dnl_langinfo=local_nl_langinfo -Disprint=local_isprint -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_ALL_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -g -W -Wall -Wno-long-long -mpowerpc -maix32 -c ./aix-patch.c -o ./aix-patch.o

libtool: gcc -pedantic -Idevel/src -Iserver3/src -Iisode/src -D__UNIX__ -D__unix__=1 -Dnl_langinfo=local_nl_langinfo -Disprint=local_isprint -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_ALL_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -g -W -Wall -Wno-long-long -mpowerpc -maix32 -c ./aix-patch.c -o ./.libs/aix-patch.o

Vagyis a fordítást megcsinálja kétszer, de *.lo file-t még nem ír. (És még nem linkeltünk meg installáltunk.)

Ez nem tom megvan-e:
https://www.midnight-commander.org/ticket/1957

Naív kérdés: libtool nélkül nem lehet forgatni egyébként?

Üdv:
Dw.

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

> Ez nem tom megvan-e

Igen, ilyesmi apró hibák előjönnek, toldozgatni kell...

> libtool nélkül nem lehet forgatni egyébként?

Nem, mivel bele van építve a mc-be (meg minden másba is). És nem is látom, hogy mi lenne az előnye.

> Érdekes: nem beszél shared library szívásokról...
Addig nincs is gond, amíg van egy-egy rögzített libiconv, gettext, pcre, slang stb verzió, és azokat sosem akarjuk frissíteni... mert ha igen, akkor a verziószám nélküli *.a fájlokban lévő *.so-k miatt bármi is történhet... esetleg maga a 'make' vagy az 'install' vagy a 'sed' fogja azt mondani, hogy, hoppá, el sem indulok

Hétvége van, csak annyit dolgoztam, hogy a fájlnév-feldaraboló programot külön modulba tettem. Valami ilyesmit tud:

Inp='/tmp/def.c'
Total= '/tmp/def.c'
Path= '/tmp'
File= 'def.c'
Core= 'def'
Ext= 'c'

Inp='./.libs'
Total= './.libs'
Path= '.'
File= '.libs'
Core= '.libs'
Ext= ''

Még dolgozgatok (1205 programsor C-ben), ilyesmit tud:

be:
./aix-libtool --mode=link gcc -L/usr/local/lib -liconv -Wl,-brtl\
-Wl,-blibpath:/usr/local/lib:/usr/lib:/lib -g -O2 -fvisibility=hidden\
-o aix-patch.la -rpath /usr/local/lib -version-info 1:0:0 -no-undefined\
aix-patch.lo

ki:
libtool: creating static lib: ar crus .libs/aix-patch.a aix-patch.o

libtool: linking shared object: gcc -L/usr/local/lib -liconv -Wl,-brtl -Wl,-blibpath:/usr/local/lib:/usr/lib:/lib -g -O2 -fvisibility=hidden -o .libs/aix-patch.so.1.0.0 .libs/aix-patch.o -shared

.libs/aix-patch.so.1 -> aix-patch.so.1.0.0 created
.libs/aix-patch.so -> aix-patch.so.1.0.0 created

Következő lépés a .la és a .lai létrehozása, azzal már majdnem a felénél leszünk...

Még él a projekt, 1496 programsor.

Épp most írta ki nekem, hogy:

$ ./aix-libtool --mode=install cp libalttest.la ~/lib
Installing libalttest.la -> /home/zsiga/lib
.libs/libalttest.lai -> /home/zsiga/lib/libalttest.la 909 bytes copied
.libs/libalttest.a -> /home/zsiga/lib/libalttest.a 37872 bytes copied
.libs/libalttest.so.2.5.1 -> /home/zsiga/lib/libalttest.so.2.5.1 41017 bytes copied
symlink /home/zsiga/lib/libalttest.so.2 -> libalttest.so.2.5.1 created
symlink /home/zsiga/lib/libalttest.so -> libalttest.so.2.5.1 created

Ez is valami... (1614 programsor)

Jelenleg --mode==install esetén nem hív külső programot, de valóban gondolkozom azon, hogy ha a program az install (vagy ginstall), akkor azt hívja meg a .la, .a és .so.2.5.1 fájlok másolására... persze a paraméterlistát értelemszerűen meghaxolva. (Arra például már figyelek, hogy a -o opció ebben a kontextusban nem az outputfájlt jelenti.)

Szerk: mit jelent a '-c' opció? A GNU-install szerint 'ignored', az AIX-install szerint '-c outputdir' formában használandó, ha hangsúlyozni akarjuk, hogy csak új install lehet, felülírást nem akarunk.

Megcsináltam, bár a '-m' opcióval harcoltam egy jót: amit a user megad, azt egyelőre ignorálom, inkább a saját kútfőmből saccolom meg a jogbiteket... a rendes libtool is ezt csinálja

./aix-libtool --mode=install ginstall -o zsiga -g devel -m 0700 libalttest.la ~/lib
Installing libalttest.la -> /home/zsiga/lib
libtool: install: ginstall -o zsiga -g devel .libs/libalttest.lai /home/zsiga/lib/libalttest.la -m0644
libtool: install: ginstall -o zsiga -g devel .libs/libalttest.a /home/zsiga/lib/libalttest.a -m0644
libtool: install: ginstall -o zsiga -g devel .libs/libalttest.so.2.5.1 /home/zsiga/lib/libalttest.so.2.5.1 -m0755

Most elgondolkoztattál, de azután rájöttem, hol van a hibalehetőség:

$ ginstall -- -m0666 /tmp
ginstall: cannot stat `-m0666': No such file or directory

Megcsináltam a 'beszúrás a parancs mögé' feature-t, most ilyen:

$ ./aix-libtool --mode=install ginstall -o zsiga -g devel -m 0700 libcpotlas.la ~/lib

Installing libcpotlas.la -> /home/zsiga/lib
libtool: install: ginstall -m0644 -o zsiga -g devel .libs/libcpotlas.lai /home/zsiga/lib/libcpotlas.la
libtool: install: ginstall -m0644 -o zsiga -g devel .libs/libcpotlas.a /home/zsiga/lib/libcpotlas.a
libtool: install: ginstall -m0755 -o zsiga -g devel .libs/libcpotlas.so.0.0.0 /home/zsiga/lib/libcpotlas.so.0.0.0

PS: sordb=1712

Igen, pontosan erre gondoltam. A parametersorrend nem azert olyan, amilyen, mert valakinek ez a heppje, hanem mert ez kvazi mindenutt (legalabbis a legtobb helyen) mukodik. Ezt erdemes nagyon szem elott tartani, ha kulso eszkozokkel dolgozunk.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Mostanában kellene eldönteni, hogy a verziószámot libtool-osan kezeljem-e, vagy házibarkács módra:
libtool-os: libvalami.so.2.5.1, libvalami.so.2, libvalami.so
házilagos: libvalami-2.5.1.so, libvalami-2.so, libvalami.so

Az előbbi előnye a kompatibilitás, de hátránya, hogy linkeléskor a '-lvalami'-t arra kell kicserélni, hogy /path/libvalami.so.2; az utóbbi inkompatibilis, viszont linkeléskor simán '-lvalami-2'-t lehet belőle csinálni.

Most, pihenésképpen azon töröm az agyam, hogy hogyan lehetne a shared objektből kiszedni ezt:

$ dump -H libxa.so

/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.4.5:/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.4.5/../../..:/usr/lib:/lib

valószínűleg csak hiszti a részemről, de azért nem bánnám, ha én mondhatnám meg, hogy akarom-e ott látni... (vagy mondjuk, isten ments, át akarom vinni a kész programot egy másik gépre (ahol nincs gcc, vagy más verziójú), amilyen perverz vagyok)

Nem tudom, kifejezetten erre van-e opciója.
Közben viszont támadt egy olyan érzésem, hogy az 'install' lesz a leggyengébb láncszem... ugyanis nem másolja át a shared lib-et, ha az használatban van (Text file busy), akkor nem installál; ekkor a derék felhasználó kézileg kell töröljön, és aztán... és lehet, hogy nincs 'aztán', mert amit törölt, anélkül nem fut pl. az install vagy a make (pl.: /usr/local/lib/libiconv.a).
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).

Ez azért nem annyira rossz:

$ aix-libtool --mode=link gcc -g -o xab ab.o ~/lib/liba.la ~/lib/libb.la
libtool: linking: gcc -Wl,-brtl -Wl,-brtllib -g -o xab ab.o /home/zsiga/lib/liba.so.1 /home/zsiga/lib/libb.so.1

$ ldd xab
xab needs:
/home/zsiga/lib/liba.so.1
/home/zsiga/lib/libb.so.1
/usr/lib/libc.a(shr.o)
/usr/lib/librtl.a(shr.o)
/unix
/usr/lib/libcrypt.a(shr.o)

$ dump -H xab
***Import File Strings***
INDEX PATH BASE MEMBER
0 /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.4.5:/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.4.5/../../..:/usr/lib:/lib
1 /home/zsiga/lib liba.so.1
2 /home/zsiga/lib libb.so.1
3 libc.a shr.o
4 librtl.a shr.o

(sordb=1891)

Most ugyanez másképp:

$ aix-libtool --mode=link gcc -g -o xab ab.o -L$HOME/lib -lxa -lxb
libtool: linking: gcc -Wl,-brtl -Wl,-brtllib -g -o xab ab.o -L/home/zsiga/lib /home/zsiga/lib/libxa.so.1 /home/zsiga/lib/libxb.so.1

Vagyis levadászta a .la fájlokat, és helyettesítette őket .so-val.

$ ldd xab
xab needs:
/home/zsiga/lib/libxa.so.1
/home/zsiga/lib/libxb.so.1
...
(sordb=1980)

És akkor itt van még a non-installed .la fájllal való linkelés... ilyenkor olyasmi kerül bele az executabléba, hogy ../libcharset/.libs/libcharset.so.1 -- hát, azért ez nem egészen tökéletesen tökéletes... csak úgy példaképpen: ha kilépünk abból a könyvtárból, ahol a linkelés történt, akkor nem találja meg a kérdéses so fájlt...

libiconv lefordult, települt, most a gettext lázadt fel:

/bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -release 0.18.1 ../intl/libintl.la -L/usr/local/lib -liconv -R/usr/local/lib -lpthread -L/usr/local/lib -liconv -R/usr/local/lib -lc -L/usr/local/lib -liconv -R/usr/local/lib -L/usr/local/lib -liconv -R/usr/local/lib -lxcurses -L/usr/local/lib -lcpotlas -Wl,-brtl -Wl,-blibpath:/usr/local/lib:/usr/lib:/lib -o libgettextlib.la -rpath /usr/local/lib set-mode-acl.lo ... libcroco_rpl.la libglib_rpl.la libxml_rpl.la

a gond az, hogy nálam nem készült libcroco_rpl. Na igen, ha nincs -version-info, akkor nem kell *.so, de azért *.la-t kellene csinálni.

További baj, hogy a libtoolnak olyat is kellene tudnia, hogy a fenti parancs vigrehajtásakor fogja a libcroco_rpl.la -t, temporális könyvtárba kibontja, és a benne lévő objecteket sorolja fel a parancssorban

Ebben az esetben nem executable-t (sem shared objectet) linkelünk, hanem az egyik.a-ból meg a másik.a-ból és egy csomó *.o-ból csinálunk egy harmadik.a -t: mivel ilyet az 'ar' nem tud, temporálisan szét kell szedni az egyik.a-t meg a másik.a-t.

Egyébként ez a gettext jócskán megf...t próbára tesz: minden, amit eddig nem tartottam fontosnak benne van (pl: -release opció, dependency_libs, relink_command)...

Electric Fence: a Makefile-ban ilyesmit érdemes hangolni:

INSTALL= ginstall
LIB_INSTALL_DIR= /usr/local/lib
MAN_INSTALL_DIR= /usr/local/share/man/man3

utána 'make install' és használható

Bevallom, eddig export-fájlt sem csináltam, gondoltam, csak exportál magától mindent, ami entry... most már ezt sem látom ilyen egyszerűnek, inkább követem az igazi libtool-t.

Kérem szépen:

$ ./aix-libtool --mode=link --tag=CC gcc -version-info 7:1:5 -g -Wl,-brtl -o libalttest.la alttest.lo -rpath ~/lib

libtool: creating static lib: ar crus .libs/libalttest.a alttest.o
libtool: creating export file: nm -B -BCpg .libs/alttest.o
libtool: 4 lines written into '.libs/libalttest.exp'
libtool: linking shared object: gcc -Wl,-G -Wl,-bexport:.libs/libalttest.exp -g -Wl,-brtl -o .libs/libalttest.so.2.5.1 .libs/alttest.o -shared

(sordb=2523 -- azért ilyen sok, mert egy kis popen-szerűséget gányoltam hozzá)

Nos, működik a -version-info és a -release tetszőleges kombinációja, továbbá megcsináltam a -Wl,-soname -Wl,libvalami.so.1 opciót is, hátha linuxon is fogjuk használni a programot.

Némi definíció (így a projekt félidejénél lassan időszerű):

-'normális' (teljesértékű, installálható) libvalami.la libtool könyvtár az, aminek a linkelésében volt -rpath (.la-ban: libdir=)

- ami nem 'normális', az a 'convenience', azt kell róla tudni, hogy nem lehet installálni (.lai nem is képződik), viszont működik vele ez az automatikus kibontás dolog, ha további linkeléshez használjuk

- ha linkeléskor volt '-static', akkor csak statikus archív keletkezik (.la-ban: library_names='')

- ha linkeléskor nem volt '-static', akkor statikus achív és shared object is keletkezik

a .la-ban a dependency-be azokat teszi be, akik:
1. a parancssorban '-lvalami'-ként bukkantak fel, és nem talált hozzájuk .la-t.
2. talált hozzájuk .la-t (vagy eleve .la volt megadva), és abban a library_names nem üres (vagyis van shared object)

Ja és ha egy installálatlan libraryt használva linkelünk egy másikat, akkor a hívóban értelemszerűen más került a .la-ba és a .lai-ba: az előbbibe a hívott aktuális helye lesz, az utóbbiban a hívott végleges helye, pl:

dependency_libs=' -L/usr/local/lib -lz -lefence /usr/local/lib/libiconv.la /home/zsiga/lib/librutd.la /home/zsiga/libtooltest/librut7d.la'
dependency_libs=' -L/usr/local/lib -lz -lefence /usr/local/lib/libiconv.la /home/zsiga/lib/librutd.la /home/zsiga/lib/librut7d.la'

És ilyenkor keletkezik egy ilyen is:

relink_command="(cd /home/zsiga/libtooltest; /bin/sh /usr/local/bin/libtool --mode=relink gcc -g -L/usr/local/lib -o liblinktest.la -rpath /home/zsiga/lib -version-info 5:1:2 linktest2.lo -lz -lefence -liconv -lemi /home/zsiga/lib/libruts.la /home/zsiga/lib/librutd.la ./librut5s.la ./librut7d.la @inst_prefix_dir@)"

Nyilván van rá kész eszköz (realpath, pl; bár nem egészen, mert ez a változat csak stringekkel dolgozik, nem nézi, hogy valódi fájlokról van-e szó, se nem old fel szimlinkeket), de összecsaptam egy rutint, ami path-okat egyszerűsít, pl:

../../../usr/local/../include/..//x/./y/./z/. -->
../../../usr/x/y/z

/../../../usr/local/../include/..//x/./y/./z/. -->
/usr/x/y/z

Ez biztos jó lesz majd valamire a programban.

Most már egy kicsit késő van, de valami galadságot vélek látni a gyári libtool-ban: linkelek egy programot oracle-klienssel (vagyis -L/ott/ahol/van/OraHome/lib32 -lclnsth opciókkal), előáll a program -- csak nem fut, mert nem találja a shared objectet... ha megadom a libtool-nak a -R/ott/ahol/van/OraHome/lib32 opciót is, akkor jó lesz... namostan meg kellene nézni, hogy ez linuxban is ilyen-e, mert ha igen, akkor ez béna...

linuxon volt a kísérlet a legegyszerűbb, ott be sem került az executable-ba az útvonal; nyilván lehetne erőltetni (gcc -R opciójával, pl), de egyébként a /etc/ld.so* alapján találja meg a betöltő a librarykat.

Mérések AIX-en (a siker ellenőrzése így történik:
dump -H locimin | grep '/orabin' -- ha van találat, akkor jó libpath került be az executable-ba (locimin a neve)).

1. gcc -L/orabin/OraHome_Current/lib32 -lclntsh -L/usr/local/lib -lcpotlas -Wl,-brtl devel/lib/devel.a -o locimin ocimin.o
Ez jó. Naná, a gcc tudja hogy mit csinál;)

2. libtool --mode=link gcc -L/orabin/OraHome_Current/lib32 -lclntsh -L/usr/local/lib -lcpotlas -Wl,-brtl devel/lib/devel.a -o locimin ocimin.o
Ez nem jó. A lcpotlas-nak vagy a .so meg egy .la fájlja, az utóbbiban szerintem nincs semmi különös (kipróbáltam más libekkel is, ugyanez a jelenség)

3. Pont ugyanez, a libcpotlas.la törlése után: jól működik. (A továbbiak kedvéért a törlést visszacsinálom).

4. libtool --mode=link gcc -L/orabin/OraHome_Current/lib32 -lclntsh -L/usr/local/lib/libcpotlas.la -Wl,-brtl devel/lib/devel.a -o locimin ocimin.o
Ez ismét jó.

Vagyis ha nincs .la file, akkor jók vagyunk (csak nem jönnek be automatikusan függőség, ugyebár), vagy ha van .la fájl, akkor az szerepeljen a a parancsban. Hát, nem tudom, hogy ez most bug-e vagy feature.

Most nézem, hogy amit a négyes pontnál leírtam, mint működő verziót (és tényleg működik is!) az szintaktikus hiba, helyesen így lenne:

libtool --mode=link gcc -L/orabin/OraHome_Current/lib32 -lclntsh /usr/local/lib/libcpotlas.la -Wl,-brtl devel/lib/devel.a -o locimin ocimin.o

És persze ez nem is jó.

Jaja, ilyenek vannak:

$ ls -1F /usr/local/lib/libcpotlas*
/usr/local/lib/libcpotlas.a
/usr/local/lib/libcpotlas.la
/usr/local/lib/libcpotlas.so -> libcpotlas.so.0.0.0
/usr/local/lib/libcpotlas.so.0 -> libcpotlas.so.0.0.0
/usr/local/lib/libcpotlas.so.0.0.0

A szerkesztés meg így megy:
libtool --mode=link gcc -L/orabin/OraHome_Current/lib32 -lclntsh /usr/local/lib/libcpotlas.la -Wl,-brtl -o locimin ocimin.o

libtool: link: gcc -Wl,-brtl -o locimin ocimin.o -L/orabin/OraHome_Current/lib32 -lclntsh -L/usr/local/lib -lcpotlas -Wl,-blibpath:/usr/local/lib:/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.4.5:/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.4.5/../../..:/usr/lib:/lib

Közben valamilyen lelki okból előreléptem az Oracle klienssel 9-ről 10-re, persze az új Pro*C-nek új problémái is lettek... például, nem érti, mi az, hogy __const

A 'libtool'-ban megkerestem ezt:

hardcode_libdir_flag_spec="\${wl}-blibpath:

és az egyenlőségjel mögötti részt kommenté alakítottam. Ocsmány gányolás, fúj. Viszont így megy.

Ha két '-rpath' van egy libtool-parancsban, az baj?
A gettext fordítása során találkoztam ezzel a jópofasággal. Mondjuk egyformák, úgyhogy inkább legyünk nagyvonalúak.

Van még egy shared lib, ami némi gondot okoz, ez pedig a
libgcc_s.a(shr.o)
ami valami olyasmi kézenfekvő helyen lakik, hogy
/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.4.5/libgcc_s.a
ezt a gcc nem mindig linkeli dinamikusan, valamilyen opciótól függ,
illetve programnyelvtől függ (C++-nál eleve dinamikus).
Namost nekem a libgettextlib-0.18.1.so -ban benne van mint dependencia,
még nem tudom, hogy miért, illetve hogy ez baj-e.
Annyiban biztosan, hogy ha átvisszük a programot egy másik gépre, ahol a gcc
nincs meg, vagy más a verziója, akkor persze nem fut.

A libgcc.so-ról más (nem linuxos) platformon ugyanez a tapasztalatom: egyes programoknak kell (ha gcc-vel készültek), és ilyenkor a libgcc.so nélkül nem tudnak futni. Ilyenkor a program dependenciái közé fel kell venni ezt is.

Ha jól emlékszem, akkor olyan dolgok kerülnek ezekbe, mint pl. std floating point műveletekhez platformonként szükséges extra külső függvények (pl. double a * b-hez használja a gcc egyes platformokon, ahol cpu fajtától függően más-más utasításokat kell végrehajtani).

A C++-nál vannak olyan függvények, amiket hasonlóan használ a compiler, viszont C++-nál a singleton technológiák miatt ezt nem lehet .a formájában többször ugyanabba a programba belinkelni, ezért kell .so legyen.

Közben megnéztem, a -static-libgcc és -shared-libgcc opciók szabályozzák; plusz a fordító saját belátása, C++ és Java esetén (az exceptionök miatt, részleteket nem tudok), csak shared lehet.

Közben hatalmi tébolyomban belinkeltem a /usr/local/lib-be, mert nem tudok megbékélni azzal, hogy ezt az útvonalat hardkódolja bele nekem az exébe...

# cd /usr/local/lib
# ln -s ../../opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.4.5/libgcc_s.a .

Ohm, en ugy tudom, az .a az static lib, vagyis mindig belefordul a kerdeses alkalmazasba, vagy interfesznek hasznalja, mindenesetre elvben dependency nem lehetne soha (ldd kimenetben nem jelenhetne meg), csak a .so kimenetben. Ezert rakjak ilyen ertelmes helyre. Szerintem.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

gettext nem adja olyan könnyen magát, most éppen ott tartunk, hogy nem indulnak a programok (pl: /usr/local/bin/xgettext, /usr/local/lib/gettext/hostname), mert:

exec(): 0509-036 Cannot load program ./hostname because of the following errors:
rtld: 0712-001 Symbol cr_rgb_is_set_to_inherit was referenced
from module /usr/local/lib/libgettextlib-0.18.1.so(), but a runtime definition
of the symbol was not found.

Na, most jött szembe az '-export-symbols-regex' opció...

Az is megvolt. (Programsorok összes száma: 3481)

pcre nevű barátunk azzal lepett meg, hogy C++ könyvtárat is akar fordítani, holott előzőleg gondosan megállapította, hogy nincs c++ fordító a gépen...

--disable-cpp

glib túllépett azon a korláton, amit én naivan felvettem a verziószámokra...

current=1600
age=1600
revision=6

Tudtam, hogy ez is eljön: a glib előállít egy programot, és még installálás előtt futtatni akarja... mivel a libek még nincsenek installálva, hát nem nagyon megy neki...
De sebaj, holnap rászánok pár órácskát, és megfixálom a dolgot...

Azaz, ilyenkor a .libs/exeneve lesz az igazi program, az 'exeneve' meg egy ilyesmi script:

#!/bin/sh
export LIBPATH="/uninstalled/path1:/uninstalled/path2"
exec /usr/local/src/glib2/src/.libs/exeneve "$@"

Persze az install-nál is figyelni kell erre: ha van a .libs-ben ugyanolyan nevű exe, akkor azt kell installálni.

Valami ilyesmi lett belőle:


$ cat xconvcc 
#!/bin/sh

ex_LIBPATH="/home/zsiga/libtooltest/.libs"

if test -z "$LIBPATH"; then
    LIBPATH="$ex_LIBPATH"
else
    LIBPATH="$LIBPATH:$ex_LIBPATH"
fi

export LIBPATH

exec /home/zsiga/libtooltest/.libs/xconvcc "$@"

glib-2.16.6 fordításához kell egy ilyen patch:

sed_repl 's/^#ifdef ENOTEMPTY$/#if defined (ENOTEMPTY) \&\& ENOTEMPTY != EEXIST/' gio/gioerror.c

Ja, és a glib-től szereztem tudomást a -module opcióról... na ez most mi a menő manó?

Ahogy nézem, a hatása kb annyi, mint a -shared-nek, vagyis static lib ne készüljön. Azután itt van még a -avoid-version...

További jelentkező: -export-dynamic. Ez nem mást, mint a -rdynamic gcc opció. Persze AIX-on nem létezik.

A slang nem hallott a CPPFLAGS enviróról, ezért neki így kell:

export CFLAGS="fordító opciói"
export CPPFLAGS="preprocesszor opciói -DUSE_TERMCAP"
export CFLAGS="$CFLAGS $CPPFLAGS"
./configure

Szerk: és a libtool-ról sem hallott, kézi erővel barkácsolja meg a libslang.so.2.2.2-t és a rámutató linkeket, .la fájlt nem ír.

A libtoolize egy kicsit keménynek látszik, inkább gányolok valamit... először a libz-n tesztelem, már fogtam is valamit: a rendes libtool *.o objektekkel is hajlandó dolgozni (nem csak *.lo-val), bár dob egy warning-ot:

*** Warning: Linking the shared library libz.la against the non-libtool
*** objects (lista) is not portable!

de azért megcsinálja. Akkor nekem is így kell csinálnom.

a slang esetében:


(
cd src

aix-libtool --mode=link    \
    gcc ${LDFLAGS} -o libslang.la -rpath /usr/local/lib -version-info 4:2:2 elfobjs/*.o
aix-libtool --mode=install cp  libslang.la /usr/local/lib

cd ../slsh

aix-libtool --mode=link gcc ${LDFLAGS} -o slsh slsh.o readline.o ../src/libslang.la
aix-libtool --mode=install cp  slsh        /usr/local/bin

cd ../modules

MODLIB="/usr/local/lib/slang/v2/modules"

for i in *.so; do
    j=${i%.so}
    aix-libtool --mode=compile gcc ${CFLAGS} -c $j.c
    aix-libtool --mode=link    gcc ${LDFLAGS} -rpath "$MODLIB" -module -avoid-version -o $j.la $j.lo
done
aix-libtool --mode=install cp -f .libs/*.so "$MODLIB"

) 2>&1 | tee log.hazikieg

Kapok egy duplicate symbol __fe_def_env -et, ha két modulban is includálva van a /usr/include/fenv.h.

Az van ott, hogy
const fenv_t __fe_def_env = { FE_TONEAREST, 0, 0, 0, 0 };

Szerintem vagy 'extern' vagy 'static' kellene elé... mondjuk a /usr/libm.a(fenv.o)-ban benne van entry-ként, úgyhogy extern-t csinálok belőle.

Most van egy ilyenem:


# ldd $(which mc)
/usr/local/bin/mc needs:
         /usr/local/lib/libcpotlas.so.0
         /usr/local/lib/libglib-2.0.so.0
         /usr/local/lib/libiconv.so.2
         /usr/local/lib/libintl.so.8
         /usr/local/lib/libpcre.so.0
         /usr/lib/libpthread.a(shr_xpg5.o)
         /usr/local/lib/libslang.so.2
         /usr/local/lib/libz.so.1
         /usr/lib/libc.a(shr.o)
         /usr/lib/librtl.a(shr.o)
         /usr/local/lib/libgcc_s.a(shr.o)
         /usr/lib/libpthreads.a(shr_comm.o)
         /unix
         /usr/lib/libcurses.a(shr42.o)
         /usr/lib/libdl.a(shr.o)
         /usr/lib/libcrypt.a(shr.o)

Megjegyzés: ez a mc-verzió hiba nélkül fordult.

Aztat hazudja nekem a 'touch' linkelése, hogy


ld: 0711-228 WARNING: Duplicate symbols were found while resolving symbols.
        The following duplicates were found:
 Symbol                    Source-File(Object) OR Import-File{Shared-object}
 ------------------------- -------------------------------------------------
 .locale_charset           localcharset.c(../lib/libcoreutils.a[localcharset.o])
    ** Duplicate **        {/usr/local/lib/libiconv.so.2}
    ** Duplicate **        {/usr/local/lib/libintl.so.8}

ez a locale_charset egy saját belső kis rutin kellene legyen, ami benne van különböző komponensekben (iconv, gettext, coreutils), csak éppen nem kellene exportálódjék a shared objectből...

Na jó, vegyük úgy, hogy oké, az openssl-nél nincs libtool és nincs verziókezelés (mondjuk úgy gondolják, hogy minden verzió felülről kompatibilis az összes megelőzővel, lelkük rajta).

Ettől még az engine-jeivel kellene valami kezdeni: nem találják a saját jó libcrypto.so fájljukat.

Később: ez lett


sed_repl "s|LIBDEPS='-L.. -lcrypto \$(EX_LIBS)' \\\\|LIBDEPS='-Wl,-blibpath:/usr/local/lib:/usr/lib:/lib -L/usr/local/lib -lcrypto -lcpotlas' \\\\|" \
    engines/Makefile
sed_repl "s|LIBDEPS='-L\$(TOP) -lcrypto' \\\\|LIBDEPS='-Wl,-blibpath:/usr/local/lib:/usr/lib:/lib -L/usr/local/lib -lcrypto -lcpotlas' \\\\|" \
    engines/ccgost/Makefile
sed_repl "s|LIBPATH|BARMI_CSAK_NE_LIBPASZ|" \
    Makefile.shared

kézenfekvő, furcsa is, hogy nem jöttem rá rögtön.

> Na jó, vegyük úgy, hogy oké, az openssl-nél nincs libtool és nincs verziókezelés

Bár ennek épp az ellenkezője az igaz linuxon:

ldd $(which openssl) | grep ssl
        libssl.so.1.0.0 => /usr/local/lib/libssl.so.1.0.0

Tehát az egész verziószám (0.9.8, 1.0.0 stb) a 'major', és nincs 'minor' rész.

Elméletileg van olyan libtool-opció, hogy

-version-number MAJOR[:MINOR[:REVISION]]

de hogy szereti-e azt, hogy -version-number 1.0.0 azt még ki kellene próbálni

Később: naná hogy nem szereti.

Kieg: az iconv ugyan libtool-t használ, de azért a móka kedvéért a libiconv.a-ba beletesz pár shared objectet is, csak hogy színesítse...

"Nyilván, gondolja magában, a libtool nem érti a dolgát, de majd én segítek, vesszenek a szokványok és szabványok!"

Azt mondja nekem a pkg-config, hogy

/bin/sh ../libtool --mode=link gcc -o libgplugin_a.la -avoid-version -module libgplugin_a.lo[/code]

Vagyis van '-module', de nincs '-rpath'. Az előbbi arra utal, hogy shared object legyen, az utóbbi meg arra, hogy convenince library (ami static). Ki fog nyerni?

Az eredeti libtool ezt csinálja:

ar cru .libs/libgplugin_a.a .libs/libgplugin_a.o
ranlib .libs/libgplugin_a.a
creating libgplugin_a.la
(cd .libs && rm -f libgplugin_a.la && ln -s ../libgplugin_a.la libgplugin_a.la)

A -module csak annyit hatott, hogy került a .la-ba egy ilyen:
# Should we warn about portability when linking against -modules?
shouldnotlink=yes

Szóval asszem nekem is ezt kellene utánoznom...
(Egyébként meg jó kérdés, hogy miért van benne a pkg-config-ban egy glib?)

Midnight Commander-nek van egy további fegyvere, hogy kiszúrjon velünk, azaz megnehezítse a verziószámos linkelést.

5.x-es AIX verzió esetén:

checking where the gettext function comes from... external libintl
checking how to link with libintl...
    /usr/local/lib/libintl.so /usr/local/lib/libcpotlas.so /usr/local/lib/libiconv.so -lpthread

Vagyis úgy dönt, hogy a linkeléshez a shared objectet kell megadni a parancsban...

Ugyanez AIX 6.x-ben:

checking where the gettext function comes from... external libintl
checking how to link with libintl... -lintl -lcpotlas -liconv -lpthread

Ezt persze csak azért csinálja, mert segíteni akar. Hát, kösz.

Később: ezt tettem bele a "do.all"-ba:

sed_repl 's|hardcode_direct=yes|kabbe=yes|' configure
sed_repl 's|hardcode_direct=yes|kabbe=yes|' config/config.rpath

sed_repl "s|hardcode_libdir_flag_spec='|kabbe='|" configure
sed_repl "s|hardcode_libdir_flag_spec='|kabbe='|" config/config.rpath

Ettől megjött a kedve, most így néz ki a dump -H outputja:


                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /usr/local/lib:/usr/lib:/lib                                          
1      /usr/local/lib                libcpotlas.so.0                         
2      /usr/local/lib                libglib-2.0.so.0                        
3      /usr/local/lib                libiconv.so.2                           
4      /usr/local/lib                libintl.so.8                            
5      /usr/local/lib                libpcre.so.0                            
6                                    libpthread.a        shr_xpg5.o          
7      /usr/local/lib                libslang.so.2                           
8                                    libc.a              shr.o               
9                                    librtl.a            shr.o         

Az openssl ügyében meg arra gondolok, hogy egy nem-szabványos bővítménynek jött el az ideje, ez lesz a .la fájlban:

# Version information for libcrypto.
current=1
age=0
revision=0
major='1.0.0'
minor=''

Ennek hatására az executabléba ez kerül:

INDEX  PATH                          BASE                MEMBER
0      /usr/local/lib:/opt/freeware/lib:/usr/lib:/lib
1      /usr/local/lib                libcpotlas.so.0
2      /usr/local/lib                libcrypto.so.1.0.0
3                                    libdl.a             shr.o
4      /usr/local/lib                libssl.so.1.0.0
5                                    libc.a              shr.o
6                                    librtl.a            shr.o

És ha ez megvan, akkor jöhet a nem egészen triviális lépés: akkor is működjön így, ha nincs is la-fájl:

keresse meg a *.so fájlt, nézze meg, hogy szimlink-e valamire, és ha igen, akkor amire mutat, arra mutat-e egy további szimlink is, az alábbi séma szerint:

libvalami.so -> libvalami.so.1.2.3
libvalami.so.1 -> libvalami.so.1.2.3 # ekkor major='1' minor='2.3'
libvalami.so.1.2 -> libvalami.so.1.2.3 # ekkor major='1.2' minor='3'
(nem talált) # ekkor major='1.2.3' minor=''

Ha jól látom, ez igaz az Oracle-ra is...

$ readelf -d /usr/local/OraHome10/lib/libclntsh.so.10.1

Dynamic section at offset 0xa75014 contains 28 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libnnz10.so]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libnsl.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000e (SONAME)                     Library soname: [libclntsh.so.10.1]

Hibát fogtam, próbáljak emlékezni: mode=install esetén csak akkor installálja a shared libraryt, ha egyáltalán van olyan! (Ugyanez a static-ra is.)

Másnap: javítva.

Egy libffi nevű komponenst hiányol a glib legújabb változata, az meg azon pusztul meg, hogy az AIX-os wc -w az output elé betesz pár szóközt is


NUM=$(echo 'apuka lalika' | wc -w); echo =$NUM=
linux: =2=
AIX: = 2=

Esetleg ez majd segít neki:


sed_repl 's/test "$$n" = "0"/test "$$n" -eq "0"/g' Makefile

glib fordításában további hiba a "loff_t" hiánya, ennek megoldása:

./configure elé:
export ac_cv_func_splice=no

Persze ezzel sem megy, a sockaddr_storage
mezőiben nem értenek egyet:

A /sys/socket.h szerint __ss_family van benne,
a gsocket.c szerint ss_family. Erre való a preprocesszor:
CPPFLAGS="-Dss_family=__ss_family"

Most megint fordul...

A pyglib az a python-glib nalam, van, ahol igy hivjak, mar nem tudom, mi a projekt rendes neve.
Amugy lehet, hogy valami helper, es igen, nem rossz, ha egy gepen van python meg perl, ez a ketto kb. minden toolchain-nak resze.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Őszintén mondom: el nem tudom képzelni, hogy mi indítana arra egy programozót, hogy egy package lefordításához python dependenciát építsen a csomagja buildelésébe... már ha persze ha eltekintünk a tudása hiányától, ami azért nem ritka manapság a sok linuxhuszár között.

Nincs olyen build feladat, amit pythonnal meg lehet csinálni, perllel pedig nem. Még azt sem lehet mondani, hogy egyszerűbb a python. Olyan gépet pedig még az életben nem láttam, amin van python, de nincs perl. Ellenben olyat nagyon sokat, amin van perl, de nincs python.

Varj-varj, itt ket kulon dologrol beszelunk. Egyreszt lehetnek a buildelest segito toolok, vannak, amiket pl. egy bootstrap.sh futtathat, illetve lehetnek python bindingek is. Ami kerdes, az az, hogy normal forditas mellett a .py fajlok telepulnek-e (tehat binding, esetleg pelda), vagy csak a buildeles soran hasznalt, esetleg a bootstraphoz kell neki. A masodik esetben igazad van, de az elso es az utolso esetben viszont teljesen normalis, hogy fugg a python-ra, az utolso esetben pl. csak a csomagolo gepen kell python.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ha a buildeléshez szükséges toolok igénylik kötelező módon a pythont, akkor akár kell a futtatáshoz, akár nem, nálam dilettánsok a kódolók: írják át a kódjukat perlbe, az mindenhol van; ha nem tudnak perlben programozni, csak pythonban, akkor inkább C kódot se írjanak, ha kérhetem...

Ha a csomagban vannak telepítendő .py fájlok, akkor azt oldják meg, hogy a configure vegye észre, hogy nincs python, és hagyja ki a .py fájlokat a egész folyamatból.

Igen, de ha csak a packaging-hoz kell (tipikusan az autoconf/automake/etc. folyamatba van valami script beleillesztve), akkor lenyegtelen, mert az csak a csomagolo gepen kell meglegyen, sehol masutt. Lattam mar ilyet is.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Az automake-nek amúgy is kell perl. Továbbra sem látom a létjogosultságát, hogy még egy ugyanolyan cucc bármelyik gépen dependenciaként belenőjön a programba. Függetlenül attól, hogy "csak" a csomagoló gépen kell. Főleg, mert vannak emberek, akik forrásból rakják a cuccaikat. A python létjogosultságát erre a feladatra alapjaiban kérdőjelezem meg.

Ez a teljes topik (blogposzt) tökéletes bizonyíték arra, hogy a GNU autotools mekkora irdatlan bukta a gyakorlatban, amint az ember elhagyja a GNU/Linux-ot. (Természetesen NevemTeve nem erre szánta a posztot, de erre is jó lett.) Mostantól már érvelnem sem kell, elég a linket idéznem.

Szokták mondani, hogy nem az autotools hibája, hogy nem tudják rendesen használni a projektek karbantartói. Sajnos bizonyos mértékig igenis az autotools hibája. Ha már egy központi GNU csomag is rosszul használja:

a configure egy részét a make csinálja (don't ask)

akkor nincs mentség. Vagy lásd ezt. Az autotools csomag ott működik, ahol nincs rá szükség (GNU/Linux-on); ahol kellene, ott meg pofára esik, mert a maintainer elfelejtette az összes nyomorult típust, makrót, függvényt, amit csak használ a kódja, egyesével felvenni követelményként a a configure.ac-ba.

Van persze másik megközelítés is, a gnulib, amely lényegében friss POSIX ill. GNU függvényeket biztosít a forrás számára. Lényegében egy több tíz megás workaround gyűjtemény. Annyit említenék meg róla, hogy nem shared lib-ként használandó, hanem: (1) a még csak nem is bootstrap-elt forrás mellé fel kell nyomni egy friss változatot, (2) a bootstrap során (amikor a ./configure is létrejön) körülbelül 400 file a gnulib-ből bemásolódik a forrásfába, mintegy megötszörözve annak méretét, (3) ezután készül az upstream tarball.

Vegyük észre, hogy: (a) mivel a gnulib forrás másolódik az upstream tarball-ba, azért biztonsági frissítésre esély sincs az alkalmazás új verziójának fordítása nélkül, (b) a bemásolandó file-ok körének (= workaround-oknak) meghatározása nem a ./configure futtatása során (a végfelhasználó környezetében) történik, hanem a tarball összeállításakor. Ez nyilván csak úgy tud működni, ha az égvilágon mindent bemásolunk a tarball-ba, amit a program használ, aztán a configure eldönti a célgépen, hogy kell-e az adott fix, vagy nem. Ettől lesz a tarball ordenáré méretű.

Az alternatíva az lenne, ha a végső build környezetben megkövetelnék a gnulib jelenlétét. Az egyik lehetőség szar, a másik pedig még szarabb.

Sajnos fel kell ismerni, hogy a GNU/Linux tool-okat proprietary rendszereken nem nagyon lehet általánosan fordítani, mert a fejlesztők alapvetően szarnak mindenre, ami nem GNU/Linux; esetleg esélyük sincs hozzáférni. Természetesen lenne alternatíva:

  • kizárólag C-ben és POSIX shell-ben programozni, szigorúan valamelyik SUS-t követve,
  • kivételes esetben lehet perl-t használni, rendkívül visszafogottan; de fordításhoz lehetőleg ne kelljen, legfeljebb fejlesztői munkához,
  • cross compiling-ot felejtsük el (SUS-ban nincs specifikálva),
  • shared lib-eket felejtsük el (SUS-ban nincs specifikálva) -- kivételeket tehetünk olyan rendszerekkel, amelyhez napi hozzáférésünk van, és hajlandóak vagyunk a folyamatos foltozgatással fososkodni. Ha bárkitől elfogadunk olyan patch-et, amely az shlib támogatást olyan rendszerre terjeszti ki, amelyhez nincs saját hozzáférésünk, vegyünk erős, mentolos szájvizet.
  • Az a legjobb, ha a csomagot felkapja egy platformspecifikus disztró. Ekkor az shlib kérdésnek máris van gazdája, már csak arra kell figyelnünk, hogy a platformspecifikus patch-ek upstream-be olvasztási kísérleteit egy jókora furkóval idejében lebunkózzuk. (Ilyen proprietary alapra való disztrót hármat ismerek: Solaris-ra kettőt (sunfreeware és opencsw), valamint HP-UX-ra a PAC-ot. De ahogy látom, AIX-ra is van egy-kettő: ibm, bullfreeware, oss4aix)

Persze a fentiekhez ragaszkodva a fejlesztés "kényelmetlen" lenne, meg nem lehetne kihasználni a sok linuxos goodie-t!!!!111

Van persze másik megközelítés is, a gnulib, amely lényegében friss POSIX ill. GNU függvényeket biztosít a forrás számára.

Ennek "megoldásnak" 2011-ben az én szememben már semmi létjogosultsága nincsen.

Aki 5-10 évnél régebbi unix-okat használ, az ugyan mire számít?
Azok a hiányok pedig, amik még a 90-es években valós problémát okoztak az alternatív unix-okon, azok mostanra elmúltak (meg amúgy is jelentősen megfogyatkozott az alternatív unix-ok listája :)
Egy szó mint száz: nincsenek már olyan tolerálhatóan frissecske commercial unix-ok, amin így kéne segíteni. Ami még létezik, az kellően POSIX meg BSD meg SVR4 amúgy is.

mert a fejlesztők alapvetően szarnak mindenre, ami nem GNU/Linux; esetleg esélyük sincs hozzáférni.

Ez mindig is így volt valahol.
15 évvel ezelőtt annyi volt a különbség, hogy ha valaki megugrotta a dos/win -> unix lépcsőt, akkor szinte biztos, hogy nagyon hamar legalább 2, egymással baromira nem kompatibilis unix-szal sikerült összetalálkoznia, ergó a platform-függés fogalmával hamar tisztába került. Aki meg mindenre szart, az maradt a dos/win/clipper/foxpro/delphi/whatever vonalon.
Mostanra elég mainstream lett a linux, és kellően távoliak a commerciális unix-ok, így fordulhat elő, hogy az anno dos/win szintjén mozgó clueless idióták mostanra linux-only clueless idiótákká fejlődtek...

"Aki 5-10 évnél régebbi unix-okat használ, az ugyan mire számít?"

Ezt ugye nem gondolod komolyan? Valószínűleg Teve kollega szopása csak kismértékben csökkenne, ha egy mai HP-UX 11iv3-n vagy esetleg egy Solaris 11-en próbálná ugyanezeket. (Speciel ha csak azt nézem, hogy a - főleg *BSD-n használt pkgsrc mennyi hekkelést tartalmaz egy-egy "linux-only" program más rendszer alá hegesztéséhez, már fejfájást lehet kapni.)

De az utolsó mondatoddal teljes mértékig egyetértek.

A cross-compilineg azert necces, mert vannak olyan rendszerek, amiken orakat/napokat venne igenybe a kodfordias, pusztan azert, mert azok a rendszerek nem erre vannak kitalalva. Gondolok itt foleg az embedded rendszerekre, ahol azert messze nem trivialis a forditas.

A tobbire +1
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ezt nem vitatom. Mindenesetre embedded rendszerek távolról sem fognak UNIX98-at támogatni. Tehát azok nem csak build host-ként, de build target-ként sem játszanak :) Amikor az ember beágyazott rendszerre fejleszt, akkor nem a SUS-t nézegeti, hanem a konkrét implementáció doksiját -- feltételezem.

Partially. Csakhogy az embedded rendszerekre is kb. ugyanazok a szoftverek kerulnek fel, mint a desktop rendszerekre, legalabbis az alap eszkozok tekinteteben ez feltetlen igy van. A busybox sem mindenhato, vannak appok, amiket nem, vagy nem megfelelo melysegben implemental. Ezeket a desktop verziobol kell forditani (ohm, oke, ebben a kornyezetben nalam a desktop minden, ami nem embedded). Amennyiben a desktop appok nem tamogatjak a cross-compilinget, az embedded rendszerek kb. meg fognak halni a szoftverhianytol.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Az openssl-t egyszer már elkönyveltem megoldottnak, de most mégis valami zavart érzek az erőben...
Van neki egy Makefile.shared-je, abban kínlódik összevissza a LIBPATH és LD_LIBRARY_PATH változókkal. Ennek az az igennagy előnye, hogy kis szerencsével megzavarja a programok betöltését... mármint AIX-on a LIBPATH, linux-on a LD_LIBRARY_PATH... eddig ezt hittem, de most úgy látszik, a cc1 indulását a gcc-ből meg tudja zavarni az utóbbi is...

Nem tudom persze, hogy egyáltalán mit akar ezzel elérni... talán úgy gondolja, hogy a linkeléskor érvényes LD_LIBRARY_PATH átöröklődik az executabléba? Mert szerintem nem...

Más: a wget-1.13.4 megpusztul már egy 'wget -v'-től is. Vajon miért?

Egyrészt ez a gondja:
Cannot get REALTIME clock frequency: Invalid argument
Másrészt:
Segmentation fault (core dumped)
Viszont a wget --version az megy... mintha a getopt_long okozná a gondot... ugyanez 1.12-ben még jó volt.

Még más: a gdb használja a libtool --mode=config opcióját... ezek szerint az aix-libtool-nak is kell majd legyen ilyenje...

Vannak kedvező jelek is: az 'xz' és a 'tar' viszonylag símán fordul+települ. Impresszív ez az xz:

$ ls -l devel.tar.*
-rw-rw-r--   1 projects devel      20139871 Dec 12 09:17 devel.tar.Z
-rw-rw-r--   1 projects devel      14788342 Dec 12 09:17 devel.tar.gz
-rw-rw-r--   1 projects devel       7910485 Dec 12 09:17 devel.tar.bz2
-rw-rw-r--   1 projects devel       3705060 Dec 12 09:21 devel.tar.xz

gdb-7.3.1 nyomora (cd opcodes; make libopcodes.la):


/bin/sh ./libtool --tag=CC   --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -mtune=native -maix32  -I/opt/freeware/include  -release `cat ../bfd/libtool-soversion`  -Wl,-bbigtoc -o libopcodes.la -rpath /usr/local/lib dis-buf.lo disassemble.lo dis-init.lo ppc-dis.lo ppc-opc.lo -Wl,/usr/local/src/gdb-7.3.1/opcodes/../bfd/.libs/libbfd.so  -lm
libtool: link: nm -BCpg  .libs/dis-buf.o .libs/disassemble.o .libs/dis-init.o .libs/ppc-dis.o .libs/ppc-opc.o   | awk '{ if ((($ 2 == "T") || ($ 2 == "D") || ($ 2 == "B")) && (substr($ 3,1,1) != ".")) { print $ 3 } }' | sort -u > .libs/libopcodes.exp
libtool: link: gcc -shared -o .libs/libopcodes-2.21.51.20110403.so  .libs/dis-buf.o .libs/disassemble.o .libs/dis-init.o .libs/ppc-dis.o .libs/ppc-opc.o   -lm -lc -Wl,-bnoentry  -mtune=native -maix32 -Wl,-bbigtoc -Wl,/usr/local/src/gdb-7.3.1/opcodes/../bfd/.libs/libbfd.so   -Wl,-bE:.libs/libopcodes.exp -Wl,-berok
collect2: /usr/local/src/gdb-7.3.1/opcodes/../bfd/.libs/libbfd.so: cannot open as COFF file
make[4]: *** [libopcodes.la] Error 1
make[4]: Leaving directory `/usr/local/src/gdb-7.3.1/opcodes'

Az mindenesetre látszik, hogy rossz libtool futott... ez azzal függ össze, hogy a configure egy részét a make csinálja (don't ask)

Persze az én vezióm sem működik, azért nem, mert a *.lo-ban ez van:


pic_object='.libs/dis-buf.o'
non_pic_object=none

Vagyis ilyenkor pic_object helyettesíti a non_pic objectet.

Ettől persze még nem jó.. pl eleve a parancs vége az kellene legyen, hogy:


- -Wl,/usr/local/src/gdb-7.3.1/opcodes/../bfd/.libs/libbfd.so
+ usr/local/src/gdb-7.3.1/bfd/libbfd.la

Újra lefuttatva a saját libtool-lal tovább jut (mondjuk amit gányol ezekkel a .so fájlokkal, az borzalmas, de egyelőre jussunk tovább), most ez jön:


gcc -mtune=native -maix32  -I/opt/freeware/include   -I. -I. -I./common -I./config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber  -I./gnulib -Ignulib  -DMI_OUT=1 -DTUI=1 -I/usr/local/include  -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts  -c -o xml-support.o -MT xml-support.o -MMD -MP -MF .deps/xml-support.Tpo xml-support.c
xml-support.c: In function 'gdb_xml_fetch_external_entity':
xml-support.c:514:19: error: storage size of 'status' isn't known
xml-support.c: In function 'gdb_xml_use_dtd':
xml-support.c:563:3: warning: implicit declaration of function 'XML_UseForeignDTD' [-Wimplicit-function-declaration]
xml-support.c:563:50: error: 'XML_TRUE' undeclared (first use in this function)
xml-support.c:563:50: note: each undeclared identifier is reported only once for each function it appears in
xml-support.c: In function 'gdb_xml_parse':
xml-support.c:580:19: error: storage size of 'status' isn't known
xml-support.c: In function 'gdb_xml_fetch_external_entity':
xml-support.c:545:1: warning: control reaches end of non-void function [-Wreturn-type]
make[2]: *** [xml-support.o] Error 1
make[2]: Leaving directory `/usr/local/src/gdb-7.3.1/gdb'

a kérdéses sor:

514: enum XML_Status status;

Az XML_Status az expat.h -ból jön:

typedef unsigned char XML_Bool;
#define XML_TRUE ((XML_Bool) 1)
#define XML_FALSE ((XML_Bool) 0)
# 45 "/opt/freeware/include/expat.h"
enum XML_Status {
  XML_STATUS_ERROR = 0,
#define XML_STATUS_ERROR XML_STATUS_ERROR
  XML_STATUS_OK = 1,
#define XML_STATUS_OK XML_STATUS_OK
  XML_STATUS_SUSPENDED = 2
#define XML_STATUS_SUSPENDED XML_STATUS_SUSPENDED
};

Ez lenne a magyarázat:


# It's desirable to list ../bfd/libbfd.la in DEPENDENCIES and LIBADD.
# Unfortunately this causes libtool to add -L$(libdir), referring to the
# planned install directory of libbfd.  This can cause us to pick up an
# old version of libbfd, or to pick up libbfd for the wrong architecture
# if host != build. So for building with shared libraries we use a
# hardcoded path to libbfd.so instead of relying on the entries in libbfd.la.

Hát igen, fordítás közben rászaladhatunk a saját programunk korábbi változatára, bár ez nem látszik gdb-specifikus problémának.

Ennek eredménye az, hogy a keletkező shared objectek vagy nem futnak, vagy beledependálnak a source tree-be. Jajj.
Persze nem tudom, hogy mi a szerepük, úgy nézem, hogy a gdb futásához nem kellenek...

Közben kolléganőm fogott egy hibát a gcc-4.6.1-ben... csak úgy, érdekességképpen...

Közben a gdb configure-ban látom, hogy a texinfo-t is hazavágtam; hát gyorsan a texinfo-4.13a-t letöltöttem, megfoltoztam, telepítettem. Gyakorlat teszi a mestert! Fáradtá.

Na ez lett a gdb elleni harc (pillanatnyi) végeredménye:

#!/bin/sh

MYLIBTOOL=/usr/local/bin/aix-libtool.sh

PATH=/usr/local/bin:$PATH

make distclean

set -e

export CFLAGS="$COMMON_CFLAGS32"
export CPPFLAGS="$COMMON_CPPFLAGS"

export LDFLAGS="-L/usr/local/lib -lcpotlas\
 -Wl,-brtl\
 -Wl,-blibpath:/usr/local/lib:/usr/lib:/lib"

find . -name configure -o -name config.rpath -exec \
    sed_repl 's|hardcode_direct=.*$|harcode_direct=no|
              s|hardcode_libdir_flag_spec=.*$|hardcode_libdir_flag_spec=|' {} \;

sed_repl 's|CC_LD=$(CC)|CC_LD=libtool --mode=link --tag=CC gcc|' gdb/Makefile.in
sed_repl 's|$(CC) $(CFLAGS)|libtool --mode=link --tag=CC gcc $(CFLAGS)|' sim/ppc/Makefile.in
./configure \
--enable-shared \
--enable-static \
--prefix=/usr/local \
--sysconfdir=/usr/local/etc \
2>&1 | tee log.configure

find . -name libtool -exec ln -sf "$MYLIBTOOL" {} \;

(make all || true) 2>&1 | tee log.make

echo '>>> Restart <<<' | tee -a log.make

sed_repl 's|-Wl,.*libbfd.so|../bfd/libbfd.la|' opcodes/Makefile
find . -name Makefile -exec \
    sed_repl 's|LDFLAGS =|LDFLAGS +=|' {} \;

make clean
find . -name libtool -exec ln -sf "$MYLIBTOOL" {} \;

(make all && make install) 2>&1 | tee -a log.make

Hátha valakit érdekel:

$ echo $COMMON_CFLAGS32
-mtune=native -maix32

$ echo $COMMON_CPPFLAGS 
-D__UNIX__ -D__unix__=1 -Dnl_langinfo=local_nl_langinfo -Disprint=local_isprint -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_ALL_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES

$ echo $COMMON_LDFLAGS32
-maix32 -Wl,-brtl -L/usr/local/lib -lcpotlas

Ebből a legfontosabb rész az, ahol a 64-bites fájlkezelés engedélyezzük (-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES)

Tegyük fel, hirtelen megbolondulok, és szeretném a libtool-t használni az openssl ellen. Mondjuk beírom ezt:

libtool --mode=link gcc -o libcrypto.la -rpath=/usr/local/lib libcrypto.a

A gyári libtool warningol, de csinál egy statikus libcrypto.a-t (ami persze megegyezik a kiindulásival), meg egy .la fájlt, az enyém meg ezt mondja:

libtool: creating export file: nm -B -BCpg
Usage: nm [-ACfhlprTv] [-B|-P] [-e|-g|-u] [-d|-o|-x|{-t [d|x|o]}]
                [-X{32|64|32_64|d64|any}] [--] File ...
libtool: 0 lines written into '.libs/libcrypto.exp'
libtool: *** fork/exec error 256, exiting
libtool: linking shared object: gcc -shared -Wl,-G -Wl,-bexport:.libs/libcrypto.exp -Wl,-bipath -o .libs/libcrypto.so.1.0.0 libcrypto.a
symlink .libs/libcrypto.so.1 -> libcrypto.so.1.0.0 created
symlink .libs/libcrypto.so -> libcrypto.so.1.0.0 created
symlink .libs/libcrypto.la -> ../libcrypto.la created

No itt van pár hiba, pl:
- Meghívta a nm-t üresen.
- Azt mondta, hogy kilép, oszt mégsem.
- Meg sem próbált old_library-t csinálni.

Na, lássunk neki.

Közben látom, hogy az Apache-ot is ügyesen megdöntöttem, a gyors kapkodás közben meg azt látom, hogy rosszul kezelem az olyan *.la fájlokat, amik -avoid-version-nal készültek... na próbáljunk valamit...

Ez lett, kiindulva a régi libaprutil.a tartalmából:

#!/bin/sh

libtool --mode=link gcc -Wl,-blibpath:/usr/local/lib:/usr/lib:/lib \
    -o libaprutil-0.la -rpath /usr/local/lib -version-info 9:6:9 \
    *.o \
    /usr/local/lib/libexpat.la \
    /usr/local/lib/libgdbm.so.3 \
    /usr/local/lib/libiconv.la \
    /usr/local/lib/libapr-0.la \
    /usr/local/BerkeleyDB.4.3/lib/libdb-4.3.la

libtool --mode=install cp -f libaprutil-0.la /usr/local/lib
Cannot load /usr/local/libexec/apache2/libphp5.a(libphp5.so) into server: Could not load module /usr/local/libexec/apache2/libphp5.a(libphp5.so).\n\tDependent module /usr/local/lib/libintl.a(libintl.so.3) could not be loaded.\n\tMember libintl.so.3 is not found in archive \nSystem error: Exec format error

Szerintetek ez baj?

A PHP-hoz persze libxml2 is kell... az meg azzal lepett meg, hogy van neki egy libxml2.syms nevű fájlja, amit odaad a linkelésnek, valószínűleg arra gondolva, hogy ez az export-fájl. Mármint, ha a gnu-linkert használnánk. Jelen kontextusban jobb lenne eldobni.

Később: az is megvan

PHP-hez:

#!/bin/sh

set -x

ar xv /usr/local/libexec/apache2/libphp5.a
explist libphp5.so >libphp5.exp

mv libphp5.so orig.libphp5.so

ld -r -bnso orig.libphp5.so -o libphp5.o

libtool --mode=link gcc -shared \
    -Wl,-bbigtoc \
    -Wl,-blibpath:/usr/local/lib:/usr/lib:/lib \
    -Wl,-bloadmap:libphp5.map \
    -o libphp5.la -rpath /usr/local/libexec/apache2/ -avoid-version \
    libphp5.o \
    /usr/local/lib/libintl.la \
    -ldl \
    /orabin/OraHome_Current/lib32/libclntsh.so \
    /usr/local/lib/libxml2.la \
    /usr/local/lib/libiconv.la

rm -f libphp5.a 2>/dev/null
ar crus libphp5.a .libs/libphp5.so

Próbálok valamit gányolni ezzel is (egyelőre nem merek nekiugrani a PHP újrafordításának, az nagyon melós volt annó is), az első jópofaság a libtool-tól:

libtool: There is 1 source-file in the command, I except troubles

Mármint ez azért gond, mert neki minden source, amit nem ismer fel... esetünkben egy .so fájlra mondta (/orabin/OraHome_Current/lib32/libclntsh.so)

Jó, "apacehctl status" nem megy. Naná, persze hogy nem. Majd bolond is lenne. Szóval jöhet a lynx.

Később: Mármint ha a gettext-et sikerült helyrehozni, ugyanis ő is rászívózott a libglib-2.0.a(libglib-2.0.so.0)-ra, amit azóta megszüntettem.

A verziókezelést fejlődni látszik, igaz inkompatibilisen, de ezért az Openssl-t meg az Oracle-t hibáztatom. Mindenesetre, ha már hozzápiszkáltam, akkor általánosra csináltam, vagyis nem csak számok lehetnek a verziószámban:


$ libtool --mode=link     gcc -version-number major:minor -o libver.la -shared rutin.lo -rpath ~/lib
$ libtool --mode=link     gcc -o vertest main.o ~/lib/libver.la
$dump -H vertest
1      /home/zsiga/lib               libver.so.major

$ libtool --mode=link     gcc -version-number 1.0.0e -o libver2.la -shared rutin.lo -rpath ~/lib
$ libtool --mode=link     gcc -o vertest2 main.o ~/lib/libver2.la
$ dump -H vertest2
1      /home/zsiga/lib               libver2.so.1.0.0e

tehát az első esetben major='major', minor='minor'; a másodikban az egész (1.0.0e) a major, és nincs minor

Legelső lépésben a fájlnév-felbontó programot fejlesztettem tovább, hogy a libvalami.so.1.2.3 -ból a so.1.2.3 legyen a kiterjesztés, ne a 3.
Persze ezt sem ész nélkül, csak ha az eleje 'lib', és a végén a verziószámok numerikusak. És ha a hívó program egy külön opcióval kéri ezt a működést.

Az az 'e' nincs benne a shared object kiterjesztésében, szerncsére.

Közben azt nézem, hogy a különféle szoftverek hogyan is döntik el, hogy mit exportálódjék, amikor a shared object készül. (a "nm -BCpg" kimenetéből kiindulva).

B Global bss symbol.
D Global data symbol.
T Global text symbol.

De: a .ponttal. kezdődő nevek nem. Jó lenne tudni, hogy az pontosan mit jelent. Ahogy nézem, minden függvény neve ponttal kezdődik, az adatoké nem.

Igen, a -version-number paraméter értéke (szinte) bármi lehet, és az bele is kerül a .la fájlba (major és minor sorok), onnan pedig a hívó modul függőségeibe -- ez a rész teljesen korrekt (ezt a működést teszteltem a nem-numerikus verziószámokkal); viszont ez az 'ismerjünk fel egy libvalami.so.version fájlt' dolog egy kicsit bizonytalan, bekövetkezhet téves felismerés is, meg elnézés is.

Szinte hihetetlen, de mintha az SSL-projekt haladni látszana... holnap referálok...

(sordb=4255)

OpenSsl látszólag jó, kellett hozzá egy újabb opció: -static-precreated

Ez annyit jelent, hogy nem kell létrehozni a .libs/libcrypto.a fájlt, mert már létezik az ./libcrypto.a, azt kell csak belinkelni a .libs-be. Ettől még a libcrypto.la szépen elkészül, és benne lesz old_library-ként:


# libcrypto.la - a libtool library file
dlname='libcrypto.so.1.0.0'
library_names='libcrypto.so.1.0.0 libcrypto.so.1.0.0 libcrypto.so'
old_library='libcrypto.a'
dependency_libs=' /usr/local/lib/libcpotlas.la'
current=0
age=0
revision=0
major='1.0.0'
minor=''

# libssl.la - a libtool library file
dlname='libssl.so.1.0.0'
library_names='libssl.so.1.0.0 libssl.so.1.0.0 libssl.so'
old_library='libssl.a'
dependency_libs=' /usr/local/lib/libcpotlas.la /usr/local/lib/libcrypto.la'
current=0
age=0
revision=0
major='1.0.0'
minor=''

(A current-age-version nincs töltve, mivel itt a current=1.0.0 lenne, de az meg nem numerikus (az age meg a revision üres))

Ruby lesz? :-) Azt hiszem, azzal annyibol egyszerubb dolgod lenne, hogy nem hasznal libtool-t, ellenben minden mast megmozgat (a fobb fuggosegek: openssl, zlib, readline, bdb). Ha lefordul es minden fajan fut, akkor mindenfele linkeles jol vizsgazik, mert a ruby majdnem mindent pluginkent hiv meg, maga a ruby binaris nagyon keves mindenre fugg.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Majd azt meg kellene csináljam, hogy a -L opciók sorrendje számítson... (jelenleg összeöntöm ABC-rendbe)... nem lesz könnyű, és nem old meg mindent (sőt, nyilván más problémákhz fog vezetni), de úgy nézem, hogy kell:

mondjuk ez van:

libtool --mode=link gcc -o libcrypto.so.1.0.0 ...
libtool --mode=link gcc -o libssl.so.1.0.0 -lcrypto ... -L. -L/usr/local/lib

Ha a '-L'-ek sorrendjét megőrzöm, akkor előbb találja meg a frissen előállított ./libcrypto.la fájlt, mint a /usr/local/lib-ben az elavultat (vagy esetleg ott nincs is .la, csak .so -- az sem jobb)

Persze ez a gond fel sem merülne, ha az openssl használná a libtool-t, és nem csak én erőltetném bele jól-rosszul, de ez most tipikusan a 'ha az én nagymamámnak kereke lenne' kategória.

Nem kell eroszakosan sorrendet tartanod, csak a relativ utvonalakat priorizalnod az abszolutakhoz kepest. Ohm, pontosabban a builddir-ben levo utvonalakat priorizalnod a builddiren kivul esokhoz kepest.
Ugyanis, egy adott projekt nem hiszem, hogy ket, kulon -L -ben levo utvonalra produkalna ugyanazt a libet, mas kiadasban, ugyanolyan nevvel.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Mondjuk ebben van igazság: ami relatíven szerepel az útvonalban (-L. például), arról érdemes megjegyezni, hogy az biztosan nem végleges útvonal, tehát ha ott talál mondjuk egy shared objectet (mármint ha működni fog a shared-object kereső rész), azt úgy kell tekinteni, mint egy 'uninstalled' elemet.

Vigyazz, ne legyel betuhu! Lehet olyan build kornyezet, hogy a -L parametere a buildkonytvtar konkret helye. Tehat a -L/home/teve/build/projekt-5.4/lib az pont ugyanolyan uninstalled item, mint a ../lib/

(a nickert bocs :-))
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Az biztos, hogy semmi sem biztos... Pontosabban: ami egy installad *.la fájlban szerepel, mint libdir=, az 'végleges'-nek tekinthető, úgyszintén néhány 'jól ismert' hely (/usr/local/lib, /opt/freeware/lib, /usr/lib, /lib); valamint ami relatív útvonallal van megadva, az biztosan (nagy valószínűséggel) 'nem végleges', minden más kétséges...

1. Egy olyan nl_langinfo, aki a CODESET kérdésre a LC_ALL/LC_CTYPE/LANG envirók alapján válaszol.
2. Egy olyan isprint, akinek minden nyomtatható 0x20-0x7e és 0xa0-0xff között.
3. Egy működő strnlen. (Erre ma már nincs szükség, de egyes 5.x sorozatokban még rossz volt a strnlen.)

+1: A napló kedvéért: a 'bison'-t is megcsináltam, nem szórakozásból, hanem mert az alól is kihúztam a libintl.a(libint.so)-t.

Végül összecsaptam a sorszámok megőrzését, működik is, ha egyvalami zavar, az az, hogy ezzel mintha egy újabb munkát generáltam volna...

Régen ilyen volt a 'dump -H /usr/local/bin/openssl' outputja:

                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER
0      /usr/local/lib:/usr/lib:/lib
1      /usr/local/lib                libcpotlas.so.0
2      /usr/local/lib                libcrypto.so.1.0.0
3      /usr/local/lib                libssl.so.1.0.0

Most, a javítás után, amikor a build-tree-t használja a linkelés:

                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER
0      /usr/local/lib:/usr/lib:/lib
1                                    libcpotlas.so.0
2                                    libcrypto.so.1.0.0
3                                    libssl.so.1.0.0

Vagyis nem tudja belehardkódolni az abszolút útvonalat. Persze ettől még fut, minden szép és jó... csak éppen egy kóbor LIBPATH enviróval meg lehet zavarni őkelmét, meg egyáltalán, minek keresgélni azt, amiről tudjuk, hogy hol van?

Másik: az a komponens, aki a -lvalami-hez megkeresi a libvalami.la-t, az .la file híjján a libvalami.so-t is kereshetné... és ha már megtalálta, egyben a symlinkeket is megvizsgálhatná: ha mondjuk van libclntsh.so, aki a libclntsh.so.10.1-re mutat, de más nincs, akkor a major a '10.1', a minor üres; de ha van libclntsh.so.10 is, akkor major='10' és minor='1'; és ha mondjuk egy libsqlplus.so-ról van szó, amelyik nem symlink, akkor major='', minor='' (ez az -avoid-version opciónak felel meg libtool-nyelven mondva))

Az elozo link alapjan elolvastam az indexes blogot is, pontosabban egyelore csak beleolvastam. Jofele az is :-)

A readline az windowson is vicces dolgokat csinal, pl. a legtobb stuff readline.dll-t vagy readline6.dll-t keres, de o defaultbol libreadline6.dll-t gyart, ugyhogy amikor lefordult, mindig kezzel csiszolok egyet rajta, hogy jo nevvel jojjon ki, ugyanis "belehardkodolja" a dll nevet a keletkezo dll.a fajlba, az pedig kellemetlen mellekhatasokkal jar a leforditott stuffra nezve (MinGW).

Arrol mar meg sem szeretnek emlekezni, hogy a gnuwin32 projekttol kell kolcsonoznom termcap konyvtarat, hogy ne a komplett msys-hez linkeljem hozza a ruby-t. Bar az MSYS ilyen szempontbol egy fokkal jobb, mint a cygwin (nem annyira maniakus), azert az elet itt sem egyszeru.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Tévedtem, mégsem fixáltam meg a PHP-t. Pontosabban mondva a /usr/local/bin/php-t kifelejtettem.

libtool --mode=link gcc -o php /usr/local/bin/php \
$ORACLE_LINK32 \
-lintl -liconv -lxml2 \
-lpthread -lcpotlas \
-lnsl -lbsd_r \
-Wl,-bloadmap:php.map

Na, reméljük...

Ma meg a smbpasswd mondta ezt:

exec(): 0509-036 Cannot load program smbpasswd because of the following errors:
        0509-150   Dependent module /usr/local/lib/libiconv.a(libiconv.so.2) could not be loaded.
        0509-152   Member libiconv.so.2 is not found in archive

Valami ilyesmit találtam ki a Makefile megheggesztésére, kiváncsi vagyok, működik-e (egyelőre a configure fut, illetve cammog).

test -f Makefile.orig || cp Makefile Makefile.orig

awk 'BEGIN        { sor= -1; } 
     /Linking/    { sor= NR; print $0; continue; }
     /\@\$\(CC\)/ { if (NR==sor+1) {
                    print "\taix-libtool --mode=link \\";
                    print "\t" substr ($0, 3);
                    continue; }
                  }
     //           { print $0; }' Makefile.orig >Makefile

Előtte gyorsan egy kis popt-1.16: úgy fordult+szerkült, mint egy kisangyal

gdbm-1.10 fordítása sikerült ugyan, de azért volt egy kis zavar az erőben, a ./configure nem tudott lefordítani valami ilyesmi tesztprogramot:

if (sizeof ((off_t)))

Ugyanez más típussal sem sikerül, a redundáns zárójelek miatt.

(Később: úgy látom, ez szándékos, így teszteli a compiler éberségét)

És érdeklődik egy /usr/include/sys/termios.h iránt. Ami itt simán /usr/include/termios.h.

De ami igazából felkeltette a figyelmemet, az az volt, hogy a mmap-ra azt mondja, hogy nem jó... szerintem meg ő próbálta rosszul erőltetni: lefoglalt valamit malloc-kal, és azt akarta MAP_FIXED-del mmap-olni, amit az AIX nem szeret, lásd itt: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/…

mmap-ra azt mondja, hogy nem jó... szerintem meg ő próbálta rosszul erőltetni: lefoglalt valamit malloc-kal, és azt akarta MAP_FIXED-del mmap-olni, amit az AIX nem szeret, lásd itt

Szereti az, csak a SPEC1170-kompatibilitást kell bekapcsolni. A Spec 1170 a SUS egyik elődje volt:

http://en.wikipedia.org/wiki/Single_UNIX_Specification#1990s:_Spec_1170

Az AIX 5L (különféle kiadásai...) UNIX 98-ra és UNIX 03-ra tanúsítottak (lásd http://www.opengroup.org/openbrand/register/). UNIX 98-ban (SUSv2) a MAP_FIXED támogatása kötelező, UNIX 03-ban (SUSv3) "csak" XSI kiegészítés, viszont a UNIX 03 cert (tudtommal) csak akkor jár, ha az XSI kiegészítések támogatottak.

http://pubs.opengroup.org/onlinepubs/007908799/xsh/mmap.html

http://pubs.opengroup.org/onlinepubs/000095399/functions/mmap.html

A rendszer valószínűleg támogatja, amit a gdbm csinálni akar, csak nem jó környezetben lett lefordítva. Valahol az AIX 5L doksiban kell lennie egy olyan fejezetnek, hogy "enable SPEC 1170 conformance" vagy "enable Single Unix Specification conformance".

Ettől függetlenül persze nem lehetetlen, hogy a gdbm nem tesz eleget azoknak a követelményeknek, amelyeket a MAP_FIXED az alkalmazásra (és nem a rendszerre) ró, ld. laphatárra igazítás.

Apache aszondja nekem, hogy implementáljam a -prefer-pic és -prefer-non-pic opciókat --mode=compile esetén...

Közben az Apache talán kész, de a PHP nem találja a size_t-t, ezért megpróbálja maga #define-olni... a hiba garantált...

az egrep (GNU-s, grep-2.7-1.rpm-ből telepített) másképp működik, mint várnám (bár nem értek hozzá, bevallom):

$ echo 'ab' | egrep '[a]b' # illeszkedik
ab
$ echo 'ab' | egrep '([a])b' # nem illeszkedik

A következő lépés, hogy kipróbálok egy másik grep verziót (2.9), mégpedig helyben fordítva.

Lehet, hogy nem veletlen, hogy az Apple is csak ovatosan lepked a verziokkal?


hron@sunshine ~ $ grep --version
grep (GNU grep) 2.5.1

Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

hron@sunshine ~ $ echo 'ab' | egrep '([a])b'
ab
hron@sunshine ~ $ 

OS X 10.6.7

Es asszem az elozoben is ez volt, mert a grep nem frissult az elozo update-tel. A 10.6.8-rol nem tudok nyilatkozni, az csak otthon van.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Még nem tudtam kipróbálni, mert a grep fordításához is kell a grep... illetve van neki egy fn_grep függvénye a ./configure-ben, csak éppen nem jól működik, ha van '.' a mintában. Megfejtés:

sed_repl 's/this map."/this map"/' configure

Később: most talán jó, bár az ő rpl_nl_langinfo-ja elnyomta az én local_nl_langinfo-mat, és ennek valamiféle YESEXPR-hez van köze, de ezt majd máskor harcoljuk meg...

Ezzel már el is jutott odáig a PHP, hogy

checking Oracle library version compatibility... 8.1
configure: error: Oracle client libraries < 9.2 are not supported

Persze igazából 11.2 az Oracle, úgyhogy megint nyomozunk egy kicsit...

Később: mondjuk tudjuk be ezt annak, hogy az Oracle-install egy kicsit ügyetlenül történt annak idején, a libclntsh.so nem symlink lett, hanem maga a verziószám nélküli shared object.

Azután: Mára az utolsó:

libtool: compile: gcc -c -Imain/ -I/usr/local/src/php-5.3.9/main/ -DPHP_ATOM_INC -I/usr/local/src/php-5.3.9/include -I/usr/local/src/php-5.3.9/main -I/usr/local/src/php-5.3.9 -I/usr/local/src/php-5.3.9/ext/date/lib -I/usr/local/src/php-5.3.9/ext/ereg/regex -I/usr/local/include/libxml2 -I/usr/local/include -I/orabin/OraHome_Current/rdbms/public -I/orabin/OraHome_Current/rdbms/demo -I/usr/local/src/php-5.3.9/ext/sqlite3/libsqlite -I/usr/local/src/php-5.3.9/TSRM -I/usr/local/src/php-5.3.9/Zend -D__UNIX__ -D__unix__=1 -Dnl_langinfo=local_nl_langinfo -Disprint=local_isprint -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_ALL_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/usr/local/include -mtune=native -maix32 -fvisibility=hidden /usr/local/src/php-5.3.9/main/main.c -o main/main.o
/usr/local/src/php-5.3.9/main/main.c: In function 'php_stream_open_for_zend_ex':
/usr/local/src/php-5.3.9/main/main.c:1230: error: 'zend_stream' has no member named 'mmap64'

Lehet megkapaszkodni:


$ egrep --version
egrep (GNU grep) 2.5.1-FreeBSD

Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ echo ab | egrep '([a])b'
ab
$ 

és kicsit óvatosan mondom, hogy szerintem jó is így, lévén a egrep-ben a () speciális - csoportosításra jó -, és benne a [] *szerintem* meg kell, hogy tartsa az eredeti funkcióját.

Egy kerdes, a BSD-s grep is tudja/fogja tudni a --color kapcsolot? Nekem ez egy eleg kritikus dolog, viszont ismerem a BSD-s sracokat annyira, hogy szeretik a jo dolgokat (is) kihagyni a portokbol.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Akkor most végigmegyek az összes gépecskémen, és ahol rossz az /opt/freeware/bin/egrep (vagyis az 'ab' nem illeszkedik az ([a])b mintára), ott telepítem forrásból... (persze ki lehetne nyomozni, hogy maga a grep hibás-e vagy az általa használt pcre, de talán majd máskor, nekem itt van a php is...)

Később: nem egészen biztos, hogy programhibáról van szó, lehet, hogy az .rpm csomag készítője zavart össze valamit, az alábbi jelekből gondolom:

# (cd /opt/freeware/bin; ls -l grep fgrep egrep)
lrwxrwxrwx    1 root     system            4 Jun 06 2011  egrep -> grep
lrwxrwxrwx    1 root     system            4 Jun 06 2011  fgrep -> grep
-rwxr-xr-x    1 root     system       204534 Sep 30 2010  grep

# echo 'ab' | /opt/freeware/bin/egrep -E '([a])b'
ab
# echo 'ab' | /opt/freeware/bin/egrep '([a])b'

Vagyis a -E opciótól az egrep (igazából grep) úgy működik, ahogy kell neki...

A grep lekérdezi azt a nevet, amelyen meghívták (argv[0]), és annak alapján választ default működést. Ezért a symlink-ek használata értelmes.

A grep-nek az argv[0]-ból ki kellene bányásznia az utolsó pathname komponenst, és csak azt vizsgálnia. Az a tippem, hogy a fenti grep az egész argv[0]-t egyben vizsgálja ehelyett, így az

/opt/freeware/bin/egrep

-et nem ismeri fel "egrep"-nek. Általában ez nem tűnik fel, mert a bináris (és a symlink-ek) a PATH-on vannak, vagyis az argv[0] általában egyetlen komponensből áll.

Közben csináltam egy '-ignore-linkflags' opciót az aix-libtool-ba: ha már egyszer én vagyok a libtool, akkor a derék szoftverek (openssl, hogy példát hozzak) ne akarjanak a linkernek opciókat adni az én fejem fölött.

Persze nem lett jó, azt mondja az openssl, hogy:

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

deklaráció: crypto/crypto.h:
definíció: crypto/mem_clr.c
vagy: crypto/ppccpuid.s (assembly)

najó, mondjuk akkor kiveszem a -ignore-linkflags -t, de akkor még azt mondja meg valaki, hogy a libcrypto.so-ban miért jelentik meg a 'strcpy', mint exportált szimbólum?

# nm /usr/local/lib/libcrypto.a | grep strcpy
.strcpy              U           -
.strcpy              U           -

# nm /usr/local/lib/libcrypto.so | grep strcpy
.strcpy              T   268436096
.strcpy              t   268436096         424
strcpy               D   536945108           8

Nem lenne rossz egy kis kutatást tartani a szimbólumok exportját/importját illetően...

Tesztprogramot vizsgálva; a 'nm' outputjában ilyesmik vannak:

d név - inicializált static változó
D név - inicializált változó (publikus)
D név - inicializálatlan változó (publikus)
t .fvnév - statikus függvény
d fvnév - statikus függvény
T .fvnév - publikus függvény
D fvnév - publikus függvény
U .fvnév - extern függvény

Vagyis minden függvényből egy adat és egy kód is fakad,
az utóbbi előtt lesz pont, a szubrutinhívás az utóbbira irányul:
bl .fvnév

Ha shared objectet gyúrunk belőle, akkor a saját függvényeiből továbbra is lesz
'D fvnév' és 'T .fvnév', ha 'exportáltak', egyébként csak T .fvnév;
az importált függvényekből lesz egy 'U fvnév' (pont nélkül),
valamint egy 'T .fvnév', tehát mintegy tovább-exportálja
ezeket a függvényeket.

Ugyanez a helyzet az executable-k esetében is: a shared-object-ből származó elemek 'U fvnév' formában vannak definiálva (pont nélkül).

Az U tudtommal csak annyit tesz, hogy undefined, vagyis nem definialt. Ez annyit tesz, hogy a binarison belul az adott szimbolum nincs semmilyen modon definialva.

Reszlet egy man nm(1)-bol:


DESCRIPTION
       GNU nm lists the symbols from object files objfile....  If no object files are listed as arguments, nm assumes the file a.out.
       For each symbol, nm shows:

       ·   The symbol value, in the radix selected by options (see below), or hexadecimal by default.

       ·   The symbol type.  At least the following types are used; others are, as well, depending on the object file format.  If lowercase, the symbol is local; if
           uppercase, the symbol is global (external).

       (...)
           "U" The symbol is undefined.

--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ez mar csak szorszalhasogatas: nem, azt jelenti, hogy itt hivatkozunk ra, de nem itt definialjuk. Maga az U az nem jelent egyben bizonyossagot is, hogy mashol definialva van. Elkepzelheto hogy nincs, ilyenkor nyomja a binaris a logba, hogy hatkerem, itt ilyen nincsen. De ettol meg a binarisban van egy ilyen szimbolum hivatkozas.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Akkor mi van ezzel az OPENSSL_cleanse-vel, meg a strcpy-vel?

ppccpuid.o:
crypto/ppccpuid.o: 0x00000070 T .OPENSSL_cleanse

libcrypto.a:
libcrypto.a[ppccpuid.o]:        112 T .OPENSSL_cleanse
libcrypto.a[számos modul]:          U .OPENSSL_cleanse

libcrypto.o:
libcrypto.o: 0x00001af4 T .OPENSSL_cleanse

libcrypto.so:
libcrypto.so: 0x10003030 T .OPENSSL_cleanse
libcrypto.so: 0x20014700 D OPENSSL_cleanse

openssl:
openssl: 0x1000a180 T .OPENSSL_cleanse
openssl: 0x1000a180 t .OPENSSL_cleanse
openssl:          - U OPENSSL_cleanse
openssl: 0x200044f8 d OPENSSL_cleanse

Ha jól értem, ez azt jelenti, hogy az Assembly-source-ből nem lett ugyan
'D OPENSSL_cleanse', de a ld-t ez nem zavarta, a shared object linkelésekor
létrehozta maga.

strcpy:

libcrypto.a:
libcrypto.a[mem.o]:          - U .strcpy
libcrypto.a[dso_dlfcn.o]:    - U .strcpy

libcrypto.o:
libcrypto.o:          - U .strcpy

libcrypto.so:
libcrypto.so: 0x10000280 T .strcpy
libcrypto.so: 0x10000280 t .strcpy
libcrypto.so: 0x200121d4 D strcpy

Ebből a legutolső sort nem értem egészen...
Nézzünk egy random példát: vfprintf:

libcrypto.a:
libcrypto.a[cryptlib.o]: - U .vfprintf

libcrypto.o:
libcrypto.o: - U .vfprintf

libcrypto.so:
libcrypto.so: 0x10000484 T .vfprintf
libcrypto.so: 0x10000484 t .vfprintf
libcrypto.so: - U vfprintf
libcrypto.so: 0x2001eab4 d vfprintf[/code]

szerkesztési listából részlet:


  E 200121CC 000008  2 DS SD S6310 memcpy                   moveeq.s(/usr/lib/libc.a[moveeq.o])
  E 200121D4 000008  2 DS SD S6311 strcpy                   noname(/usr/lib/libc.a[strcpy.o])
  E 200121DC 000008  2 DS SD S6312 memset                   memset.s(/usr/lib/libc.a[memset.o])
  E 200121E4 000008  2 DS SD S6313 strcmp                   strcmp.s(/usr/lib/libc.a[strcmp.o])
  E 200121EC 000008  2 DS SD S6314 strncpy                  strncpy.s(/usr/lib/libc.a[strncpy.o])
  E 200121F4 000008  2 DS SD S6315 strcat                   strcat.s(/usr/lib/libc.a[strcat.o])
  E 200121FC 000008  2 DS SD S6316 memmove                  moveeq.s(/usr/lib/libc.a[moveeq.o])

Ebből arra következtetek, hogy ezek a libc.a-ból kövzetlenül szerkültek be, a gyorsaság miatt,
szemben pl a vfprintf-fel, aminek nincs ilyen külön objektmodulja:


libc.a:
/usr/lib/libc.a[strcpy.o]: 0000000000 T .strcpy
/usr/lib/libc.a[strcpy.o]: 0000000000 t .strcpy
/usr/lib/libc.a[strcpy.o]: 0x000001a8 D strcpy
/usr/lib/libc.a[shr.o]: 0x00062500 T .strcpy
/usr/lib/libc.a[shr.o]: 0x00062500 t .strcpy

/usr/lib/libc.a[strcpy.o]: 0000000000 T .strcpy
/usr/lib/libc.a[strcpy.o]: 0000000000 t .strcpy
/usr/lib/libc.a[strcpy.o]: 0x000001b0 d TOC
/usr/lib/libc.a[strcpy.o]: 0x000001a8 D strcpy
/usr/lib/libc.a[shr.o]: 0x002f8f20 T .NCstrcpy
/usr/lib/libc.a[shr.o]: 0x002fa840 T .NLstrcpy
/usr/lib/libc.a[shr.o]: 0x00062500 T .strcpy
/usr/lib/libc.a[shr.o]: 0x00062500 t .strcpy
/usr/lib/libc.a[shr.o]: 0x00303d40 T .wstrcpy

/usr/lib/libc.a[shr.o]: 0x0002a8e0 T .vfprintf
/usr/lib/libc.a[shr.o]: 0x0006ba20 D vfprintf

Akkor végül is minden rendben van, kivéve a PHP-t...

(ld): er full
ld: 0711-318 ERROR: Undefined symbols were found.
        The following symbols are in error:
 Symbol                    Inpndx  TY CL Source-File(Object-File) OR Import-File{Shared-object}
                              RLD: Address  Section  Rld-type Referencing Symbol
 ----------------------------------------------------------------------------------------------
 .zm_startup_nl_langinfo   [990]   ER PR /usr/local/src/php-5.3.9/ext/standard/basic_functions.c(ext/standard/basic_functions.o)
                                   00001db0 .text    R_RBR    [1340]  .zm_startup_basic

No ez a zm_startup_basic televan ilyesféle extern-ekkel:

.zm_startup_array    U           -
.zm_startup_assert   U           -
.zm_startup_basic    T        6160
.zm_startup_browscap U           -
.zm_startup_crypt    U           -
.zm_startup_dir      U           -
.zm_startup_dns      U           -
.zm_startup_file     U           -
.zm_startup_imagetypes U           -
.zm_startup_lcg      U           -
.zm_startup_nl_langinfo U           -
.zm_startup_pack     U           -
.zm_startup_proc_open U           -
.zm_startup_standard_filters U           -
.zm_startup_syslog   U           -
.zm_startup_url_scanner_ex U           -
.zm_startup_user_filters U           -
.zm_startup_user_streams U           -

de csak a zm_startup_nl_langinfo-t nem sikerül feloldani linkeléskor.

Van ottan még számos modul, amik mind exportálnak ezt-azt, pl:

nm browscap.o | grep zm_
.zm_deactivate_browscap T        6476
.zm_shutdown_browscap T        6624
.zm_startup_browscap T        6268
zm_deactivate_browscap D       10108
zm_deactivate_browscap d       10108          12
zm_shutdown_browscap D       10120
zm_shutdown_browscap d       10120          12
zm_startup_browscap  D       10096
zm_startup_browscap  d       10096          12

Azután itt van a string.o:

# nm string.o | grep zm_
.zm_startup_local_nl_langinfo T        4056
zm_startup_local_nl_langinfo D       93068
zm_startup_local_nl_langinfo d       93068          12

Ez vajon miért nem volt jó? Aha, a "local" miatt: először jött az én kis átnevezésem (nl_langinfo -> local_nl_langinfo, azután az övé (vagyis hogy elé tette a zm_startup_ -ot) Persze jó kérdés, hogy miért nem minden kontextusban ugyanúgy alakult át.

Akkor most itt tartunk:

# make install-pear-installer
make: *** [install-pear-installer] Error 255
# make -n install-pear-installer
/usr/local/src/php-5.3.9/sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir= -derror_reporting=1803 -dmemory_limit=-1 -ddetect_unicode=0 pear/install-pear-nozlib.phar -d "/usr/local/lib/php" -b "/usr/local/bin" -dp a -ds a

Nem specifikusan a PHP-ről van szó; talán valahogy így lehetne felállítani egy képletet:

szopás = k1 * program_mérete + k2 * függőségek_száma + k3 * dokumentálatlan_függőségek_száma + k4 * a_fejlesztők_által_használt_"szellemes_egyedi_megoldások"_száma

de legalább readline-6.2 megvan, gnupg folyamatban

De most a PHP-ban elakadtam, valóban, tesztből megnézem ugyanezt linuxban...
eddig lefordult:

apache, libxml2, gnupg, php

lement csont nélkül a 'make install-pear-installer' is... akkor most kezdhetjük összenézni, hogy melyik mit is csinált... de jó!

Van egy bazinagy pear/install-pear-nozlib.phar,
azt esetleg ki lehet bontani:

phar extract -f install-pear-nozlib.phar

és a benne lévő index.php-t futtatni:

php -n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir= -derror_reporting=1803 -dmemory_limit=-1 -ddetect_unicode=0 \
index.php  -d "/usr/local/lib/php" -b "/usr/local/bin" -dp a -ds a

debug-kiíratásokkal be tudjuk lőni ezt a sort, mint problémásat:

$info = $pkg->fromAnyFile($instfile, PEAR_VALIDATE_INSTALLING);

$instfile="phar://install-pear-nozlib.phar/Archive_Tar-1.3.7.tar"

a $pkg definíciója pedig:

$pkg = new PEAR_PackageFile($config, $debug);

Illetve --debug opcióval már előbb meghal:

$config->get ($key, null, 'default');
ahol $key='auto_discover'
$config pedig egy PEAR_config object

További ötlet:

find . -name '*.php' | while read F; do sed_repl 's;phar://install-pear-nozlib.phar/;;' $F; done

Akkor most az javasolnám, hogy ne fordítsuk a PHP-t large-file-support-módban AIX-en, még gcc-vel sem. Ugyanis large-file-support ilyen #define-okban fejeződik ki:

#ifdef _LARGE_FILES
#define fseeko fseeko64
#define ftello ftello64
#define fgetpos fgetpos64
#define fsetpos fsetpos64
#define fopen fopen64
#define freopen freopen64
#endif /* _LARGE_FILES */

sajnos ezek a makrók szépen átmennek a PHP-be is, tehát nem lesz fopen nevű függvényünk, csak fopen64... (linux + glibc + gcc esetén van egy kerülőút az erdőn keresztül (_REDIRECT és vidéke a /usr/include/sys/cdefs.h-ban))

(Természetesen a fopen hívása @fopen-ként volt a scriptben, nehogy rögtön kiderüljön, mi is a baj... szépen tele kellett raknom tesztkiíratásokkal...

Namostan az lehet, hogy a bzip2-t nem telepíttem forrásból? Csapjon valaki a kezemre!

Szép minimalista felépítés, csak Makefile, se configure, se libtool, semmi multiplatform... lehet vele shared-libet csináltatni, de maga az executable azt nem használja, a sebesség miatt (legalábbis a fejlesztő szerint x86-on lassít, mert a %ebx foglalt:

A second reason to prefer the version statically linked to the library is that, on x86 platforms, building shared objects makes a valuable register (%ebx) unavailable to gcc, resulting in a slowdown of 10%-20%, at least for bzip2.

Ez vajon hibajelenség?

Program received signal SIGSEGV, Segmentation fault.
0xd859e278 in zend_hash_internal_pointer_reset_ex () from /usr/local/libexec/apache2/libphp5.so
(gdb) bt
#0  0xd859e278 in zend_hash_internal_pointer_reset_ex () from /usr/local/libexec/apache2/libphp5.so
#1  0xd8c4d234 in apply_config () from /usr/local/libexec/apache2/libphp5.so
#2  0xd8c4f52c in php_handler () from /usr/local/libexec/apache2/libphp5.so
#3  0x10003718 in ap_run_handler ()
#4  0x100048b4 in ap_invoke_handler ()
#5  0x1009b144 in ap_process_request ()
#6  0x1009a2b4 in ap_process_http_connection ()
#7  0x10041e78 in ap_run_process_connection ()
#8  0x100426f8 in ap_process_connection ()
#9  0x10035e80 in child_main ()
#10 0x1003618c in make_child ()
#11 0x100365f0 in perform_idle_server_maintenance ()
#12 0x10036d4c in ap_mpm_run ()
#13 0x10001e94 in main ()

zend_hash.c:

ZEND_API void zend_hash_internal_pointer_reset_ex(HashTable *ht, HashPosition *pos)
{
        IS_CONSISTENT(ht);

        if (pos)
                *pos = ht->pListHead;
        else
                ht->pInternalPointer = ht->pListHead;
}

(Nem válasz igazából, mert nincs kérdés, de jól gondolom, hogy te most gyakorlatilag veszel egy átlag LAMP-os környezetet, és AAMP-ot csinálsz belőle? És tulajdonképp az a célod, hogy bármi, amit valamelyik Linux-disztróban kb 10000 csomagkészítő összegányolt, hogy náluk menjen, azt te egyedül megcsinálod AIX-re, pedig - ha jól veszem ki a régi indexes, meg az itteni szálat - az IBM mindent megtesz annak érdekében, hogy ez neked ne sikerüljön? A IBM-nél jobban már csak a magasanképzett linuxos szoftverfejlesztó szakmunkások próbálnak ebben megakadályozni.)

Note to self: erre rá kellene nézni:

libtool --mode=install /usr/local/src/httpd-2.2.21/build/install.sh -c -m 644 build/config_vars.out /usr/local/share/apache2/build/config_vars.mk
Output-file '/usr/local/share/apache2/build/config_vars.mk'is neither .lo nor .la, exiting
Installing build/config_vars.out -> /usr/local/share/apache2/build/config_vars.mk

Van egy olyan érzésem, hogy ha az Apache is (az aprutil is, amit hajlamos nem újrafordítani, ha nem mondjuk neki külön, hogy --with-included-apr) , meg a a PHP is largefile-support nélkül fordul, akkor minden oké lesz.

De azért jobb lenne, ha mehetne minden largefile-supporttal...

-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES

Eddig abban voltam, hogy ez a három #define elég a boldogsághoz, de most úgy látom, van program (Apache), aki erre keres:

_LARGEFILE64_SOURCE

Később: egy ilyet találtam hozzá:
http://www.delorie.com/gnu/docs/glibc/libc_13.html

Megint visszaköszönnek a förtelmes hordozhatatlan hakkok, amit a tökkelütött FLOSS programozók beledrótoztak a programjaikba. Különösen szégyen ez az Apache részéről, amely már tíz éve is a hordozhatósággal domborított. A megoldás természetesen a SUS-ban specifikált getconf utility használata, amely a platform fordító és egyben linker (c89 v. c99) számára elő tudja állítani a megfelelő flag-eket. (A másik oldal nyilván az, hogy a forrást is a SUS szerint kell megírni.) Persze ha gcc-vel fordítunk AIX-on, akkor az AIX-os getconf nem sokat fog használni... Ha a program történetesen mással nem is fordul, csak gcc-vel, akkor tényleg az egyetlen lehetőség a makrók kézi masszírozása.

Tisztelettel adózom a kitartásodnak; én már rég feladtam volna (vagy mások által fordított csomagok között nézelődnék).

A hivatalos glibc doksi egyébként itt van: ... majdnem, mert a gnu.org a sopa ellenkampány miatt nem elérhető. Szóval a kedvenc linyuksz munkaállomásodon "info libc", "m", "Feature Test Macros". Az az ironikus, hogy a glibc doksit kell olvasgatni, míg a célrendszeren teljesen független libc van...

Ugye, lassan valami kis AIX-szakértővé növöm ki magam;)
(legalábbis a fordítás+telepítés területén)

Egyébként így visszatekintve azt mondanám, hogy amit akkor csináltam, az a gányolás, toldozgatás és hályogkovácsolás keveréke volt... viszont lett belőle működő readline, bash, bison, gettext, iconv, glib, mc, apache, php...

Azután tavaly újra megpróbáltam valamit frissíteni, és láttam, hogy a shared-libek állása (verziószám nélküli *.a fájlokban lakó shared objectek) minden verzióváltást lehetetlenné tesz... erre előálltam egy olyan termékkel, ami verziószámos *.a fájlokba tette a shared libeket (lásd a topik legelején) (persze ehhez az install-folyamatba be kellett avatkozni, minden executable-t újralinkelni) ami nem volt annyira rossz ötlet, csak messze nem tökéletes: például egy lib-ből vagy csak shared, vagy csak static lib képződhetetett, de az is megesett, hogy egy *.a-ban shared és nem shared objectek is laktak...

Ez a mostani a harmadik nekifutás, szerintem ez már egész jó lett..

Állítólag nem tulságosan felfigyelősek... egy kis dialógus 2004-ből:

> Hello,
> is there a way the enable XDISPLOC telnet option in telnetd?
> AIX version is 5.1, the default telnet server
>
> with standard telnetd:
> client: IAC WILL XDISPLOC
> server: IAC DO XDISPLOC
> server: IAC SB XDISPLOC SEND IAC SE
> client: IAC SB XDISPLOC IS host:port IAC SE
>
> with AIX telnetd:
> client: IAC WILL XDISPLOC
> server: IAC DONT XDISPLOC

Would you believe that it is seven years since I asked IBM to include
this function?

Valamit haxoltam, most fordul, nem esküszöm meg, hogy működni fog:

/* unistd.h */

#ifndef _H_UNISTD

/* ezt a file-t a /usr/local/src-be kellene installálni,
   lehetőleg nem felülírva vele semmit,
   a haszna az lenne, hogy GCC használata esetén
   az függvény-átnevezések nem #define-nal történnének,
   hanem egy GCC-specifikus pragmával
 */

#include_next <unistd.h>

#if defined (_LARGE_FILES) && defined (__GNUC__)
#undef lseek

off64_t lseek (int, off64_t, int)
    __asm__ ("lseek64");

#if _XOPEN_SOURCE_EXTENDED==1

#undef truncate
#undef ftruncate

int truncate (const char *, off64_t)
    __asm__ ("truncate64");

int ftruncate (int, off64_t)
    __asm__ ("ftruncate64");

#endif

#endif

#endif

Vagy, ha nem akarunk fordítani, számos helyről tölthetünk le mindenfélét, pl:

http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/ezinstal…

persze lehet, hogy a csomag készítőjének más elképzelése van az opciókról (pl az LFS használatáról), a shared libekről és sok minden másról, mint nekünk... én például ha le is tölthetnék egy olyan PHP-verziót, amiben szuper MySql és PosgreSQL támogatás van, nem sokat érnék vele az Oracle-mmal...

vagy, pl ránézünk a csomagból jövő bash függőségeire (dump -H):

0      ./builtins:./lib/readline:./lib/glob:./lib/tilde:./lib/sh:/opt/freeware/lib:/usr/vac/lib:/usr/lib:/lib                                         
1                                    libc.a              shr.o
2                                    libcurses.a         shr42.o
3                                    libiconv.a          shr4.o
4                                    libdl.a             shr.o

különösen szépek az elején a PATH-ban lévő relatív útvonalak, de az sem piskóta, hogy pl a libiconv.a(shr4.o) miatt eljöhet majd egy pillanat, amikor valahol a PATH-on talál egy libiconv.a-t, amelyben nincs shr4.o, és akkor a bash megszűnik működni...

Ooo... nem tudtad? A readline makefile-ja ketszer linkel, csak elsore kevesebbet. Mondjuk, az is finom, hogy windowson utolag ujra kell linkelni mindket shared libet, mert libreadline6.dll lesz belole, sok alkalmazas meg readline6.dll -t es readline.dll -t keres. En a readline6.dll-t preferalom.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Nos, most már tudom: beteszteltem linuxon, ugyanez a jelenség, csak ott nincsenek 'duplicated symbol' üzenetek a linkertől.

Mindenesetre most megy a bash-3.2, ilyen a dump -H:

INDEX  PATH                          BASE                MEMBER              
0      /usr/local/lib:/usr/lib:/lib                                          
1      /usr/local/lib                libcpotlas.so.0
2                                    libdl.a             shr.o
3      /usr/local/lib                libiconv.so.2
4      /usr/local/lib                libintl.so.8
5                                    libpthread.a        shr_comm.o
6                                    libpthread.a        shr_xpg5.o
7      /usr/local/lib                libreadline.so.6
8                                    libc.a              shr.o
9                                    librtl.a            shr.o

PS: és van benne egy hibás po.ru vagy micsoda üzenetfájl, ami utf-8-nak mondja magát, de nem az. Ennyit még el tudok viselni erős szívvel.

Ezt írtam ki magamnak:

aix-libtio.GetRelease: *** Kezeletlen eset a 'libsybdb.la elemzésében
library_names='libsybdb.a libsybdb.a '
shared objectet tartalmazó *.a fájlok kezelésére nem vagyok felkészülve

Hát, igen. Ezen a gépen 2005-ben próbáltam valami freetds vagy ilyesmi nevű terméket fordítani, ami végül nem kellett semmire, de attól még megmaradt, és most szépen az apr-util ráismert, mint elveszett jóbarátjára... akár meg is próbálhatom kezelni ezt az esetet is... (másik lehetőség, hogy kiveszem az elemet a könyvtárból, és átírom a .la fájlt)

# ar tv /usr/local/lib/libsybdb.a
rwxr-xr-x     0/0     1359241 Oct 27 14:03 2005 libsybdb.so.5

Ma esti utolsó buktám:

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

és valóban, ebben a verzióban nincs ilyen... pontosabban van, de nem exportálódik:

nm -Bg  /orabin/OraHome_Current/lib32/libclntsh.so | egrep '(OCIPing|OCIAttrSet)'
   4257088 T .OCIAttrSet
   4251360 T .OCIPing
    508272 D OCIAttrSet

Csak a jegyzőkönyv kedvéért: a PHP a readline-t sem ismeri fel, a rl_pending_input függvény hiánya miatt. Ez a függvény ugyanis egy változó...
https://bugs.php.net/bug.php?id=60881

sed_repl 's;rl_pending_input();rl_pending_input;g' configure

Ja és nem találja a libsqlite-ot. Mert nekem csak libsqlite3 jutott... vajon kinek van igaza?

Később: most megy (talán az előbb kimaradt a 'make distclean'). Illetve nem megy, mert az sqlite-ból kimaradt a -DSQLITE_ENABLE_COLUMN_METADATA fordítási opció. Fussunk neki újra!

Így már csak az a gond, hogy két sqlite3 linkelődik a php-be: a saját, meg a külső...

Ezért most ezzel próbálkozom:

sed_repl 's;ext/sqlite3/libsqlite/sqlite3.lo ext;ext;' Makefile

Namostan az sqlite3 az Apache (illetve apr-util) környékén is okozott gondot (pontosabban mondva: kimutatott egy hibát az aix-libtoolban), de szerencsére erre nem derült fény, amíg nem az éles gépen próbáltam ki... egyelőre nincs ötletem, mi a magyarázat...

Hát például gond az, hogy az 'apr_dbd_sqlite3-1.so' nem 'lib'-bel kezdődik. Mondjuk ez nem hiba; azzal függ össze, hogy nem linkelésre, hanem csak dinamikus betöltésre való (dlopen és vidéke, libtool-ban -module opció).

Javítva, egyben azt is megtudtam, hogy ezek a modulok a /usr/local/lib/apr-util-1/ -be települnek, tehát nincsenek beleheggesztve magába a libaprutil-1.so-ba.

A javítást kipróbálandó, újra akartam csinálni a gettext-0.18.1.1-et. Természetesen nem sikerül.

gcc -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I..  -I../intl -I../intl -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -D__UNIX__ -D__unix__=1 -Dnl_langinfo=local_nl_langinfo -Disprint=local_isprint -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_ALL_SOURCE -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/usr/local/include -D_THREAD_SAFE  -mtune=native -maix32  -O2 -c -o lstat.o lstat.c
lstat.c:61:1: error: conflicting types for 'rpl_lstat'
./sys/stat.h:742:1: note: previous declaration of 'rpl_lstat' was here
lstat.c: In function 'rpl_lstat':
lstat.c:64:3: warning: passing argument 2 of 'orig_lstat' from incompatible pointer type [enabled by default]
lstat.c:36:1: note: expected 'struct stat *' but argument is of type 'struct stat64 *'

Ez nyilván az én múltkori hackolásom miatt van (largefile support...)

Meg a gettext-beli gnulib jószándéka miatt, hogy ő egy saját, módosított lstat-ot alkosson nekünk...


/* lstat works differently on Linux and Solaris systems.  POSIX (see
   `pathname resolution' in the glossary) requires that programs like
   `ls' take into consideration the fact that FILE has a trailing slash
   when FILE is a symbolic link.  On Linux and Solaris 10 systems, the
   lstat function already has the desired semantics (in treating
   `lstat ("symlink/", sbuf)' just like `lstat ("symlink/.", sbuf)',
   but on Solaris 9 and earlier it does not.

   If FILE has a trailing slash and specifies a symbolic link,
   then use stat() to get more info on the referent of FILE.
   If the referent is a non-directory, then set errno to ENOTDIR
   and return -1.  Otherwise, return stat's result.  */

Tényleg van egy ilyen a configure outputjában:

checking whether lstat correctly handles trailing slash... no

Alapvetően ott a gond, hogy neki is van egy saját meghaxolt sys/stat.h-ja, amiben beinkludálja az eredetit, azután jó kis #define-okkal az eredeti 'lstat' helyére befúrja a saját rpl_lstat-ját... külön fel van készülve a large-file-supportra is, mondhatni szépen keresztbe teszünk egymásnak

Úgyhogy most teszek a libcpotlas.la-ba két új függvényt, local_lstat32 és local_lstat64 néven...
persze ezt úgy kell megcsinálni, hogy menjen az alábbi három eset mindegyikében:

32-bit, _LARGE_FILES opció nélkül: lstat=local_lstat32, lstat64=local_lstat64
32-bit, _LARGE_FILES opcióval: lstat=local_lstat64, lstat64=local_lstat64
64-bit: lstat=local_lstat64, lstat64=local_lstat64, (local_lstat32 ilyenkor nincs is)

(Szerk: de csak ha a -DUSE_LOCAL_LSTAT opcióval fordítunk, mert azért ez mindennapos valós szükségletnek nemigen nevezhető...)

Ehhez persze az aix-libtool-t is toldozgatni kellett, hiszen eddig nem volt 64-bites működés; most ha azt látja a gcc paraméterei között, hogy -maix64 vagy -m64, akkor ő is használja a -X64 opciót a 'nm' és az 'ar' hívásánál.

Később: így most megy a gettext, nem csodálkoznék, ha cserébe valami más romlott volna el...

Ja és mostantól a .la-ba beleírom a 'release'-t, pusztán az emberi olvasók kedvéért (ha esetleg lennének ilyenek):

# Names of this library.
library_names='libgettextlib-0.18.1.so libgettextlib-0.18.1.so libgettextlib.so'

# Version information
current=0
age=0
revision=0
release='0.18.1'

De van egy olyan érzésem is, hogy az install sem komplett, azért nem megy a lokalizáció.

Mondjuk összecsapunk egy ilyen programot:

/* loctest.c */

#include <stdio.h>
#include <stdlib.h>
#include <locale.h>

static void Test1 (const char *);

int main (void)
{
    Test1 (NULL);
    Test1 ("");
    Test1 ("C");
    Test1 ("en");
    Test1 ("en_US");
    Test1 ("en_US.ISO8859-1");
    Test1 ("hu");
    Test1 ("hu_HU");
    Test1 ("hu_HU.ISO8859-2");

    return 0;
}

static void Test1 (const char *loc)
{
    const char *p;

    p= setlocale (LC_CTYPE, loc);
    printf ("setlocale (%s) returned %s\n", loc, p);
}

és a következő kimenetet kapjuk:


setlocale () returned C
setlocale () returned en_US.ISO8859-1
setlocale (C) returned C
setlocale (en) returned 
setlocale (en_US) returned en_US
setlocale (en_US.ISO8859-1) returned en_US.ISO8859-1
setlocale (hu) returned 
setlocale (hu_HU) returned 
setlocale (hu_HU.ISO8859-2) returned 

a truss megmondja, hogy vannak nekünk olyan fájljaink, hogy

/usr/lib/nls/loc/en_US.ISO8859-1
/usr/lib/nls/loc/en_US.ISO8859-1__64

mindkettő jó kis shared object, 32 és 64 bitesek, értelemszerűen; szülőföldjük a bos.loc.iso.en_US csomag. Sőt, mintha valamelyik install-CD-n (vol7) lenne is egy 'bos.loc.iso.hu' nevű fájl, talán épp abban kellene legyen a magyar lokalizáció...

Mondjuk a 'jó lett' kifejezést szeretném úgy árnyalni, hogy 64 bites esetben jó lett:

$ ./loctest64 hu_HU.ISO8859-2
setlocale (LC_CTYPE, "hu_HU.ISO8859-2") returned "hu_HU.ISO8859-2"
$ ./loctest hu_HU.ISO8859-2
setlocale (LC_CTYPE, "hu_HU.ISO8859-2") returned NULL

Később: megint én leszek a hibás, mivel a jó/nem jó működés közötti különbség attól függ, hogy volt-e -L/usr/local/lib flag szerkesztéskor... szóval ottan van valami galádság... A truss a következő különbséget mutatja:


jó:
__loadx(0x01000080, 0x2FF1E450, 0x00003E80, 0x2FF223E0, 0x00000000) = 0xD007F130
__loadx(0x01000180, 0x2FF1E440, 0x00003E80, 0xF0249AAC, 0xF02499DC) = 0x20011118
__loadx(0x07080000, 0xF0249A7C, 0xFFFFFFFF, 0x20011118, 0x00000000) = 0x20011FB8
__loadx(0x07080000, 0xF02499BC, 0xFFFFFFFF, 0x20011118, 0x00000000) = 0x20011FC4
__loadx(0x07080000, 0xF0249A8C, 0xFFFFFFFF, 0x20011118, 0x00000000) = 0x20011FF4
__loadx(0x07080000, 0xF02499CC, 0xFFFFFFFF, 0x20011118, 0x00000000) = 0x20012000
__loadx(0x07080000, 0xF0249A4C, 0xFFFFFFFF, 0x20011118, 0x00000000) = 0x20011FD0
__loadx(0x07080000, 0xF02499FC, 0xFFFFFFFF, 0x20011118, 0x00000000) = 0x20011FE8
__loadx(0x07080000, 0xF0249A5C, 0xFFFFFFFF, 0x20011118, 0x00000000) = 0x2001200C
__loadx(0x07080000, 0xF0249A6C, 0xFFFFFFFF, 0x20011118, 0x00000000) = 0x2001203C
__loadx(0x07080000, 0xF02499EC, 0xFFFFFFFF, 0x20011118, 0x00000000) = 0x20012024
__loadx(0x07080000, 0xF0249A0C, 0xFFFFFFFF, 0x20011118, 0x00000000) = 0x2001209C

rossz:
__loadx(0x01000080, 0x2FF1E440, 0x00003E80, 0x2FF223D0, 0x00000000) = 0xD007F130
__loadx(0x01000180, 0x2FF1E430, 0x00003E80, 0xF0249AAC, 0xF02499DC) = 0x00000000

mindenesetre a 0xd007f130 az a /usr/lib/nls/loc/en_US adatterülete (gdb: info sh), a 0x20012118 pedig a /usr/lib/libi18n.a(shr.o) adatterülete.

Ha a debuggert megállítjuk a __loadx-nél, akkor a paraméterek az r3..r7 regiszterekben vannak, már csak a jelentésüket kell megsaccolni.

(gdb) print (char *)$r6
$4 = 0x2ff223e0 "/usr/lib/nls/loc/en_US.ISO8859-1"

(gdb) print (char *)$r6
$5 = 0xf0249aac "libi18n.a(shr.o)"

Szerintem ez egy dlopen lehetett a libi18n.a(shr.o)-ra, ami nem sikerül, ha volt a szerkesztésnél -L/usr/local/lib. (Ha mondjuk lenne /usr/local/lib/libi18n.a, és az bezavarna, azt érteném, de nincs.)

Egyébként (visszanéztem) november 25-én tettem szóvá, hogy az iconv miért tesz valamiféle shared object-et a libiconv.a-ba. Mondjuk ők is észrevették ezt a jelenséget, és erre lenne ez a megoldás? Megprólom újra a make install-t, és ellenőrzöm...

További hasznos funkció a 'dump' parancsban:

dump -Tv exeneve

megmutatja, melyik extern honnan oldódik fel

A flex múltkori problémájára most találtam megoldást, melynek lényege, hogy a 0-méretű malloc ne NULL-t adjon vissza. Ez biztos jó valamire. Részlet a kódból:


const char Maradjon  [16] = "Ne_bantsd_ezt___";
const char Ne_bantsd [16] = "Ne_bantsd_ezt___";

#define CHECK(func) \
if (memcmp (Ne_bantsd, Maradjon, sizeof (Maradjon))) \
Hiszti (func, __LINE__);

void *local_realloc (void *ptr, size_t size)
{
    void *rp= (void *)Ne_bantsd;

    CHECK ("realloc");
    if (ptr==Ne_bantsd || ptr==NULL) {
        if (size!=0) rp= realloc (NULL, size);

    } else {
        if (size!=0) rp= realloc (ptr, size);
        else         free (ptr);
    }
    return rp;
}

Persze nem sikerült elsőre, ezzel jól megdöntöttem a flex-et, és mivel a debuggerrel is volt valami ügyetlenkedésem, órákig tartott, míg rájöttem, hogy mi volt a gond (az alulról a negyedik sorban ptr= realloc (ptr, size) volt.

Kieg: persze a CHECK felesleges (lehet), ha a 'Ne_bantsd' egy írásvédett szegmensbe kerül, de ha már megírtam ezt az ellenőrzőt, hát bennehagyom, legalább színesíti a kódot.

Why is malloc being defined as rpl_malloc ??

AC_FUNC_MALLOC

Ennek a mókának az az értelme, hogy a malloc()-nak a NULL visszatérési értékét azonnal out-of-memory-nak lehessen tekinteni. (Egyébként csak akkor lehet annak tekinteni, ha a bemenő paraméter (a méret) pozitív volt.)

Ahogy a fent idézett szálban is kiderült (valami másnak a kapcsán), a linkelési hibát az okozta, hogy vagy a flex maintainer, vagy valamelyik AC makró szerzője képtelen volt rendesen használni az AC_FUNC_MALLOC-ot.

Köszi, hogy utánanéztél; én is gondolkoztam azon, hogy esetleg a malloc(0) legyen malloc(1), de akkor már miért nem malloc(2) vagy malloc(16)?
Az én gányolt procimmal legalább szépen kipusztul, ha megpróbál túlírni... (mármint egy nulla méretű blokk esetében bármilyen írás túlírás... Sőt, esetleg egy olyan címet kellene visszaadni, amiről olvasni sem lehet...)

Namostan a wget bugját a múltkor jól elnéztem azzal, hogy javították, de nem javítothatták, legalábbis kibocsátott verzióban nem, mert az 1.13.4 az utolsó. Úgyhogy most lett egy ilyen kódrészlet:

if [ ! -f src/main.patch ]; then
(
set -x
cd src
cat >main.patch <<DONE
957a958,959
>       
>       if (longindex==-1) continue;
DONE
patch -i main.patch main.c
) 2<&1 | tee log.patch
fi

Még azt az egyet nem tudom, hogy a *.la fájlba miért nem írom bele, hogy mikor készült (dátum+idő)... na ezt gyorsan pótlom!

Eljön egy pillanat, amikor azon kezdek gondolkozni, hogy a "dump -H *.so" kimenetében mit jelent ez:


INDEX  PATH                          BASE                MEMBER              
0      /usr/local/lib:/usr/lib:/lib
1      /usr/local/lib                libcpotlas.so.0
2      /usr/local/lib                libz.so.1
3                                    libgcc_s.a          shr.o
4                                    libc.a              shr.o
5                                    librtl.a            shr.o
6                                    ..

Mármint az utolsó sor. Van olyan is, ahol csak egy pont van, de mintha már láttam volna olyat is, ahol '.' is van, meg '..' is. Talán az unresolved externekhez van köze?

Ilyesmiket mond a dump -Tv:

[493]   0x00000000    undef      IMP     DS EXTref              .. libintl_dgettext
[494]   0x00000000    undef      IMP     DS EXTref              .. asprintf

meg

[1]     0x00000000    undef      IMP     DS EXTref               . PyArg_ParseTuple
[2]     0x00000000    undef      IMP     DS EXTref               . PyBuffer_Release

Mondjuk ez a gdb egy kicsit ügyetlen így, próbáljuk meg mégegyszer megnézni. Pl van egy olyan rész, amikor linkelésnél azt mondja:

libtool --mode=link gcc ... -Wl,somepath/libname.so

na ezt kellene a libtoolnak úgy kezelnie, mintha ezt mondta volna:

libtool --mode=link gcc ... somepath/libname.so

de ha van ottan la-file, akkor így:

libtool --mode=link gcc ... somepath/libname.la

Kieg: és ha mondjuk valami/.libs/libname.so van ott, akkor abból valami/libname.la legyen

Előző kérdésemre (. és .. ügyben) a 'ld' manuálja mondja:

    #! . (A single dot) This name refers to the main executable. Use this file
    name when you are creating a shared object that imports symbols from
    multiple main programs with different names. The main program must export
    symbols imported by other modules, or loading will fail. This import file
    name can be used with or without the run-time linker.

    #! .. (Two dots) Use this name to list symbols that will be resolved by the
    run-time linker. Use this file name to create shared objects that will be
    used by programs making use of the run-time linker. If you use a module that
    imports symbols from .. in a program that was not linked with the rtllib
    option, symbols will be unresolved, and references to such symbols will
    result in undefined behavior.

Elhatalmasodott rajtam a hatalmi téboly, nevezetesen hogy minden shared elemnek elírjuk a helyét linkeléskor, ez lett belőle (mc):

INDEX  PATH                          BASE                MEMBER              
0      /usr/local/lib:/usr/lib:/lib
1      /usr/lib                      libc.a              shr.o
2      /usr/local/lib                libcpotlas.so.1
3      /opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.6.2
                                     libgcc_s.a          shr.o
4      /usr/local/lib                libglib-2.0.so.0
5      /usr/local/lib                libiconv.so.2
6      /usr/local/lib                libintl.so.8
7      /usr/local/lib                libpcre.so.0
8      /usr/lib                      libpthread.a        shr_comm.o
9      /usr/lib                      libpthread.a        shr_xpg5.o
10     /usr/local/lib                libslang.so.2
11     /usr/local/lib                libz.so.1

Nem szigorúan fordítás, de AIX, GNU vonzattal - és bőven befolyásolhatja egy configure kimenetelét.

Úgy tűnik, bogár került (legalább ) a 7.1 awk-jának számábrázolásába: lebegőpontosodott (vagy mi) néhány értékre feltételvizsgálat idejére.
Amíg le nem szokik erről, érdemes a gawk-ra koncentrálni.


> awk 'BEGIN {for (a=1; a<=20; ++a) { for ( k=1; k<=3; ++k) {print a,k,a^k} } }' > hatvanycsekk.lst
> awk '{ a=$1; k=$2; h=$3; x=a^k; if (x!=h) print a"^"k"="x " != " h}' hatvanycsekk.lst
3^3=27 != 27
4^3=64 != 64
5^3=125 != 125
6^1=6 != 6
7^1=7 != 7
8^3=512 != 512
9^1=9 != 9
9^3=729 != 729
10^1=10 != 10
10^3=1000 != 1000
11^1=11 != 11
11^3=1331 != 1331
12^3=1728 != 1728
13^3=2197 != 2197
14^3=2744 != 2744
15^3=3375 != 3375
16^3=4096 != 4096
17^3=4913 != 4913
18^3=5832 != 5832
19^3=6859 != 6859
20^3=8000 != 8000
> gawk '{ a=$1; k=$2; h=$3; x=a^k; if (x!=h) print a"^"k"="x " != " h}' hatvanycsekk.lst
> lslpp -w `which awk`; lslpp -L bos.rte.shell
File Fileset Type
----------------------------------------------------------------------------
/usr/bin/awk bos.rte.shell File
Fileset Level State Type Description (Uninstaller)
----------------------------------------------------------------------------
bos.rte.shell 7.1.1.1 C F Shells (bsh, ksh, csh)

5.3 alatt még normális volt.

Persze, de az egész formájú érték összehasonlításban az nem játszik.
Még ha a szövegezés talán pongyola is, a code blokk megér egy pillantást, és a man idevonatkozó sora is:

'However, even though all numbers in AWK are floating-point, integral values are always converted as integers.
Thus, given
CONVFMT = "%2.2f"
a = 12
b = a ""
the variable b has a string value of "12" and not "12.00".'

Ez nem gawk, hanem a std nyelvi spec - amit 5.3-ban még biztosan követett is az OS-sel csomagolt darab.

Egyébként ha x=a^b, ahol a==int(a), a==int(a), akkor a legrosszabb csillagzat alatt is x==int(x).

...

Közben megnéztem: még a 6.1-es awk-ja se tudathasadásos.

integral values are always converted as integers [...] Ez nem gawk, hanem a std nyelvi spec

Milyen szabvány, milyen AIX?

SUSv2, UNIX 98, UNIX 98 Server

All arithmetic will follow the semantics of floating-point arithmetic as specified by the ISO C standard

SUSv3, UNIX 03

All arithmetic shall follow the semantics of floating-point arithmetic as specified by the ISO C standard

Továbbá

Comparisons (with the '<', "<=", "!=", "==", '>', and ">=" operators) shall be made numerically if both operands are numeric, if one is numeric and the other has a string value that is a numeric string, or if one is numeric and the other has the uninitialized value. Otherwise, operands shall be converted to strings as required and a string comparison shall be made using the locale-specific collation sequence.

A numeric string meghatározását nézegetve úgy látom, hogy a, k és h már beolvasáskor numeric string-gé válnak mind (1. Field variables eset). A hatványozás eredménye (vagyis x) még csak nem is numeric string, hanem egyenesen numeric. Így az összehasonlítás egy numeric és egy numeric string között történik, vagyis lebegőpontosan. Ha szöveges összehasonlításra van szükség, akkor:

An application can force an expression [...] to be treated as a string by concatenating the null string ( "" ) to it.

Abban igazad van, hogy

A numeric value that is exactly equal to the value of an integer [...] shall be converted to a string by the equivalent of a call to the sprintf function [...] with the string "%d" as the fmt argument

azonban az idézett kódban az összehasonlítással bezárólag semmit sem konvertálunk sztringgé, csak azt követően, kiíratáshoz.

Próbáljuk meg ezt:

awk '{ a=$1; k=$2; h=$3; x=a^k; if (x"" != h) print a"^"k"="x " != " h}' hatvanycsekk.lst

Ebben az esetben ui. az összehasonlításnak egyik operandusa sem numeric (két numeric string-ről van szó), tehát szövegesen hajtódik végre.

Külön erre:

Egyébként ha x=a^b, ahol a==int(a), a==int(a), akkor a legrosszabb csillagzat alatt is x==int(x).

Ezzel, felteszem, azt állítod, hogy ha mind az alap, mind a kitevő egész (nincs törtrésze lebegőpontos ábrázolásban), akkor a hatvány ugyanígy egész lesz. Ebben nem vagyok 100%-ig biztos:

The value of the expression:

expr1 ^ expr2

shall be equivalent to the value returned by the ISO C standard function call:

pow(expr1, expr2)

Nem vagyok biztos abban, hogy a szabvány a fenti állítást megköveteli a pow()-tól (vagy a lebegőpontos ábrázolástól).

Hát, tisztelettel, megbuktam, mint Szálasi a főtárgyaláson:

A Python fordítása során egyszer csak következett egy ilyen lépés:

symlink build/lib.aix-5.2-2.7/_struct.so -> build/lib.aix-5.2-2.7/.libs/_struct.so created

ami helyett persze ez kellett volna történjen:

symlink build/lib.aix-5.2-2.7/_struct.so -> .libs/_struct.so created

Ismét igazolódott, hogy nincs kész program, csak elégtelenül tesztelt program...

Mármint a korábbi változat egy semmibe mutató szimlinket csinált:

symlink build/lib.aix-5.2-2.7/_struct.so -> build/lib.aix-5.2-2.7/.libs/_struct.so =
build/lib.aix-5.2-2.7/build/lib.aix-5.2-2.7/.libs/_struct.so

Továbbá még nem látom, hogyan lehetne rávenni, hogy használja a telepített readline-t és curses-t... a configure egy szót sem szól ezekről; most azt próbálom (reggelre meglátom, jó-e), hogy berakom a LDFLAGS enviróba, hogy '-lreadline -lcurses' (Note: tudom, igazából a LIBS-be kellene tenni)

Továbbá még nem látom, hogyan lehetne rávenni, hogy használja a telepített readline-t és curses-t... a configure egy szót sem szól ezekről

Ha ilyenek szeretnél tudni, nagyon hasznos lehet a pl. gentoo ebuildeket böngészni...

Ilyeneket lehet benne találni:

local disable
use berkdb || use gdbm || disable+=" dbm"
use berkdb || disable+=" _bsddb"
use gdbm || disable+=" gdbm"
use ncurses || disable+=" _curses _curses_panel"
use readline || disable+=" readline"
use sqlite || disable+=" _sqlite3"
use ssl || export PYTHON_DISABLE_SSL="1"
use tk || disable+=" _tkinter"
use xml || disable+=" _elementtree pyexpat" # _elementtree
export PYTHON_DISABLE_MODULES="${disable}"

OPT="" econf \
--with-fpectl \
--enable-shared \
$(use_enable ipv6) \
$(use_with threads) \
$(use wide-unicode && echo "--enable-unicode=ucs4" || echo "--enable-unicode=ucs2") \
--infodir='${prefix}/share/info' \
--mandir='${prefix}/share/man' \
--with-dbmliborder="${dbmliborder}" \
--with-libc="" \
--enable-loadable-sqlite-extensions \
--with-system-expat \
--with-system-ffi

Szóval az ipv6-ot úgy állítja, hogy --enable-ipv6 vagy --disable-ipv6, a threadeket úgy, hogy --with-threads vagy --without-threads, míg a curses és readline támogatást úgy állítja, hogy environment változóban adja át, hogy mely modulokat nem kell lefordítani.

No, valami fejlődés azért van, lett egy install soráni újralinkelés (egyelőre csak a shared objecteknél), így fixen bele lehet hardkódolni a path-okat a headerbe, pl:

$ dump -H .libs/libdevel_globus.so
                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.6.2:/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.6.2/../../..:/usr/lib:/lib                                         
1      /home/projects/devel/src/.libs libdevel_core.so.0                      
2      /usr/local/lib                libcpotlas.so.1                         
3      /usr/lib                      libc.a              shr.o               
4                                    libgcc_s.a          shr.o

(látszik, hogy az utolsó egy nünüke, akivel még csinálni kellene valamit)

$ dump -H ~/lib/libdevel_globus.so

/home/projects/lib/libdevel_globus.so:
                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.6.2:/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.6.2/../../..:/usr/lib:/lib                                         
1      /home/projects/lib            libdevel_core.so.0                      
2      /usr/local/lib                libcpotlas.so.1                         
3      /usr/lib                      libc.a              shr.o               
4                                    libgcc_s.a          shr.o

a különbség a libdevel_core.so-nál látszik: az első esetben az uninstalled, a másodikban az installed verzió van beleégetve a libdevel_globus.so-ba

Javítás után egy másik pl:

$ dump -H /usr/local/lib/libgettextlib.so
INDEX  PATH                          BASE                MEMBER
0      /usr/local/lib:/usr/lib:/lib
1      /usr/local/lib                libgcc_s.a          shr.o
2      /usr/local/lib                libglib-2.0.so.0
3      /usr/local/lib                libiconv.so.2
4      /usr/local/lib                libintl.so.8                            
5      /usr/local/lib                libxml2.so.2
6      /usr/local/lib                libz.so.1
7      /usr/local/lib                libcpotlas.so.1
8      /usr/lib                      libpthread.a        shr_xpg5.o
9      /usr/lib                      libxcurses.a        shr42.o
10     /usr/lib                      libc.a              shr.o

Ugyanez persze 64-bitre is kell... továbbá az openssl megint keresztbe tesz: valamiért nem történt meg a relinking a /usr/local/lib/engines/xxx esetén:

INDEX  PATH                          BASE                MEMBER              
0      /usr/local/lib:/usr/lib:/lib
1      /usr/local/src/openssl-1.0.0h-32/.libs libcrypto.so.1.0.0
2      /usr/local/lib                libcpotlas.so.1                         
3      /usr/lib                      libc.a              shr.o

Később: mivel ő nem is hív libtool-t, nem nagy csoda, hogy nem történik meg, ha én nem csinálom...

Egy szép napon majd a -pthread opciót is kezelni kellene (vagyis úgy tekinteni, mintha a -lpthreads is ott lenne.)

Samba-3.6.4 fordításakor valamiért azt az opciót adja a ld-nek, hogy -error_unresolved
Ez persze AIX-on azt jeleni, hogy a belépési pont a rror_unresolved; amire ő gondol, az a -bernotok lenne.

Egy ideje egy olyan érzés motoszkál a kis agyamban, hogy nem is (csak) a libtool-t kellene lecserélni, hanem a ld-t -- pontosabban elhelyezkedni a gcc és a ld között; pl:

be: aix-ld -ovalami input1.o -L/usr/local/lib -lz -lcrypto -lc
ki: ld -ovalami input1.o /usr/local/lib/libz.so.1 /usr/local/lib/libcrypto.so-1.0.1 /usr/lib/libc.a

Még mindig csak az a szerény célom, hogy az executablé-ban ban ne az legyen a függőség, hogy "libvalami.a(shr4.so)" vagy "libvalami.so" hanem az, hogy "/usr/local/lib/libvalami.so.2"... nem nagy dolog, de adott esetben ez is a működés és a nem működés közötti különbséget jelentheti... (és tapasztalataim szerint az ilyen esetek vagy hajnali egykor szoktak lenni, vagy akkor, amikor a legnagyobb az ügyfélforgalom)

Az -export-dynamic -ot (is) félreértettem, jelentése AIX-on: -Wl,-bexpall (linuxon a linkernek van egy -export-dynamic opciója, amit a gcc-ből így lehet előidézni: -Wl,-export-dynamic vagy -rdynamic)
Úgyhogy alkalomadtán legyek szíves eszerint intézkedni!

Na ez például nem fordul a régebbi gépen (5.2), de megy az újabbon (6.1):

/* tcp_ip_nomachine.c */

#include <netinet/tcp.h>

int main (void)
{
    return 0;
}

Így meg megy:


/* tcp_ip_machine.c */

#include <sys/machine.h>
#include <netinet/tcp.h>

int main (void)
{
    return 0;
}

Ezt a curl fordítása során fogtam.
Az igazi megoldás a netinet/ip.h meghackolása, az újabb változat alapján:

99a100,104
> 
> #ifndef _H_MACHINE
> #include <sys/machine.h>
> #endif
>

Tegyük fel, hogy én egy PHP-t fordítok, és keletkezne egy egy libphp5.so, csak éppen van benne pár unresolved extern, pl 'apr_pstrdup'... (eddig is volt, csak nem figyeltem rá). Ez, úgy tűnik, a libapr-1.so-ból jönne.
Vajon okoz valami gondot, ha ezt kifejezetten a php figyelmébe ajánlom (LIBS=-lapr-1 a ./configure előtt)?

Szerk: hát, kevesebb lett az unresolved, de pl: apr_brigade_flatten megmaradt.

Szerk: azok meg a libarutil-1.so-ból jönnek

Most látom, hogy van olyan is, hogy C++...
Vagyis, ha a derék felhasználó a g++ paranccsal linkel, akkor alapértelmezni kellene a -lstdc++ opciót is. Na akkor +1 fejlesztési igény;)

A g++ persze megteszi, csak az én libtool-om nem értesül róla, hogy egyáltalán volt ilyen lib, ezért nem is tud abszolút fájl-nevet hardkódolni az executabléba...
Ennek során egy olyan változtatást kellene beletegyek, hogy a parancssor feldolgozása két menetben történjen, először csak ismerkedik a paraméterekkel, különös tekintettel ezekre: cc/gcc vs c++/g++, -m32/-maix32 vs -m64/-maix64, -pthread[s]... jelenleg csak egyszer megy végig, és ha pl talál egy olyat, hogy '-liconv', akkor rögtön meg is keresi az iconv-ot... ebből a múltkor volt is valami gond, csak nem emlékszem pontosan, hogy mi;)

Na varj, azert a libstdc++ az az alaprendszer reszenek kene legyen, tehat ha tokveletlenul nem abszolut uttal hivatkozol ra, abbol meg baj nem nagyon szarmazhat (sztem), mert az minden AIX-en ugyanott kellene legyen, es nem is jo otlet felulvagdosni. Szerintem kicsit eltulzod ezt a dolgot.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Nem is helyezem át sehová, csak annyi az egész, hogy ne <bárhol>/libstdc++.a formában kerüljön az exébe, hanem /usr/lib/libstdc++.a formában... az igaz, hogy ez persze hiszti;) de ha már a nem-standard libeknél szükség van erre, akkor akár általános szabályt is csinálhatok belőle... ha beírok egy 'dump -H exe'-t, akkor azt szeretném látni, hogy minden shared-libnél van path, nem csak néhánynál.

Persze, az egész amúgy is csak egy hobby-projekt, a 'nagyon ráérek' időkre... Konkrétan csak arról van szó, hogy amikor beírom, hogy pl 'dump -H /usr/local/bin/re2c', akkor megnyugtat a látvány, hogy minden shared lib előtt van path, nem kell gondolkozni, hogy melyiknek nem kell, melyiknek kellene.

INDEX  PATH                          BASE                MEMBER              
0      /usr/local/lib:/usr/lib:/lib
1      /usr/local/lib                libgcc_s.a          shr.o
2      /usr/local/lib                libstdc++.a         libstdc++.so.5
3      /usr/local/lib                libcpotlas.so.1
4      /usr/lib                      libc.a              shr.o

Szerk: most hogy ez így feljött, hirtelen nem is tudnám megmondani, hogy ez a /usr/local/lib/libstdc++.a fájl honnan jött... 'lslpp -w' és 'rpm -qf' nem segít. Dátuma 2004-04-23...

Igen, ezen mar gondolkodtam, hogy szoljak-e. Meg mindig nem vagyok biztos a dolgomban, de... mi lenne, ha a felrakott csomagokhoz irkalnal SPEC fajlokat, es RPM-kent raknad fel oket? Tudom, hogy nem igazan RPM alapu disztrorol beszelunk, de megis-megis... nagyobb biztonsagban lennel. Peldaul egy veletlen felulvagas ellen.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Valóban, egyes házi fejlesztgetésimből már csináltam .rpm csomagot, de arra nem vállalkoznék, hogy mondjuk egy php sokszáz fájlját átnézzem és csomagba szervezzem...

Szerk: Bár állítólag vannak ilyesmire is eszközök, pl: http://asic-linux.com.mx/~izto/checkinstall/

Ja és a PHP-5.3.13 ban már kell a -bbigtoc opció a linkelésnél... és még úgy is sír, hogy "Extra instructions are being generated for each reference to a TOC symbol if the symbol is in the TOC overflow area."... Akkor én most mit csinálják, adjak neki papírzsepit?

Szintén nem (jól) megy a régebbi gépen a strptime:

/* strptimetest.c */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

static void Test1 (const char *str, const char *fmt);

int main (void)
{
    Test1 ("20120531", "%Y%m%d");
    Test1 ("20120532", "%Y%m%d");
    return 0;
}

static void Test1 (const char *str, const char *fmt)
{
    struct tm tm;
    const char *p;

    memset (&tm, 0, sizeof (tm));

    p= strptime (str, fmt, &tm);
    fprintf (stderr, "strptime(%s,%s) returned %p\n", str, fmt, p);
}

A Midnight Commander jobban bele tud menni a zip fájlokba, ha */etc/mc/mc.ext-ben csinálunk egy ilyesmi módosítást:

622c622
< type/^([Zz][Ii][Pp])\ archive
---
> type/\(.zip\)\ compressed\ archive

Épp azért, mert a *.jar/war/ear is zip-file, ezeket nem kiterjesztés alapján ismeri fel a mc (az lenne a "regex" a mc.ext-ben), hanem meghívja a file(1) utilityt, és annak a válaszát elemzi (ezt jelenti a "type" a mc.ext-ben). Épp csak a 'file' kimenete rendszerfüggő:

Linuxon:
$ file ~/lib/DevelJni.jar
/home/zsiga/lib/DevelJni.jar: Zip archive data, at least v1.0 to extract

AIX-en:
$ file ~/lib/DevelJni.jar
/home/projects/lib/DevelJni.jar: PKZIP (.zip) compressed archive

Off: Ha most élnénk a UNIX gyerekkorát, nyilván elkezdenénk egy 'libfile' kifejlesztésén gondolkozni (vö: gzip és libz, iconv és libiconv, stb)... sajnos már késő: mostanra általános gyakorlattá vált, hogy a programok emberi olvasásra szánt outputját más programok olvassák, és próbálják jól/rosszul megérteni, ahelyett, hogy a (legtöbbször nem is létező) program-interfészt használnák.

Ezt nem tudtam, nagyon hasznos feature-nek tűnt... de azért elmentem arra bizonyos régi AIX-re is, hogy ott is kipróbáljam:

$ file ~/devel/java/DevelJni.jar
/home/projects/devel/java/DevelJni.jar: PKZIP (.zip) compressed archive

$ file -i ~/devel/java/DevelJni.jar
/home/projects/devel/java/DevelJni.jar: regular file

Szerintem inkább az lehet, hogy AIX-en a '-i' nem azt jelenti, mint GNU-ban (ahol az a --mime szinonímája)... persze ha tényleg fontos lenne, azonnal telepítenék egy GNU-file-t;)

Szerk: tévedtem, semmi köze a GNU-hoz. Itten van: ftp://ftp.astron.com/pub/file/file-5.11.tar.gz

Szerk: Akkor telepítem is a gépekre. A másodikon már meg is akadt, mert a liberr-t nem linkelte hozzá. Csak tudnám, mi az...

Szerk: Bevallom, az unzip-re nem gondoltam, hogy honnan is jön (az Oracle-ből jött, amelyik gépen van Ora), úgyhogy máris generáltam magamnak egy újabb feladatot... bár, ha jól csalódom, az unzip fordításáról már volt szó ebben a topikban.

A következőn gondolkozom: mondjuk javában fejlesztünk -- mármint Javában fejlesztünk, de az egyik derék coder latin2-ben, a másik utf8-ban. A gond ott van, amikor (napokkal vagy évekkel) később valaki fordítani akar, honnan fogja tudni, hogy milyen -encoding opciót adjon meg a javac-nak.

Természetesen egy ideális világban hatalmi szóval lehetne egyértelműen kiválasztani és kötelezően előírni az utf8-at, de most tegyük fel, hogy még nem vagyunk a fejlettségnek ezen a fokán; viszont azt esetleg el lehet várni, hogy a derék koder a fájl elejére valami ilyesmi kommentet tegyen:

/* ezanave.java encoding="cp852" */

Ezek után a fordítást egy spéci programocska végezné (pl enc_javac néven), ami beleolvasna a file-ba, és ha találna ilyen encoding-ot akkor azt továbbítaná az igazi javac-nak.

Ne a forrasban legyen. Kell csinalni egy properties fajlt, aztan abba tolja bele az ilyeneket, akkor meg ant-bol is fel lehet nyalatni.

Amugy meg... tudom, hogy irto geci vagyok... de asszem a file parancs pont ki tudja talalni (pontosabban, el tudja donteni, hogy UTF vagy ISO-8859, viszont ha ISO, az alverziot mar nem talalja ki, es van nemi kulonbseg az ISO-8859-1 es az ISO-8859-2 kozott... de remenykedjunk, hogy azert annyira csak nem okor valaki, hogy latin1-ben nyomja).

De amugy, mintha a javac-ban lenne valami ilyen intelligencia... bar nalatok 1.4 van... akkor nem tudom. De az biztos, hogy NE a forrasfajlban legyen, ez ugyanis irto csabito arra, hogy 2 fajl ket kulon kodolasban legyen. Ez pedig nem jo.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Egy újabb gépen gettext nem fordul, sqrt és ceil hiánya miatt. Erre megoldás lesz a LIBS='-lm', csak nem értem, hogy a többi gépen miért nem kellett kézileg megadni...
Szerk: ja, hogy ezen nincs telpítve... valószínűleg a többin is csak azért van, mert az Ora installhoz kellett...

Ja, nem volt /usr/ccs/lib/libm.a (sem /usr/lib/libm.a link). Ne kérdezd, ki telepített (úgy hallottam, az IBM Mo egyik tudós szakértője, de nem tudom pontosan, én csak egy kétkezi programozó vagyok, nem rendszergazda).
Szerk: persze nem olyasmi ez, amit a scp ne tudna megoldani...

Gyors kérdés: akkor mi van, ha a glib és a pkg-config kölcsönösen függenek egymástól?

Szintén a mc.ext-be a *.so fájlokhoz:

# .so libraries
regex/\.(so|so\.[0-9\.]*)$
        View=%view{ascii} file %f && nm -C %f

vagyis kimarad a 'nm' -D opciója, ami itt nincs