[gcc] ld -shared -whole-archive saga

[ilsensine]

Esiste un semplice modo per convertire un archivio statico (.a) in una libreria dinamica (.so):
ld -shared -whole-archive -o libfoo.so libfoo.a [ altri parametri... ]
PURTROPPO questa forma mi "perde" tutte le inizializzazioni/finalizzazioni (le funzioni dichiarate con gli attributi constructor/destructor)
E' singolare che, se a ld fornisco in pasto i singoli oggetti .o che compongono l'archivio .a, funziona tutto alla perfezione
Per "ovviare" alla singolare "feature", ho trovato che un semplice
gcc(g++) -shared -Wl,-whole-archive -o libfoo.so libfoo.a -Wl,-no-whole-archive [...]
funziona come deve. Visto che gcc invoca ld per il linking, che diavolo andrebbe fatto utilizzando direttamente ld per ottenere lo stesso risultato?

Non che abbia una grossa importanza pratica, solo per curiosità...

[ilsensine]

Originariamente inviato da ilsensine

E' singolare che, se a ld fornisco in pasto i singoli oggetti .o che compongono l'archivio .a, funziona tutto alla perfezione

Umm qui quo qua, neanche questa forma funziona.
Ho visto che ld di suo non mette i simboli __CTOR_LIST__, __CTOR_END__, __do_global_ctors_aux (e i relativi per i destructor); dovrebbero essere loro i colpevoli -- dove cavolo li prende il gcc?

[ilsensine]

Oh bè, certo, era OVVIO, dovevo semplicemente linkare crti.o, crtn.o, crtbeginS.o, crtendS.o

[ri]

stavo per dirtelo! giuro!!

[RaouL_BennetH]

ecco, questi sono i classici post che mi buttano giù di morale perchè mi fanno rendere conto di quanto ignorante sono in un campo che invece amo.

Mi piacerebbe aver dato una risposta tipo:

ma è elementare watson

dato che gcc bli bli bla bla.....

e invece.... il vuoto

e il magone è doppio quando poi si pensa che a ragionare sul problema sono le persone come ilsensine che son sempre a nostra disposizione...mentre noi per lui....

uharg!!

[ri]

il suo punto forte è che ragiona cercando il "perchè" la determinata cosa non funziona, non il "come" farla funzionare
è sicuramente un approccio più lento all'inizio, ma con il tempo accumuli un bagaglio d'esperienza che ti velocizzerà tantissimo nel risolvere i problemi futuri

[mjordan]

Originariamente inviato da ilsensine

Oh bè, certo, era OVVIO, dovevo semplicemente linkare crti.o, crtn.o, crtbeginS.o, crtendS.o

Ma quelle non stanno in libgcc_s??

[ilsensine]

Originariamente inviato da mjordan

Ma quelle non stanno in libgcc_s??

No; gcc_s contiene delle funzioni ausiliarie. Quei .o che ho elencato servono per fare un pò di black magic in fase iniziale e finale. In particolare, crti.o definisce gli entry/exit point _init/_fini. crtbeginS.o "marca" l'inizio delle sezioni elf .ctor e .dtor, mettendo i simboli __CTOR_LIST__ e __DTOR_LIST__; inoltre definisce la funzione __do_global_dtors_aux. Dopo questo file si possono linkare gli oggetti del programma; le funzioni di costruzione/distruzione finiranno nelle sezioni .ctor e .dtor, accodate ai demarcatori di inizio. Quindi l'oggetto crtendS.o chiude le sezioni, inserendo i simboli __CTOR_END__ e __DTOR_END__; in più definisce la funzione __do_global_ctors_aux.
crtn.o "chiude" l'oggetto elf con dei limitatori; non ho ben capito a cosa serva, ma se non lo metto ottengo un segfault alla chiusura.

[mjordan]

Originariamente inviato da ilsensine

No; gcc_s contiene delle funzioni ausiliarie. Quei .o che ho elencato servono per fare un pò di black magic in fase iniziale e finale. In particolare, crti.o definisce gli entry/exit point _init/_fini. crtbeginS.o "marca" l'inizio delle sezioni elf .ctor e .dtor, mettendo i simboli __CTOR_LIST__ e __DTOR_LIST__; inoltre definisce la funzione __do_global_dtors_aux. Dopo questo file si possono linkare gli oggetti del programma; le funzioni di costruzione/distruzione finiranno nelle sezioni .ctor e .dtor, accodate ai demarcatori di inizio. Quindi l'oggetto crtendS.o chiude le sezioni, inserendo i simboli __CTOR_END__ e __DTOR_END__; in più definisce la funzione __do_global_ctors_aux.
crtn.o "chiude" l'oggetto elf con dei limitatori; non ho ben capito a cosa serva, ma se non lo metto ottengo un segfault alla chiusura.

crtn.o a quanto ho capito si occupa di "parametrizzare" la sezione .init e .fini del binario ELF in modo da includere istruzioni di ritorno.

[ilsensine]

Originariamente inviato da mjordan

crtn.o a quanto ho capito si occupa di "parametrizzare" la sezione .init e .fini del binario ELF in modo da includere istruzioni di ritorno.

...tradotto?

[mjordan]

Originariamente inviato da ilsensine

...tradotto?

No ho letto soltanto on the fly un documento SCO sulle sezioni ELF e relative "black magic" effettuate in fase di linking. Molto interessante.
Tempo fa mi cimentai con il formato ELF in un documento abbastanza tecnico, poi lo abbandonai per studiare i maledetti esami universitari e non ho piu' avuto modo di riprenderlo.
Comunque forse queste sono le questioni piu' interessanti della programmazione.

Non ricordavo dell'utilizzo di quei file *.o, ora ho rispolverato un po. Praticamente sono dei "placeholder" per i binari ELF che il linker utilizza per costruire un binario completo.