Dotaz: rozdilne prelozene programy na jinak shodnych systemech

[Pavel Kozisek]

provadim backup mezi servry a soucasti zalohy jsou i adresare, ve kterych se nachazeji aplikace na servru provozovana vcetne vsech zdrojaku , make apod. Oba systemy jsou Centos 5.11 nainstalovane standardne pres repositare. YUM vypise na obou systemech stejny stav. Servry pouzivaji jine hardware (maly server - celeron, velky server - i5).

Kdyz prelozim make-em nejakou soucast aplikace (v nejakem adresari) , tak vzniknou desitky souboru '.o' a i nekolik executable a knihoven ('.a'). Na druhem servru udelam to same. Kdyz nyni porovnan vznikle kompilaty, tak je 99% identickych , ale vzdy se nekolik prelozenych souboru lisi. To mne trochu znervoznuje. Rsyncem totiz pretahuji soubory vznikle na i5 na ten celeron a ten maly server by v pripade havarie velkeho servru mel fungovat jako nahrada - a mne by se lepe spalo, kdyby ty soubory byly nachlup stejne

Nevi nekdo, zda je to normalni? Co je pricinou, ze se tech nekolik souboru lisi. (velikost je ale kupodivu stejna - jen obsah je jiny)?

Odpovědi

[Petr Šobáň]

Normální věc.

Optimalizace - jiný HW tak přeložené programy budou jiné.

Musel by jsi to překládat s uplně stejnými volbami bez optimalizací pro CPU atd.....

[xxxs]

ja neporadim, ale asi by si sem mal hodit s akymi modifikatormi kompilujes. a asi aj verziu make.

[Pavel Kozisek]

diky za nazory, taky jsem si nejdrive myslel, ze to bude mit neco spolecneho s hardware, ale pak jsem to zavrhl, protoze by jinak binarni soubory nebyly vpodstate prenositelne - tedy si myslim.

Srovnaval jsem pomoci cmp -b ty binarni soubory a narazil jsem na jednu vec u statickych knihoven:

tam je v hlavicce unix timestamp a to je samozrejme ruzne podle okamziku kompilace. Pomoci ar -D se tomu da zabranit, coz jsem dodneska nevedel - clovek se uci porad.

U dvou objektovych souuboru jsme take nasel proc to je - je tam radka :

fprintf(stdout, "This is program version %s.\n", __DATE__);

ten program je stary 20 let - uprimne receno bych rekl, ze to neni dobra myslenka?

jinak se to preklada nasledovne:

gcc -Wall -Wno-pointer-sign -g -c -o parse_language_file.o parse_language_file.c

to jsem myslel ze je bez optimalizace - kvuli debuggu ??

[Michal Kubeček]

diky za nazory, taky jsem si nejdrive myslel, ze to bude mit neco spolecneho s hardware, ale pak jsem to zavrhl, protoze by jinak binarni soubory nebyly vpodstate prenositelne - tedy si myslim.

U gcc je potřeba rozlišit dva parametry ovlivňující výsledný kód ve smyslu optimalizace pro konkrétní třídu procesorů. První je "-march", který definuje, jaká instrukční sada se použije; tam skutečně může dojít k tomu, že zvolím-li modernější model, využijí se instrukce, které na starších procesorech mohou chybět a kód tam nepoběží. Druhou je "-mtune", která pouze ovlivní to, jak překladač bude optimalizovat využití registrů a řazení instrukcí podle zvoleného modelu procesoru; na jiném může být výsledný kód o něco méně efektivní než kód optimalizovaný přímo pro něj, ale poběží.

U obou jde použít hodnotu "native" a pak se použije instrukční sada resp. optimalizace podle procesoru, na kterém je spuštěn překladač. To je ale také jediný případ, kdy výsledný kód závisí na tom, kde se překládalo. Může to být výhodné, když počítáte s tím, že se program bude spoouštět právě jen na tomto počítači (nebo na jiných se stejným modelem procesoru); v jakémkoli jiném je lepší použít nějaké konkrétní hodnoty.

fprintf(stdout, "This is program version %s.\n", __DATE__);

ten program je stary 20 let - uprimne receno bych rekl, ze to neni dobra myslenka?

Není to dobrá myšlenka, ale bohužel se s tím člověk pořád občas potká.

to jsem myslel ze je bez optimalizace - kvuli debuggu ??

Těžko říct. Absence optimalizace sice tu a tam může při debugování trochu pomoci, ale rozhodně to není důvod ji vypínat předem.

[Zdenda_S]

fprintf(stdout, "This is program version %s.\n", __DATE__)

Co je na tom obecne spatne ? pouzivam neco velice podobneho pri vypsani helpu ci verze jen tam pouzivam misto data odkaz na gitovy commit a datum kompilace jen jako version of GCC VERSION at _DATE a popripade i hostname stroje na kterem to bylo prelozeno ...

[Michal Kubeček]

Kdyby tam bylo datum toho příslušného commitu (a build byl vždy ze stejné větve), tak by to za určitých okolností smysl mít mohlo. Ale označovat datum buildu za verzi, je naprostý nesmysl, protože když si udělám checkout tři roky staré verze a přeložím ji, bude se vydávat za novější než ta, kterou jsem přeložil včera z aktuálních zdrojáků.

Dávat do binárky datum buildu, build host, verzi překladače a kdoví co všechno sice na první pohled vypadá strašně cool, ale za dvacet let, co se s Linuxem potýkám, si nevzpomínám, že by mi tento typ informací byl (v binárce samotné) k něčemu užitečný. V prostředí jako OBS už je to pak vysloveně škodlivý zlozvyk, protože to zbytečně vynucuje nové a nové rebuildy, ke kterým by jinak nebyl žádný důvod. Proto třeba OBS při zjištění, že se něco takového děje, hlásí warning.

[Zdenda_S]

No vetsinou pouzivam ten commit stroj a verzi gcc jsem pridaval jen obcas kdyz sem ladil nejaký experiment který chodil na lunuxu a osx pod stejnou archtekturou a tisknul jsem to v protokolu kterej byl timto programem generován.

[Xerces]

Tohle (časový razítka v binárce) je myslím jeden z problémů, který se řeší v Debianu v rámci reprodukovatelných buildů. https://wiki.debian.org/ReproducibleBuilds Já to sice nesleduju jak to chlapci řeší ale tuším, že se to snaží ze zdrojáků vykosit.