MySql AIX-on: ki az a collect2?

 ( NevemTeve | 2014. szeptember 18., csütörtök - 6:20 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Na jó, ezt már rossz nézni. Az utolsó hivatalos instrukció AIX buildre 5.1-es MySQL-re vonatkozik.

http://dev.mysql.com/doc/refman/5.1/en/aix-installation-source.html

Próbálkozz e szerint.

--
Coding for fun. ;)

próbálkoztam, rövid lett:

$ xlc_r
-bash: xlc_r: command not found

Nem azt mondtam, hogy nem tudom, mi az; hanem azt, hogy nincs a gépemen. (Egyébként viszont nagyon hasznos lehetne a doksi, amit linkeltél, ha pl. lenne még configure, dehát már nincs.)

Csak óvatosan kérdezem: mi a fenére kell neked AIX-ra mysql, főleg házilag forgatva? Apropo, van, akinek sikerült valamit összehozni:

http://www.scheerer.co.uk/2013/05/installing-apache-php-and-mysql-on-ibm-aix-7-1/

--
Coding for fun. ;)

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. ;)

Nagy +1

+1, ez mar nagyon durva idopocsekolas, halott rendszerre (98-as AIX 0.1?) heggeszteni dolgokat...

(Lefordítalak magyarra, oké?)

K: Teve olvtárs, milyen AIX verzió ez?
V: 6.1 (oslevel -r: 6100-09)

2007 november vs 2014 szeptember

Tök jó, mindjárt jelentem is a menedzsmentnek, hogy megmondta egy szaktekintély az interneten, hogy most rögtön lekapcsolhatjuk az országot, mert elavult az AIX-unk.

nem hiszem el, hogy jobban megeri napokon at azzal szivni, hogy egy regi rendszerre mysqlt forditasz, mint bemenni egy boltba es venni egy intel szervert.

ha meg igen, akkor valami baj van ott :)

Pontosan. Ha kiszámolnák, hogy mennyi egy Poweres gép CAPEX/OPEX árai, akkor könnyen kijöhet az, hogy csak mission critical LPARok menjenek azon, egyéb VMekre ott az x86 tetszőleges virtualizációval.

Ha már mindenképpen LPAR, akkor lehet hogy RHEL/SLES-sel is jobban járna...

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

7 ev szerintem mar igy is vissza az idobe, szoval siman telepithetnel mysql 3.0-at is

Vedd úgy, hogy megtettem. Köszönöm a beszélgetést;)

Ha a tudáshiány szorgalommal párosul... :)

Akkor eljutunk néhány misztikus, sokak által hírből sem ismert metódushoz, amiket tanulásnak, kísérletezésnek, tapasztalásnak nevezünk...

otthon, onszorgalombol azt csinal mindenki, amit szeretne. munkahelyen, munkaidoben teljes ido- es penzpazarlasnak nevezzuk, foleg ilyen x86 szerver arak mellett.

+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?

Igen, ezen még nem gondolkoztam, hogy egy ingyenes terméknél ki és milyen supportot fog nyújtani...

azt remelem vagod, hogy supported platformon futtatott mysqlhez lehet supportot venni akar direct oracletol, akar a perconatol.

AIX thread a hupon!!! oh wait...

PS. http://www.perzl.org/aix/index.php?n=Main.Mysql

:)