Az élet igazolni akarta előző megérzésemet, miszerint nem valami szerencsés olyasmiket belehardkódolni az exébe, hogy 'PATH=/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/4.0.2' SHOBJ='libgcc_s.a'... ugyanis új gcc verziót telepítettünk, és most az újrainduláskor nem indult, aminek kellett volna...
(Persze akkor sem lett volna jobb, ha az lett volna benne, hogy 'SHOBJ=/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/4.0.2/libgcc_s.a', hiszen a kedves rpm az update alkalmából leszedi a régi, feleslegessé vált libgcc_s.a-t.)
Persze nem akkora baj ez, amit a sed ne tudna javítani...
Szerk:
Persze értem, hogy jót akarnak, meg sok a különféle rendszer; meg az ózonlyuk és a savas eső... olyasmit akarnak mondani, hogy 1.0.0*-tól az 1.0 lesz a 'major', a 0 a minor, és a '*' (betű) pedig csak úgy ottan van, ehhez képest a Makefile-ban ez van:
Azert van kulon valasztva az shlib version, mert maga a frissites olyan osztott konyvtarat eredmenyez, mely szabadon felcserelheto a korabbi, 1.0.0-s verzioju shlibbel, ugyanis mind API, mind pedig ABI szinten kompatibilis, csak mukodes tekinteteben valtozott, felulet tekinteteben nem. Ezert nem szoktak osztott konyvtarnal az utolso szamot surun valtoztatni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
A 'file' nevű komponenst említettem a múltkor, annak meg az a trükkje, hogy használná az 'asprintf'-ben a '%zu' szekvenciát; de mivel az AIX-nek nincs ilyen asprintf-je, hát a saját hozott asprintf-jét használja. Amelyik nem ismeri a '%zu'-t. Jajjanyám.
Ja, és az openssl-nek (illetve a licryptonak) kell a libz.so
Persze ez csak futáskor derül ki: dlopen-t hív, ha az megtalálja valahol (path nincs -- security?), akkor jó, egyébként nem.
Kieg: az nem segít, ha hozzászerkesztjük az executable-hoz a libz.so-t.
Kieg: a forrásban kommentként benne van, hogy a Windows kedvéért csinálja dlopen-nel (illetve LoadLibrary-val, de ez most mindegy),hogy akkor is menjen, ha nincs zlib.dll
openssl-ről szólva: lehet, hogy arra gondoltak, hogy az 1.0.1 kompatibilis az 1.0.0-lal, ezért jó lesz, ha a major verzió-t 1.0.0-ra állítják.
Ahogy én látom, ugyanezt a múltban ragadt, korszerűtlen keményvonalas linuxosok úgy csinálták volna, hogy csak az 1.0-t nevezik major verziónak, a végén lévő 1-et pedig minor-nak.
vl írta 2011. október 4-én ('install' működésére):
> > Szóval inkább én szépen másolom, ha az nem megy,
> > akkor törlöm+létrehozom (törölni akkor is lehet, ha busy).
> Inkább temp, generált néven ugyanabba a könyvtárba létrehozni + rename.
> - nem fordulhat elő, hogy a törlés után nem tudod megcsinálni a fájlt
> - egyetlen mikroszekundumig sem lesz olyan állapot, amikor nincs ott a fájl
Nagyon jó meglátás, azzal a kiegészítéssel, hogy egy library esetén eleve meg sem szabad próbálni az open-t (outputra), mert az AIX-szal szemben a linux nem ad ETEXTBUSY-t, hanem engedi felülírni a shared-libet, akkor is, ha használatban van -- csak éppen a használó programok döglenek ki...
Az új linux rendszerem (Debian-6) azzal a jó hírrel fogadott, hogy az 'rpm -bb' megszűnt működni, ott az 'rpmbuild'... Ugye nem is kell mondanom, hogy az AIX-en lévő régebbi rpm-hez nincs ilyen rpmbuild... Mennyire megkönnyítik az ilyen inkompatibilis felesztések a scriptek készítését!
Ilyesmi, csak az rpmbuild még 'fejlettebb' is, más szóval nem egészen sikerült még működésre bírni... (még a végén visszateszek egy korábbi rpm-et az előző verzióból)
Viszont hasonló módszerrel alkottam egy 'hostname-f' programot, ami linuxon 'hostname -f' -et hívja, AIX-on meg a resolv.conf-ból veszi ki a domaint.
" AIX-on meg a resolv.conf-ból veszi ki a domaint."
Csakhogy ez igy nem korrekt.
A hostname -f linuxon azt csinalja, hogy a hosts fajlban keresi meg a gepen levo ip-khez torteno elso matchelot, es a megfelelo entrynel addig nyalja a gepneveket, amig olyat nem talal, ami ugy kezdodik, mint a gepnev.
C-ben ez egyszerubb, ha elo tudod szedni a gepen levo osszes IP-t, akkor gethostbyaddr() -ral lekered, es vegigszaladsz a h_alias tombon (asszem ez a neve) egy strncmp-vel.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
A linux-os hostname nem fordul AIX-en, mivel a linux-specifikus ifaddr.h -t használja...
gondolom, az kb hasonlókat tud, mint a net/if, csak legalább nem hordozható...
Egyébként régen a hostname a coreutils része volt, csakis emiatt fordítottam a legújabb coreutils-t (gmp-vel együtt, amihez a libtool-t is haxolnom kellett), azután örömmel láttam, hogy a 'hostname' maradt a régi.
Most hallom, hogy valaki xlc-vel fordít/szerkeszt... ez persze az ő szomorú magánügye, de most összehasonlításképp jó lenne tudnom, hogy mi ott a -Wl,-bmap:mapfile megfelelője. (Vagyis átadni a linkernek némi opciókat.)
Ami megint 'trailing_slashes' hibákat talált, az open-ben meg a symlink-ben. Vajon ki az, akinek olyanokon jár az agya, hogy 'ej ejj, micsoda dolog az, hogy pl a 'cat /etc/passwd/' kiírja a fájl tartalmát, ahelyett, hogy hibát dobna -- de majd én kijavítom'
Az apache-2.4.3 alkalmából ismét egy kis javítás/szépítés: igenis vannak olyan helyzetek, amikor nincs 'lib' a shared object előtt, pl a mod_cache_disk.so használja a mod_cache.so-t.
---
Persze a régi PHP nem megy az új Apache-csal...
Syntax error on line 235 of /usr/local/etc/apache2/httpd.conf:
Cannot load libexec/apache2/libphp5.so into server:
0509-130 Symbol resolution failed for /usr/local/libexec/apache2/libphp5.so because:
0509-136 Symbol ap_log_error (number 1057) is not exported from dependent module httpd.
0509-136 Symbol ap_log_rerror (number 1058) is not exported from ependent module httpd.
0509-136 Symbol ap_get_server_version (number 1068) is not exported from dependent module httpd.
0509-136 Symbol unixd_config (number 1076) is not exported from dependent module httpd.
0509-192 Examine .loader section symbols with the 'dump -Tv' command.
---
Hasonló nevű szimbólumok persze vannak, pl:
ap_log_error_
ap_log_rerror_
ap_get_server_revision
ap_unixd_config
Gondolom, ennyi változás belefér a verzióváltás szabadságába... vagy mibe...
---
Most éppen a php-5.3.13 újrafordítása sem megy a "meta_ccld" hiánya miatt. (Én még a létezéséről sem tudtam, most meg a hiányával kell szembesülnöm...)
---
Ami egyébként van -- vajon melyik komponens nem találja, és miért nem találja?!
---
Én nem találom. Mármint az én libtoolom. A program nevét vizsgálom, hiszen az opciók értelmezése attól függ.
---
Nyomozásom szerint ez azt jelentheti, hogy valahogy(?) érvényre jutott a --enable-maintainer-zts opció a ./configure során... Az ilyesmi megesik...
---
Nem segített a --disable-maintainer-zts sem. Akkor az UFÓK lehetnek a hibásak.
---
Vagy a szerver verziószáma (aszerint ágazik el a ./configure egy ponton):
Syntax error on line 271 of /usr/local/etc/apache2/httpd.conf:
Invalid command 'User', perhaps misspelled or defined by a module not included in the server configuration
Az van ott, hogy "User www-data"... ezzel vajon mi a gond?
Ma kipróbálom, köszi. (Valószínűleg sok ilyen modulka fog még hiányozni -- majd lesek valahonnan; végül is 2.2.21 és 2.4.3 között azért mégiscsak történhetett némi változás.)
No, van új pipacs Apache, multithread és multiprocess közül lehet választani, egyelőre multithread-dal megyünk (mpm_worker), de ha valami gyanús jelet látok, visszamegyünk a régi üzemmódba (mpm_prefork).
Akkor jó;) Persze alig hogy kész van, már jött is egy júzer, aki Shift+F11-et szeretne használni, kf21 értelemben... naná, hogy eddig csak kf1-kf20 volt a programban...
Még azt mondja meg valaki, hogy a libstdc++ -szal csak akartam valamit kezdeni, vagy csak erősen rágondoltam, és nem csináltam vele semmit -- legalábbis most, úgy látom, nem megy.
Na szóval aljas módon a libstdc++.so-t is kirángattam békés fészkéből (értsd: tartalmazó .a fájljából), és besymlinkeltem a /usr/local/lib-be. A .la fájlt kicsit meg kellett haxolnom, de most valamennyire megy:
És még mindig hátra lenne az a feature, hogy .la fájl nélkül is menjen a verziókezelés (házi feladat magamnak), vagyis ha megtalálja a libstdc++.so -t, és látja rajta, hogy az symlink, akkor a target alapján (libstdc++.so.6.0.16) megpróbálja meghatározni a major verziószámot, magyarul: keres egy libstdc++.so.6 vagy libstdc++.so.6.0 nevű linket, aki ugyanarra a targetre mutat (az előbbit fogja megtalálni), és azt használja a linkeléshez).
Azt olvasom, hogy 7.x-ben már van dirfd. Ez egy másik megfogalmazása annak, hogy 5.x-ben és 6.x-ben nincs.
Azt mondják ugyanis, hogy a readdir_r előtt egy name_max = fpathconf (dirfd (dir), _PC_NAME_MAX) az igazán kúlos, kevésbé menő a name_max = pathconf (dir, _PC_NAME_MAX) -- ugyanis a dir az változhat is (vö: multitaszk, symlink, stb), akár meg is lehet haxorizálni a programot ilyen módon.
checking whether rename honors trailing slash on destination... no
checking whether rename honors trailing slash on source... no
Szerintem ez valakinek a fixa ideája, hogy poénból felesleges perjeleket tesz a nevek végére, és ellenőrzi, hogy kap-e hibaüzenetet a különféle rendszerhívásoktól...
checking whether rename manages hard links correctly... no
checking whether rename manages existing destinations correctly... no
Az egyik arra céloz (talán), hogy ez nem teljesül:
"If oldpath and newpath are existing hard links referring to the same file, then rename() does nothing, and returns a success status."
Szerk: Na jó, ez én voltam: a 'local_rename' a 'local_symlink'-ből keletkezett (igen, copy+paste fejlesztés), és egy ponton bizony 'symlink' maradt benne 'rename' helyett. Ciki.
A mappa/fajl megkulonboztetes miatt szokas perjelet tenni a fajl vegere - bar amennyire tudom, jelenleg nincs olyan FS, ami ugyanolyan nevu fajlt es mappat is engedne egyazon mappan belul.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
Senki sem érezte feladatának, hogy engem tájékoztasson erről az opcióról;)
(A legutóbbi ilyen felfedezésem a -mtune=native volt: hátha a gcc is ki tudja találni, hogy pontosan milyen az aktuális CPU, és nem nekem kell belevasalnom a Makefile-okba egy platformfüggő információt)
Csak arra gondolta, hogy
- mondhatna mondjuk fordítási (mármint amikor a clang-ot fordították) beállításokat
- ha már igyekszik minden gcc opciót ésszel értelmezni, erre is szebb lenne annyi, hogy "Sorry, ez értelmetlen a clang-ban", mint az, hogy "unsupported option"
/* itt valami nagyon izgalmas dolog történik, aminek
kb annyi a lényege, hogy összezavarja a Pro*C-t
#if (defined(__IBMC__) || defined(__IBMCPP__))
#if ((defined(__STDC_WANT_DEC_FP__)) && !(defined(__IBM_DFP__)))
#if defined(__IBM_PP_WARNING)
#warning The -qdfp option is required to process DFP code in headers.
#else
#error The -qdfp option is required to process DFP code in headers.
#endif
#endif
#endif
*/
Na jó, hát lehet, hogy nem kizárólag a gdb-team a hibás, inkább csak annyi, hogy fel sem merült bennük, hogy esetleg nem csak linux+gcc a világ... szóval ha /usr/local/include/unistd.h -ba beteszünk egy ilyet:
Ha üres stringet keresünk, az jön vissza, hogy 'nincs benne'. A matematikusi beállítottságú programozó inkább azt mondaná, hogy: de igen, pont ott van a legelején...
Nem erted, az a lenyeg, hogy konkret karakterpoziciot kell megjelolni. Ha a nulladik poziciot jeloli meg - az nem az, ha az elsot - az sem. Az ures sztring az pontosan minden feledik pozicioban van jelen - viszont nem adhat vissza tortszamot.
Nem adhat vissza ervenyes poziciot, mert ilyen nincsen, ha visszaad, nem ellenorizheto vissza.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
Na pontosan ennek nem lenne szabad lennie benne, mert a gdb-nek akkor is mennie kellene, ha a forrást törlöm a /usr/local/src-ből.
PS: Megnéztem egy másik gépen a gdb-7.3.1-et, a hiba ott is fennáll. (Ismét igazolódott a régi mondás, hogy hiba csak ott van, ahová nézünk. Vagy fordítva: ahova nézünk, ott találunk egy hibát.)
Nagyobb kompatibilitás miatt a *.la fájlokban ezentúl két dependency_libs lesz, az egyik a hagyományos libtool-nak, a másik önmagunknak, a különbség a la-nélküli libek tárolásában van:
Na nem mintha kezdeném megkedvelni a hagyományos libtool-t... nemcsak hogy a major-verziókat nem tárolja (az egész projekt ezzel kezdődött ugyebár), de a relatív path-nevek használata is elég furcsán tud kinézni, pl:
Megpróbálom orvosolni a /opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.6.2/include-fixed/sys/types.h fájl törlésével jó hályogkovács módra.
Mi történhet? Legfeljebb minden borul. Az meg így is úgy előfordulhat.
En ezeket a fajlokat nem torolni szoktam, csak be gzippelni. Az pont annyira elrejti az app elol, hogy mar ne lassa, megis helyben maraud, es barmikor visszacsomagolhato, ha kell.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
md4_dgst.c: In function 'md4_block_data_order':
md4_dgst.c:111:2: warning: implicit declaration of function 'asm' [-Wimplicit-function-declaration]
md4_dgst.c:111:2: error: expected ')' before ':' token
ugyanis az 'alloca' nem externként kellene működjön, hanem 'valahogy speciálisan'
Ez a problémát is a -std=c99 opció okozza valamiképpen...
vagy ha effektíve include-oljuk az alloca.h-t (amolyan kultúrember módjára), akkor sincs baj.
A jáváról van szó, hogy pontosítsam: ugyebár JNI esetén behúz egy libValamiJni.so-t. De persze az a libValamiJni.so csak egy közvetítő, az igazi monkát a libvalami.so végzi. Mármint, ha a dlopen megtalálja a libvalami.so-t. Van ugyan egy -Djava.library.path=
opció, de az csak a libValamiJni.so betöltésében segít, a további betöltésben nem.
Valamiért jobban tetszik nekem a gondolat, hogy legyen benne a path magában az elemben... ezt a 'rendes' libtool is megteszi.
Közben született még egy szépítési igény: kis programocskám a --mode=install során megismétli a linkelést, ami persze még nem bűn, csak éppen nem törli maga után az átmeneti fájlt. Még ez sem lett volna baj, ha nem kellene néha root-ként installálni (/usr/local/bin-be), néha meg mezei userként (/home/projects/sms/bin) -- az előbbi lehetetlenné teszi az utóbbit. (Persze az is igaz, hogy ebben a konkrét esetben ez elhárítható, de temporális fájlt hagyni magunk után mindenképp hiba.)
Ez a hibajelenség: ld: 0711-931 SEVERE ERROR: Output file: .libs/smssendI
The file is write-protected.
collect2: ld returned 12 exit status
Ez is megvan... lassan, de biztosan közeledünk a béta-tesztelhető állapothoz... Mondjuk gyenge pontja a dolognak, hogy rajtam kívül senki se kíváncsi rá -- persze meg is értem: ki akarna egy teszteletlen termékkel kísérletezni a céges gépen. (Mármint engem kivéve: az egóm mérete és a kísérletezőkedvem messze túllépi a mezei programozótól elvárhatót.)
Nekem, mint uzemeltetonek viszont a hatam borsozik az ilyen megoldasoktol. Linuxon amugy a legtobb "nagy" gyarto siman LD_LIBRARY_PATH-tel adja meg, hogy mi hol van, es csa. Ez legalabb tud dinamikus is lenni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
Hozzászólások
Subscribe. Es kosz.
--
+1
Off: Miért nem blog, ha már blogként írod?
Mert nem tudom (értsd: nem is próbáltam, eszembe se jutott), hogy hogyan kellene/lehetne.
http://hup.hu/node/add/blog
--
Az élet igazolni akarta előző megérzésemet, miszerint nem valami szerencsés olyasmiket belehardkódolni az exébe, hogy 'PATH=/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/4.0.2' SHOBJ='libgcc_s.a'... ugyanis új gcc verziót telepítettünk, és most az újrainduláskor nem indult, aminek kellett volna...
(Persze akkor sem lett volna jobb, ha az lett volna benne, hogy 'SHOBJ=/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/4.0.2/libgcc_s.a', hiszen a kedves rpm az update alkalmából leszedi a régi, feleslegessé vált libgcc_s.a-t.)
Note to self: az 'ar'-nak linuxon nincs -X32/-X64 opciója... (bár van egy -X32_64, ami egyben alapértelmezés is)
Szerk: 'nm'-re ugyanez igaz
Szerk: és itt külön van a /lib64 meg /usr/lib64
Emlékeztető magamnak: nyomozni kellene, miért lett az openssl-1.0.1-ből openssl.so.1.0.0?
Csak egy tipp:
/usr/local/src/openssl-1.0.1c-64# grep 1.0.0 crypto/opensslv.h#define SHLIB_VERSION_NUMBER "1.0.0"
Mert minor verziovaltas volt, API verzio valtas nem tortent.
--
Persze nem akkora baj ez, amit a sed ne tudna javítani...
Szerk:
Persze értem, hogy jót akarnak, meg sok a különféle rendszer; meg az ózonlyuk és a savas eső... olyasmit akarnak mondani, hogy 1.0.0*-tól az 1.0 lesz a 'major', a 0 a minor, és a '*' (betű) pedig csak úgy ottan van, ehhez képest a Makefile-ban ez van:
Az én egybites agyam szerint az alábbi kettő valamelyik kellene legyen:
#1: régi meglátás: minden verzió különbözik
#1: új meglátás: az utolsó számjegy kis változást jelent:
Nem.
Azert van kulon valasztva az shlib version, mert maga a frissites olyan osztott konyvtarat eredmenyez, mely szabadon felcserelheto a korabbi, 1.0.0-s verzioju shlibbel, ugyanis mind API, mind pedig ABI szinten kompatibilis, csak mukodes tekinteteben valtozott, felulet tekinteteben nem. Ezert nem szoktak osztott konyvtarnal az utolso szamot surun valtoztatni.
--
A 'file' nevű komponenst említettem a múltkor, annak meg az a trükkje, hogy használná az 'asprintf'-ben a '%zu' szekvenciát; de mivel az AIX-nek nincs ilyen asprintf-je, hát a saját hozott asprintf-jét használja. Amelyik nem ismeri a '%zu'-t. Jajjanyám.
Javítottam "%lu"-ra, így már jobban kijön a hiba:
Ne is kérdezzem, hogy minek neki nulla bájt, igaz?
Szerencsére erre már egyszer hackoltam megoldást (local_malloc és társai: size=0 esetén egy spéci címet adnak vissza), most sokkal jobb: core dump...
A mag domping az jo!
--
Ja, és az openssl-nek (illetve a licryptonak) kell a libz.so
Persze ez csak futáskor derül ki: dlopen-t hív, ha az megtalálja valahol (path nincs -- security?), akkor jó, egyébként nem.
Kieg: az nem segít, ha hozzászerkesztjük az executable-hoz a libz.so-t.
Kieg: a forrásban kommentként benne van, hogy a Windows kedvéért csinálja dlopen-nel (illetve LoadLibrary-val, de ez most mindegy),hogy akkor is menjen, ha nincs zlib.dll
openssl-ről szólva: lehet, hogy arra gondoltak, hogy az 1.0.1 kompatibilis az 1.0.0-lal, ezért jó lesz, ha a major verzió-t 1.0.0-ra állítják.
Ahogy én látom, ugyanezt a múltban ragadt, korszerűtlen keményvonalas linuxosok úgy csinálták volna, hogy csak az 1.0-t nevezik major verziónak, a végén lévő 1-et pedig minor-nak.
Mint például a libz.so.1.2.3.4-ben az 1 a major, a 2.3.4 a minor (érdekes egy verziószám egyébként;)
vl írta 2011. október 4-én ('install' működésére):
> > Szóval inkább én szépen másolom, ha az nem megy,
> > akkor törlöm+létrehozom (törölni akkor is lehet, ha busy).
> Inkább temp, generált néven ugyanabba a könyvtárba létrehozni + rename.
> - nem fordulhat elő, hogy a törlés után nem tudod megcsinálni a fájlt
> - egyetlen mikroszekundumig sem lesz olyan állapot, amikor nincs ott a fájl
Nagyon jó meglátás, azzal a kiegészítéssel, hogy egy library esetén eleve meg sem szabad próbálni az open-t (outputra), mert az AIX-szal szemben a linux nem ad ETEXTBUSY-t, hanem engedi felülírni a shared-libet, akkor is, ha használatban van -- csak éppen a használó programok döglenek ki...
Annyira bevált, hogy a symlink-et is így fogom csinálni:
volt: symlink(végleges) || unlink && symlink(végleges)
lett: symlink(temporál) && rename
Előnye ugyanaz: nincs olyan pillanat, amikor nincs symlink.
Az új linux rendszerem (Debian-6) azzal a jó hírrel fogadott, hogy az 'rpm -bb' megszűnt működni, ott az 'rpmbuild'... Ugye nem is kell mondanom, hogy az AIX-en lévő régebbi rpm-hez nincs ilyen rpmbuild... Mennyire megkönnyítik az ilyen inkompatibilis felesztések a scriptek készítését!
--
Ilyesmi, csak az rpmbuild még 'fejlettebb' is, más szóval nem egészen sikerült még működésre bírni... (még a végén visszateszek egy korábbi rpm-et az előző verzióból)
Viszont hasonló módszerrel alkottam egy 'hostname-f' programot, ami linuxon 'hostname -f' -et hívja, AIX-on meg a resolv.conf-ból veszi ki a domaint.
Persze ha root-ként hívom, akkor a 'hostname --fqdn' hatása az, hogy a host neve --fqdn lesz. De jó!
" AIX-on meg a resolv.conf-ból veszi ki a domaint."
Csakhogy ez igy nem korrekt.
A hostname -f linuxon azt csinalja, hogy a hosts fajlban keresi meg a gepen levo ip-khez torteno elso matchelot, es a megfelelo entrynel addig nyalja a gepneveket, amig olyat nem talal, ami ugy kezdodik, mint a gepnev.
C-ben ez egyszerubb, ha elo tudod szedni a gepen levo osszes IP-t, akkor gethostbyaddr() -ral lekered, es vegigszaladsz a h_alias tombon (asszem ez a neve) egy strncmp-vel.
--
A linux-os hostname nem fordul AIX-en, mivel a linux-specifikus ifaddr.h -t használja...
gondolom, az kb hasonlókat tud, mint a net/if, csak legalább nem hordozható...
Egyébként régen a hostname a coreutils része volt, csakis emiatt fordítottam a legújabb coreutils-t (gmp-vel együtt, amihez a libtool-t is haxolnom kellett), azután örömmel láttam, hogy a 'hostname' maradt a régi.
Pont ezert irtam le a mukodeset. Ha nagyon nekiduralnam magamat (nem fogom) akkor meg en is meg tudnam irni. Nem egy bonyolult lekuletu cucc.
--
Most hallom, hogy valaki xlc-vel fordít/szerkeszt... ez persze az ő szomorú magánügye, de most összehasonlításképp jó lenne tudnom, hogy mi ott a -Wl,-bmap:mapfile megfelelője. (Vagyis átadni a linkernek némi opciókat.)
Szerk: ájulat! A doksi szerint ugyanúgy!
aix-libtool-ban 5648 sor körül járunk, és lassan megérik a béta-tesztre.
Csak a napló kedvéért: most untam meg, hogy nincs 'diff -u', most következik a GNU diffutils telepítésbe. (Persze forrásból, naná)
Ami megint 'trailing_slashes' hibákat talált, az open-ben meg a symlink-ben. Vajon ki az, akinek olyanokon jár az agya, hogy 'ej ejj, micsoda dolog az, hogy pl a 'cat /etc/passwd/' kiírja a fájl tartalmát, ahelyett, hogy hibát dobna -- de majd én kijavítom'
Az apache-2.4.3 alkalmából ismét egy kis javítás/szépítés: igenis vannak olyan helyzetek, amikor nincs 'lib' a shared object előtt, pl a mod_cache_disk.so használja a mod_cache.so-t.
---
Persze a régi PHP nem megy az új Apache-csal...
Syntax error on line 235 of /usr/local/etc/apache2/httpd.conf:
Cannot load libexec/apache2/libphp5.so into server:
0509-130 Symbol resolution failed for /usr/local/libexec/apache2/libphp5.so because:
0509-136 Symbol ap_log_error (number 1057) is not exported from dependent module httpd.
0509-136 Symbol ap_log_rerror (number 1058) is not exported from ependent module httpd.
0509-136 Symbol ap_get_server_version (number 1068) is not exported from dependent module httpd.
0509-136 Symbol unixd_config (number 1076) is not exported from dependent module httpd.
0509-192 Examine .loader section symbols with the 'dump -Tv' command.
---
Hasonló nevű szimbólumok persze vannak, pl:
ap_log_error_
ap_log_rerror_
ap_get_server_revision
ap_unixd_config
Gondolom, ennyi változás belefér a verzióváltás szabadságába... vagy mibe...
---
Most éppen a php-5.3.13 újrafordítása sem megy a "meta_ccld" hiánya miatt. (Én még a létezéséről sem tudtam, most meg a hiányával kell szembesülnöm...)
---
Ami egyébként van -- vajon melyik komponens nem találja, és miért nem találja?!
---
Én nem találom. Mármint az én libtoolom. A program nevét vizsgálom, hiszen az opciók értelmezése attól függ.
---
Nyomozásom szerint ez azt jelentheti, hogy valahogy(?) érvényre jutott a --enable-maintainer-zts opció a ./configure során... Az ilyesmi megesik...
---
Nem segített a --disable-maintainer-zts sem. Akkor az UFÓK lehetnek a hibásak.
---
Vagy a szerver verziószáma (aszerint ágazik el a ./configure egy ponton):
$ httpd -v
Server version: Apache/2.4.3 (Unix)
Mai utolsó üzenet:
Syntax error on line 271 of /usr/local/etc/apache2/httpd.conf:
Invalid command 'User', perhaps misspelled or defined by a module not included in the server configuration
Az van ott, hogy "User www-data"... ezzel vajon mi a gond?
kommentezd ki, es nyomj egy httpd -M -et (vagy mi az apache binarisod neve). Valami modulka hianyzik.
--
Ma kipróbálom, köszi. (Valószínűleg sok ilyen modulka fog még hiányozni -- majd lesek valahonnan; végül is 2.2.21 és 2.4.3 között azért mégiscsak történhetett némi változás.)
No, van új
pipacsApache, multithread és multiprocess közül lehet választani, egyelőre multithread-dal megyünk (mpm_worker), de ha valami gyanús jelet látok, visszamegyünk a régi üzemmódba (mpm_prefork).Erre a nagy örömre most a PHP-5.4.6 intett be: https://bugs.php.net/bug.php?id=63017
holnaptól innen folyt köv
(PS: dtelnet-1.2.7 érdekel valakit? Nem? Gondoltam.)
Tevedsz, nekem tetszik.
--
Akkor jó;) Persze alig hogy kész van, már jött is egy júzer, aki Shift+F11-et szeretne használni, kf21 értelemben... naná, hogy eddig csak kf1-kf20 volt a programban...
Az új PHP első eredménye: htmlspecialchars harmadik paraméterének változott az alapértelmezése. Bővebben itt:
Ékezetes FAQ
Ja és egyes configurék ilyeneket írnak ki:
checking for working fcntl.h... no (bad O_NOATIME, O_NOFOLLOW)
Ki kellene vizsálni ezt is...
Még azt mondja meg valaki, hogy a libstdc++ -szal csak akartam valamit kezdeni, vagy csak erősen rágondoltam, és nem csináltam vele semmit -- legalábbis most, úgy látom, nem megy.
(wasntme)
--
Na szóval aljas módon a libstdc++.so-t is kirángattam békés fészkéből (értsd: tartalmazó .a fájljából), és besymlinkeltem a /usr/local/lib-be. A .la fájlt kicsit meg kellett haxolnom, de most valamennyire megy:
És még mindig hátra lenne az a feature, hogy .la fájl nélkül is menjen a verziókezelés (házi feladat magamnak), vagyis ha megtalálja a libstdc++.so -t, és látja rajta, hogy az symlink, akkor a target alapján (libstdc++.so.6.0.16) megpróbálja meghatározni a major verziószámot, magyarul: keres egy libstdc++.so.6 vagy libstdc++.so.6.0 nevű linket, aki ugyanarra a targetre mutat (az előbbit fogja megtalálni), és azt használja a linkeléshez).
Azt olvasom, hogy 7.x-ben már van dirfd. Ez egy másik megfogalmazása annak, hogy 5.x-ben és 6.x-ben nincs.
Azt mondják ugyanis, hogy a readdir_r előtt egy name_max = fpathconf (dirfd (dir), _PC_NAME_MAX) az igazán kúlos, kevésbé menő a name_max = pathconf (dir, _PC_NAME_MAX) -- ugyanis a dir az változhat is (vö: multitaszk, symlink, stb), akár meg is lehet haxorizálni a programot ilyen módon.
Most már ott tartok, hogy linux-ra is meg akarom csinálni a libtool-t... borzasztó, hogy önnön-magamnak generálom a feladatot;)
Most éppen a -Wl,-rpath,uninstalled-la-dir/.libs-et tettem bele, eddig jó is, de egyben észrevettem, hogy a -R opció még nem megy
Következő kötözködés (m4 fordítása):
checking whether rename honors trailing slash on destination... nochecking whether rename honors trailing slash on source... no
Szerintem ez valakinek a fixa ideája, hogy poénból felesleges perjeleket tesz a nevek végére, és ellenőrzi, hogy kap-e hibaüzenetet a különféle rendszerhívásoktól...
Megoldva. Ugyanő:
checking whether rename manages hard links correctly... no
checking whether rename manages existing destinations correctly... no
Az egyik arra céloz (talán), hogy ez nem teljesül:
"If oldpath and newpath are existing hard links referring to the same file, then rename() does nothing, and returns a success status."
Szerk: Na jó, ez én voltam: a 'local_rename' a 'local_symlink'-ből keletkezett (igen, copy+paste fejlesztés), és egy ponton bizony 'symlink' maradt benne 'rename' helyett. Ciki.
A mappa/fajl megkulonboztetes miatt szokas perjelet tenni a fajl vegere - bar amennyire tudom, jelenleg nincs olyan FS, ami ugyanolyan nevu fajlt es mappat is engedne egyazon mappan belul.
--
+1
Hát, pl a "ls -l etc" és "ls -l etc/" működhet különbözőképpen, ha mondjuk az "./etc" egy könyvtárra mutató symlink.
Itt viszont arról van szó, hogy az alábbi parancs nem megy linuxon (ENOTDIR), de működik AIX-en (és ez valakinek az érzékenységét sérti):
cat /etc/motd/pedig ez valoban eleg barbar dolog :))
--
NetBSD - Simplicity is prerequisite for reliability
Most talán jó, ugyanő (m4):
checking whether link handles trailing slash correctly... noMost értesültem róla, hogy a gcc-nek van egy -v opciója, ami nagyon hasznos lehet, hogy megtudjuk, mi is történik a háttérben. Pl:
(legyen $GPATH=/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.6.2 mert rengetegszer ismétlődik)
collect2 -bpT:0x10000000 -bpD:0x20000000 -btextro -bnodelcsect -bexport:/usr/lib/libg.exp -o executable /lib/crt0.o -L$GPATH -L$GPATH/../../.. -brtl -bnortllib -bernotok -bipath -bmap:executable.map ... /usr/lib/librt.a /usr/lib/libc.a $GPATH/libgcc.a $GPATH/libgcc_eh.a -lg -lc $GPATH/libgcc.a $GPATH/libgcc_eh.a
(dőltbetűvel van, amit én adok meg, a többit ő teszi hozzá)
Nem tudtad? :o Ez pedig annyira alap, hogy meg en is tudom :-)
--
Senki sem érezte feladatának, hogy engem tájékoztasson erről az opcióról;)
(A legutóbbi ilyen felfedezésem a -mtune=native volt: hátha a gcc is ki tudja találni, hogy pontosan milyen az aktuális CPU, és nem nekem kell belevasalnom a Makefile-okba egy platformfüggő információt)
Akkor meg par kis hasznos:
--
1
(Jé, a clang a -dumpmachine-t ismeri, de a -dumpspecs nem mond neki semmit. Mint ahogy nekem se, megint tanultam valamit.)
A clang-ba nincsenek specek, miert is mondana neki barmit. Gcc-nel viszont szepen lehet debugolni, hogy mit hol keres.
--
Csak arra gondolta, hogy
- mondhatna mondjuk fordítási (mármint amikor a clang-ot fordították) beállításokat
- ha már igyekszik minden gcc opciót ésszel értelmezni, erre is szebb lenne annyi, hogy "Sorry, ez értelmetlen a clang-ban", mint az, hogy "unsupported option"
Csak az utolsora reagalok: ez a ket kifejezes a clang eseteben szinonima :-)
--
Na meg egy pici:
Hazi feladat, hogy mit csinal. CLang is ismeri.
--
Ilyen már volt egyszer, de most nem találom...
Pro*C üzeni:
Error at line 148, column 2 in file /usr/include/standards.h#warning The -qdfp option is required to process DFP code in headers.
Ja igen, ez lett a megoldás a standards.h- ban:
/* itt valami nagyon izgalmas dolog történik, aminek
kb annyi a lényege, hogy összezavarja a Pro*C-t
#if (defined(__IBMC__) || defined(__IBMCPP__))
#if ((defined(__STDC_WANT_DEC_FP__)) && !(defined(__IBM_DFP__)))
#if defined(__IBM_PP_WARNING)
#warning The -qdfp option is required to process DFP code in headers.
#else
#error The -qdfp option is required to process DFP code in headers.
#endif
#endif
#endif
*/
Es akkor most mi lesz a headerekben levo DFP code-dal?
--
Nincs erőm kinyomozni, hogy mi a menő manó az a DFP kód :(
Szegenyke. :-) Inkabb csak ironia/humor/stb akart lenni...
--
gdb-7.5 ezzel örvendeztet meg:
cc1: warnings being treated as errorsbfd.c: In function '_bfd_abort':
bfd.c:1047: error: 'noreturn' function does return
"Némely emberi agy egészen másképp működik, mint ahogy azt elvárnánk" (Váncsa István)
Minek tették a CFLAGS-ba a -Werror-t, ha nem gondolták komolyan?!
Na jó, hát lehet, hogy nem kizárólag a gdb-team a hibás, inkább csak annyi, hogy fel sem merült bennük, hogy esetleg nem csak linux+gcc a világ... szóval ha /usr/local/include/unistd.h -ba beteszünk egy ilyet:
void _exit(int) __attribute__ ((noreturn));akkor remélhetőleg jó lesz
Mondjuk ez is megérne egy kivizsgálást:
checking whether memmem is declared... yeschecking for memmem... yes
checking whether memmem works... no
Ha üres stringet keresünk, az jön vissza, hogy 'nincs benne'. A matematikusi beállítottságú programozó inkább azt mondaná, hogy: de igen, pont ott van a legelején...
Vagy a vegen. Vagy valahol a tizenotodik es tizenhatodik karakter kozt feluton. Nem veletlenul mondja.
--
De a leírás azt mondja, hogy az első előfordulást kell megtalálni. Tehát nem valamelyiket, nem mindet, nem az utolsót, hanem az elsőt.
Nem erted, az a lenyeg, hogy konkret karakterpoziciot kell megjelolni. Ha a nulladik poziciot jeloli meg - az nem az, ha az elsot - az sem. Az ures sztring az pontosan minden feledik pozicioban van jelen - viszont nem adhat vissza tortszamot.
Nem adhat vissza ervenyes poziciot, mert ilyen nincsen, ha visszaad, nem ellenorizheto vissza.
--
Segédkérdés: mennyi memcmp ((void *)100, (void *)200, 0)
Keteselyes. A franc tudja, mi van ezeken a memcimeken.
--
A harmadik paramétert is vedd figyelembe.
Es tenyleg.
--
Elmentem kicsinyég, remélve, hogy a gdb addig lefordul. Le is fordult. Majdnem jól:
$ dump -H $(which gdb) | grep src
3 /usr/local/src/gdb-7.5/bfd/.libs libbfd-2.22.52.20120718.so
8 /usr/local/src/gdb-7.5/opcodes/.libs libopcodes-2.22.52.20120718.so
Na pontosan ennek nem lenne szabad lennie benne, mert a gdb-nek akkor is mennie kellene, ha a forrást törlöm a /usr/local/src-ből.
PS: Megnéztem egy másik gépen a gdb-7.3.1-et, a hiba ott is fennáll. (Ismét igazolódott a régi mondás, hogy hiba csak ott van, ahová nézünk. Vagy fordítva: ahova nézünk, ott találunk egy hibát.)
Akkor most mars innen, a HUP-on nem szeretnek hibat :D
--
Nagyobb kompatibilitás miatt a *.la fájlokban ezentúl két dependency_libs lesz, az egyik a hagyományos libtool-nak, a másik önmagunknak, a különbség a la-nélküli libek tárolásában van:
Na nem mintha kezdeném megkedvelni a hagyományos libtool-t... nemcsak hogy a major-verziókat nem tárolja (az egész projekt ezzel kezdődött ugyebár), de a relatív path-nevek használata is elég furcsán tud kinézni, pl:
libboci.. ez kesz... :D :D :D
--
Az egy barátságos interface az OCI-hoz... (nem azért, mert én csináltam, de egész jó)
Az mondjuk Friendly OCI lenne, de a libfoci is allat :-)
Nem elcelodni akartam rajtad, tenyleg humorosnak talalmo a nevvalasztast. De ez nem baj, sot!
--
Azsongya nekem a pkg-config, hogy:
/usr/include/pthread.h:666:19: error: unknown type name 'pthread_spinlock_t'
Ez vajon volt már, vagy új?
Megpróbálom orvosolni a /opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.6.2/include-fixed/sys/types.h fájl törlésével jó hályogkovács módra.
Mi történhet? Legfeljebb minden borul. Az meg így is úgy előfordulhat.
En ezeket a fajlokat nem torolni szoktam, csak be gzippelni. Az pont annyira elrejti az app elol, hogy mar ne lassa, megis helyben maraud, es barmikor visszacsomagolhato, ha kell.
--
Persze, igazából csak átnevezem én is...
És már itt is a következő: openssl-1.0.1c
md4_dgst.c: In function 'md4_block_data_order':
md4_dgst.c:111:2: warning: implicit declaration of function 'asm' [-Wimplicit-function-declaration]
md4_dgst.c:111:2: error: expected ')' before ':' token
Mert megadtam a gcc-nek a -std=c99 opciót... mármint még régebben, globálisan.
Akkor itt most -std=gnu99 lesz
gengetopt:
g++: internal compiler error: Segmentation fault (program as)
Lehet, hogy ebből egy 'gas' lesz hamarosan?
Inkább egy másik gépről áthoztam egy régebbi as-t.
This is gas. :-)
--
findutils:
ld: 0711-317 ERROR: Undefined symbol: .alloca
ugyanis az 'alloca' nem externként kellene működjön, hanem 'valahogy speciálisan'
Ez a problémát is a -std=c99 opció okozza valamiképpen...
vagy ha effektíve include-oljuk az alloca.h-t (amolyan kultúrember módjára), akkor sincs baj.
/me <3 alloca
--
/me <\3 alloca
De ma nem tudom miert, sok-sok eve egy messzi galaxisban volt vele valami szopasom, azota valamiert nem.
Pedig az alloca jo. Bar nem igazan cross-platform, de ez engem a legkevesbe szokott izgatni.
--
Kérdés magamhoz: linux-ban bele lehet (bele érdemes) tenni egy shared libbe az ő függőségeinek a helyét? Tessék szépen kinyomozni!
Executable esetén ez már megy:
$ readelf -d smsserv
Dynamic section at offset 0x2ef8 contains 26 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libdevel_core.so.0]
0x00000001 (NEEDED) Shared library: [libdevel_rt.so.0]
0x00000001 (NEEDED) Shared library: [libsms.so.0]
0x00000001 (NEEDED) Shared library: [librt.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000f (RPATH) Library rpath: [/home/projects/sms/src/.libs:/home/projects/lib]
A jáváról van szó, hogy pontosítsam: ugyebár JNI esetén behúz egy libValamiJni.so-t. De persze az a libValamiJni.so csak egy közvetítő, az igazi monkát a libvalami.so végzi. Mármint, ha a dlopen megtalálja a libvalami.so-t. Van ugyan egy -Djava.library.path=
opció, de az csak a libValamiJni.so betöltésében segít, a további betöltésben nem.
Es a libvalami.so miert nincs LD pathen?
--
+1
Valamiért jobban tetszik nekem a gondolat, hogy legyen benne a path magában az elemben... ezt a 'rendes' libtool is megteszi.
Közben született még egy szépítési igény: kis programocskám a --mode=install során megismétli a linkelést, ami persze még nem bűn, csak éppen nem törli maga után az átmeneti fájlt. Még ez sem lett volna baj, ha nem kellene néha root-ként installálni (/usr/local/bin-be), néha meg mezei userként (/home/projects/sms/bin) -- az előbbi lehetetlenné teszi az utóbbit. (Persze az is igaz, hogy ebben a konkrét esetben ez elhárítható, de temporális fájlt hagyni magunk után mindenképp hiba.)
Ez a hibajelenség:
ld: 0711-931 SEVERE ERROR: Output file: .libs/smssendIThe file is write-protected.
collect2: ld returned 12 exit status
Ez is megvan... lassan, de biztosan közeledünk a béta-tesztelhető állapothoz... Mondjuk gyenge pontja a dolognak, hogy rajtam kívül senki se kíváncsi rá -- persze meg is értem: ki akarna egy teszteletlen termékkel kísérletezni a céges gépen. (Mármint engem kivéve: az egóm mérete és a kísérletezőkedvem messze túllépi a mezei programozótól elvárhatót.)
Nekem, mint uzemeltetonek viszont a hatam borsozik az ilyen megoldasoktol. Linuxon amugy a legtobb "nagy" gyarto siman LD_LIBRARY_PATH-tel adja meg, hogy mi hol van, es csa. Ez legalabb tud dinamikus is lenni.
--
Számos lehetőség van, pl:
1. oda telepítesz, ahová akarsz, de az install a bináris programokat újralinkeli a választott path-nak megfelelően. Pl: Oracle AIX-on
$ dump -H -X64 /orabin/OraHome_4/bin/sqlplusINDEX PATH BASE MEMBER
0 /orabin/OraHome_4/sqlplus/lib/:/orabin/OraHome_4/lib/:/usr/lib:/lib
2. Ora telepítesz, ahová akarsz, a bináris program helyett script-eket futtatsz, a script készíti elő a környezeti változókat. Pl: firefox linuxon
3. Előre definiált helyre telepítesz, a bináris program és a lib is fix helyre kerül. Pl: rpm/deb csomagból telepítés.
4. Magad fordítasz, libtool-lal. A libtool beállítja a rpath/libipath mezőket a binárisban.