[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) :muro:
E' singolare che, se a ld fornisco in pasto i singoli oggetti .o che compongono l'archivio .a, funziona tutto alla perfezione :muro: :muro: :bsod:
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? :grrr:

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

[ilsensine]

E' singolare che, se a ld fornisco in pasto i singoli oggetti .o che compongono l'archivio .a, funziona tutto alla perfezione :muro: :muro:
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 :D

[ri]

stavo per dirtelo! giuro!! :asd:

[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 :O

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

e invece.... il vuoto :cry:

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!! :cry:

[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]

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

Ma quelle non stanno in libgcc_s??

[ilsensine]

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]

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]

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? :D

[mjordan]

...tradotto? :D

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.