Erre:
gcc $(/bin/sh lfs.sh CFLAGS) -D _XOPEN_SOURCE=500 -pipe -ansi -pedantic -O3 -c main.c
getconf: no such configuration parameter `_XBS5_ILP32_OFFBIG'
nagyon egyszerűt fogok mondani: nem SUSv2 a getconf-od. Ha megnézed a README-ben az Installation alatti első mondatot:
Please enable SUSv2 conformance in your environment.
Hogy ezt a saját rendszereden hogyan tudod megtenni, abban nem tudok segíteni. Ha megnézed az lfs.sh-t, van benne egy glibc-s bugreport-azonosító, mivel még a glibc getconf-ja sem volt valóban SUSv2 konform. Legnagyobb megdöbbenésemre Ulrich Drepper a mai napon elfogadta a bejelentésemet és a CVS-ben javította a getconf-ot.
Megkérdezheted, hogy ha alapvetően az a hozzáállásom, hogy a rendszer csináljon SUSv2 kompatibilitást, akkor miért kivételezek a GNU/Linux-szal, és azon belül is a Debian-nal, vagyis azokra miért rakok be workaround-ot. (Lásd az lfs.sh-t, ill. az Installation-beli záróljeles tippet GNU/Linux felhasználóknak.)
Azért, mert azon dolgozom, és az arra való specifikus workaround-ot képes leszek karban tartani. FreeBSD-t sajnos még sosem láttam, de ha küldenétek is rá most érvényes workaround-ot, akkor sem tenném be, mert nem tudnám karbantartani, tehát az upstream tarball-ban rátok lennék utalva, vagy közösségi projektté kellene tennem az lbzip2-t.
Annak persze nagyon örülnék, ha valaki csinálna rá egy kívül karbantartott port-ot :)
A
_SC_THREAD_THREADS_MAXmakróval ugyanez a helyzet: ha nem tudja a libc-d, akkor vagy nem SUSv2 módban vagy, vagy a libc-d nem SUSv2.
OSF1: Az OSF1 az általam látott egyik, a SUS-hoz leghívebb OS. Már a SUSv1 (UNIX 95) időkben is LP64 volt! Természetesen van rajta SUSv2 shell, le is van írva, hogyan kell használni (talán standards(5) man lap, BIN_SH és egyebek), csak te szerintem nem állítottad be / nem adtad át a make-nek. OSF1-en (ex has, már nem emlékszem pontosan) leginkább így kellene fordítani:
$ # beállítjuk a SUSv2 környezetet, majd
$ make -f Makefile.portable SHELL=/path/to/SUSv2/shell
Ha jól emlékszem, OSF1-en (Tru64-en) a standards(5) két dolgot ír elő SUSv2-höz: az egyik a BIN_SH, a másik pedig az, hogy a PATH-od elejére be kell tenni valami extra könyvtárat, ami megdöbbentő módon két binárist tartalmaz: egy
shnevűt, és egy
makenevűt... :)
Tehát OSF1-en nem ostoba sem a shell, sem a make, csak te nem azokat a változatokat használtad belőlük, amelyeket én a README-ben kértem tőled.
Read The Fine Manual, please :)
(Annyit azért megjegyzek, hogy az OSF1-en a <pthread.h> elkezd sírni, ha nincs -pthread kapcsoló megadva a c89-nek. Na ez borzasztó hiba, nem is értem, hogyan nem bukott meg rajta a SUSv2 tanúsítványuk. Nincs workaround, javítsák meg a Tru64-et, vagy minden Tru64-es felhasználó szitkozódva írjon bele a Makefile.portable-be.)
Amit mondani akartam, h szep es jo az a SUSvx, es h torekednek egyseges szabvanyra, de nem mindig jon ossze a dolog az egyedi aprosagok miatt. Ezt szoktak megoldani azzal, h kulonbozo platformokhoz kulonbozo Makefile-okat dobnak ossze
Hát nem tudom megállni, ide be kell raknom, amit az egyik segítőkész huppernek írtam:
Például a p7zip-et gcc-vel akartam fordítani Tru64-en. A p7zip-ben van kb. 20-30 makefile, van köztük olyan, aminek az a neve, hogy makefile.tru64_gcc, vagy valami ilyesmi. (Az általam elvárt platform compiler-t (c89) nem használja, de nem is használhatná, mivel a p7zip nagyrészt C++-ban van megírva, C++-ra a POSIX pedig egyáltalán nem tér ki tudtommal.) Nosza, az INSTALL doksi szerint
$ cp makefile.tru64_gcc makefile.machine
$ makeLáss csodát, nem működött, bele kellett turkálnom, mert amióta a makefile.tru64_gcc készült, azóta kijött új gcc, kijött új Tru64, és így tovább.
A konkrét problémára nem emlékszem, de bele kellett reszelnem valamilyen plusz kapcsolót -- azt hiszem, a Tru64-en a
megakasztotta a fordítást, ha a compiler előzetesen nem kapta meg a -pthread kapcsolót. A -pthread persze borzasztóan nem standard, de az isten szerelmére, nekem a platformhoz adott specifikus "makefile.tru64_gcc"-t kellett emiatt reszelnem!Vagyis hiába vette Igor Pavlov és barátságos felhasználói a fáradtságot a 20-30 makefile elkészítésére, ezek közül up-to-date jó ha 3-4 van, saccra.
Amugy ha gondolod, megfixalom a fentieket ugy, h minnel kevesebb helyen kelljen modositani a kodod.
Köszönöm, de az általam kiadott csomagba nem akarok ilyet beletenni. Az én véleményem az, hogy a kód (C, shell, Makefile.portable), amennyire csak kitellett tőlem, a SUSv2-höz igazodik. Az eddig bejelentett problémák (amelyeket persze köszönök) mind arról szóltak, hogy "a rendszerem nem tudja a SUSv2-t, vagy nem állítottam be rajta a SUSv2-t". Úgy érzem, az ilyen gondok csomagbeli elhárítása nem az én feladatom (mellesleg egyszerűen nincs is kedvem hozzá, bántja a kis kényszeres szépérzékemet). Úgysem tudnám olyan jól megcsinálni (külső segítséggel sem), mintha valaki összetolna az adott rendszerhez egy rendes, központi fába kerülő, karbantartott patch-et, port-ot, ahogy én is csináltam a debian-hoz. (Persze hogy bekerül-e egyáltalán, az jó kérdés.)