Dotaz: gcc, preklad bez includovani

[qwerty]

Dobry den,

zajimalo by me jakto ze se prelozi muj program a normalne funguje:

int main(void) { printf("abc"); }

kdyz printf je deklarovane v stdio.h a to tam neincluduju. Uvazoval sem ze gcc nejak automaticky includuje standartni I/O knihovnu ale kdyz se podivam na to co vypadne po praci preprocesoru (gcc -E) tak je tam:

# 1 "x.c" int main() { printf("abc"); }

takze by to snad printf nemelo znat a melo byt to hodit chybu ne ?

Odpovědi

[#Tom]

Proč by mělo? Když si nezapnete varování, chová se překladač podobně, jako by v programu bylo deklarováno tohle:

int printf(int, ...);

A int a char * se převedou bez problémů (většinou), takže to funguje. Zkuste ale toto:

gcc -o program -Wall -Werror -pedantic -ansi program.c

[qwerty]

jeste bych k tomuto mel jednu otazku. Kdyz mam dva prelozene objektove soubory a oba obsahuji stejny symbol (napriklad v obou budu mit definici funkce xyz()) tak linker pri slinkovavani hodi kolizi. Zajimalo by me, proc takovato dvoji definice nekoliduje, pokud jedna definice je v objektovem souboru a druha je ve sdilene knihovne, ktera se linkuje spolecne s nim pri prekladu. Jako napr. kdyz si udelam definici funkce printf(char*) v nejakem souboru, tak i kdyz sdilena knihovna libc se linkuje spolecne s timto souborem, tak kolize nevznikne a volani funkce vola tu mnou definovanou. Projizdel jsem si libc readelfem a printf neni WEAK symbol.

[unchallenger]

Viz např. http://people.redhat.com/drepper/dsohowto.pdf, sekce 1.5.

[qwerty]

Toto ale, pokud se nemylim, hovori o dynamickem linkeru (/lib/ld-linux) jako zavadeci ktery po spusteni nejakeho spustitelneho souboru linkuje sdilene knihovny na kterych je ten spustitelny soubor zavisly. Ale ten muj problem vznika pri normalnim linkovani gcc uz pri vzniku toho spustitelneho souboru.

[unchallenger]

Jaký problém? Jeden globální symbol v programu může mít akorát jednu adresu. Když chceš v každém souboru nezávislé symboly, máš použít static. Případně mezi tím existuje ještě třída viditelnosti STV_HIDDEN (viz ten článek), kterou můžeš vytvořit symboly viditelné např. v rámci celé knihovny, ale ne mimo ni.

[qwerty]

No jako neni to problem ale jen moje zvedavost. Proste me zajima jakto ze nekoliduje symbol z meho objektoveho souboru se stejnym symbolem ze sdileneho objektu. Oba jsou globalne viditelne (ten muj urcite je a ten z libc musi byt taky protoze pokud si napr. funkci printf sam nenadefinuju a pritom pri linkovani nebudu pridavat libc tak mi bude uz gcc pri linkovani rvat unresolved symbol) a pritom nekoliduji.. kdezto dva stejne globalni symboly ve dvou objektovych souborech koliduji (gcc linker zarve chybu). Jako je mi jasny ze mi v logice teto veci neco unika ale nevim co :)

[unchallenger]

Na hledání symbolu v té knihovně vůbec nedojde, protože je definovaný programu, takže viditelnost ničemu nevadí.

Konflikt může být toho druhu, že se snažíš do jedné tabulky symbolů nacpat dvě definice téhož symbolu, a to ti kompilátor nedovolí.

Nebo když budou dvě knihovny definovat symbol různě, mohou se dít zajímjavé věci v důsledku pořadí resolvování, takže části kódu dostanou něco, co nečekají. Podstatné ale je, že se symbol podle nějakého pravidla hledá v jednotlivých DSO, a když se najde, tak už se dál nehledá.

Já nevím, zda má cenu, abych sem postupně opisoval ten článek, raději si ho přečti...