MySql AIX-on: ki az a collect2?

Az előző adás folytatása: a g++ nem a 'ld' (sem a 'gld') nevű programot hívja, hanem az /opt/freeware/libexec/gcc/*/*/collect2-t. (Mondjuk a név nem ismeretlen, hiszen linuxon tényleg ő szokta kiírni a linkelési hibákat.)

Talán az lenne a legjobb, ha ennek a collect2-nek lenne valamilyen kimenete, amiben meggyónná, hogy mit és miért csinál. No, majd keresgélek.

Erre már válaszoltam egy másik bejegyzésben: azért mert itt van számtalan AIX, meg itt van a feladat, hogy kell mysql.

Egyébként sokak mellett pl én is fordítottam AIX-en Apache-t és PHP-t (meg samba-t, gdb-t, bash-t, mc-t, openssl-t), szóval ez is menni fog, csak azt kell látni, hogy itt külön akadályozó játékos van, nevezetesen a Cmegmeg.

Ha én kapnám a feladatot, akkor felállítanék egy dedikált külön mysql szervert a rendszerre, normálisabb, supportolt OS-re. Kisebb szívás és kevesebb költség. Valamit csak jelent, hogy a hivatalos dokumentációkban is megszakad a howto az 5.1-es verziónál...
--
Coding for fun. ;)

Nyilván, ha az üzemeltetés ingyen van, egy új hw beszerzése valóban megszervezhető... ha nincs ingyen az üzemeltetés, akkor azért talán megkérdezné a pénzügyi felelős, hogy a már meglévő számtalan számítógép (amiknek már meg van oldva az üzemeltetése) miért nem jó? (Különösen, hogy pl az Oracle elműködget rajtuk valahogy.) Most mondjam azt, hogy azért, mert a programozónk lusta és/vagy buta ahhoz, hogy kiderítse, mi a gond?

A nagy különbség az, hogy az Oracle supportált AIX-on, míg a MySQL nem. Tehát a rendszergazdának/üzemeltetőnek csípőből vissza kellene dobnia a projektet, hogy nem szupportált dolgokkal nem küzdenek. Ha a gyári szupport nem érdekes, akkor meg jobban jártok egy ingyenes ppc64-es linuxszal (pl. Debian ppc64, Centos sajna nincs, viszont van Fedora), ami csomagként tartalmazza a mysql-t OOB.

Magyar sajátosság (?), hogy a pénzügyi felelősök általában szakmai inkompetensek? Egy hozzáértőnek el lehet magyarázni, hogy nem támogatott a rendszer, így ha sikerül is a fordítás és az elindítás, bármikor érhetnek kellemetlen meglepetések. Egy így összekínlódott adatbázismotorra még tesztadatokat se bíznék, nemhogy éleseket.

--
Coding for fun. ;)

( NevemTeve | 2014. 09. 18., cs – 12:10 )

Na ebből kellene kiokosodnom: 


========== output_file = test-pfs-t, c_file = /tmp//ccCftwck.c

write_c_file - output name is test-pfs-t, prefix is test_pfs_t
static int count;
typedef void entry_pt();
extern entry_pt x14 __asm__ ("_GLOBAL__I_65535_0_pfs_hton");
extern entry_pt x15 __asm__ ("_GLOBAL__I_65535_0__ZN22PFS_engine_table_share16check_all_tablesEP3THD");
void _GLOBAL__FI_test_pfs_t() {
        static entry_pt *ctors[] = {
                x14,
                x15,
        };
        entry_pt **p;
        if (count++ != 0) return;
        p = ctors + 2;
        while (p > ctors) (*--p)();
}
extern entry_pt x16 __asm__ ("_GLOBAL__D_65535_1__ZN22PFS_engine_table_share16check_all_tablesEP3THD");
void _GLOBAL__FD_test_pfs_t() {
        static entry_pt *dtors[] = {
                x16,
        };
        entry_pt **p;
        if (--count != 0) return;
        p = dtors;
        while (p < dtors + 1) (*p++)();
}
========== end of c_file

Ez a fájlt a collect2 hozta létre, ezt mondja rá a 'nm': 


D _GLOBAL__FD_test_pfs_t
D _GLOBAL__FI_test_pfs_t
T ._GLOBAL__FD_test_pfs_t
T ._GLOBAL__FI_test_pfs_t
U global constructors keyed to 65535_0__ZN22PFS_engine_table_share16check_all_tablesEP3THD
U global constructors keyed to 65535_0_pfs_hton
U global destructors keyed to 65535_1__ZN22PFS_engine_table_share16check_all_tablesEP3THD

Nem mondhatnám, hogy minden bitet értek rajta, de ne adjuk fel a csüggedést...

Ez az egyik fele a mesének, a másik meg az az opció, amit a második linkeléskor ad át a collect2 a ld-nek: 

-binitfini:_GLOBAL__FI_test_pfs_t:_GLOBAL__FD_test_pfs_t

Elég dühítő, hogy nincs AIX a közelemben, most már kezd érdekelni a téma. Nem lehet esetleg az 5.1-es hivatalos útmutató alapján frissebbre reszelni a fordítást? Továbbá: tényleg kellenek az 5.1 utáni feature-k, vagy csak a frissebb-jobb sémát követed?
--
Coding for fun. ;)

Hát egy biztos: visszafelé nem megyek az időben... (mármint a mostanitól is jobban visszafelé... Külön keresnem kellett olyan letöltést, ahol nem kell az Oracle-nak meggyónnom a cipőméretem, a fizetésemet, és az összes minősített személyes adatomat... (illetve a cégemét) A packages.debian.org segített végül, bevallom.)

Különben meg alig hiszem, hogy a g++, a collect2 meg az AIX igazságos harca a MySql verziójától függene...

+1. Én szeretem az AIX-et, de lehet, hogy ebben a felállásban elgondolkodnék a PC/Linux párosításon. Ha viszont az infrastruktúra kötött, akkor meg a lovon fordítva ülés helyett megnézni, hogy mi a támogatott, és arra "lőni", úgy DB, mint alkalmazás oldalról.

Az is jó kérdés, hogy a "kell mysql" miként merült föl, mi az az üzleti igény, ami kifejezetten mysql-t igényel, és nem lehet más RDBMS-t alátolni - olyat, ami támogatott AIX alatt.

Vagy épp a sajtreszelővel történő egyszemélyes szexuális örömszerzéshez, ha nem tudja valaki a határokat elfogadni. És ahogy előttem írták: céges környezetben, munkaidőben lehet, hogy az ilyen sajtreszelős brémaszírozás nem biztos, hogy kifizetődő dolog. Sőt.

Apró kérdésként felmerül az is, hogy mi van, ha a nagy nehezen összereszelt mysql valami miatt elhasal? Ki lesz a felelőse, ki fogja a hibát megkeresni és kijavítani? Ha kijön valamilyen biztonsági vagy funkcionális javítás az általad leforgatott verzióhoz, akkor az új build elkészítést, tesztelését ki és mennyi idő alatt fogja megcsinálni?