2012-09-13 9 views
5

In un progetto, il mio collega crea una libreria statica, ad esempio liba.a, che si collega all'app.Come posso collegare libc.a a una libreria condivisa in arm-linux uso arm-none-linux-gnueabi-gcc

In liba.a sovrascrive la libc malloc() nella versione del proprietario.

Creo una libreria condivisa libs.so che è anche collegata all'app.

Il problema è quando il mio libs.so collegato con app, la malloc() utilizzato nel mio libs.so sarà quello di liba.a, non quello in libc.so di serie, questo causa problemi.

Quindi, voglio collegamento statico libc.a al mio libs.so, ho usato flag -static -shared -fPIC per gcc.

Ma ottengo sempre arm-2012.03/bin /../ lib/gcc/arm-none-linux-gnueabi/4.6.3 /../../../../ arm-none-linux -gnueabi/bin/ld: arm-2012.03/bin /../ arm-none-linux-gnueabi/libc/usr/lib/libc.a (dl-tsd.o) (. testo + 0x14): R_ARM_TLS_LE32 non rilocazione permesso nell'oggetto condiviso.

Qualcuno ne ha idea?

Grazie in avanti.

+0

Penso che -static -share non debba essere mischiato .... – Jeyaram

+0

Il testo seguente è stato copiato da ld.pdf da codesurgery: "-static Non si collega alle librerie condivise Questo è significativo solo sulle piattaforme per le quali è condiviso le librerie sono supportate ** L'opzione può essere utilizzata con '-shared' **. Ciò significa che una libreria condivisa è in fase di creazione ma che tutti i riferimenti esterni della libreria devono essere risolti inserendo voci da librerie statiche ". –

+0

@DavidChyi: Questo dice solo che -static e -shared possono essere mescolati, ma non che sia una buona idea. I compilatori in generale hanno molte opzioni che non sono una buona idea da usare per le normali applicazioni. Sono importanti per casi speciali come la compilazione di kernel, bootloader, codice microcontrollore e così via. –

risposta

2

Non è possibile, perché il codice che va nella libreria condivisa deve essere compilato con -fPIC e il codice nelle librerie statiche no. Se sei riuscito a farlo, l'eseguibile risultante finirebbe per essere collegato con libc più volte, il che sarebbe comunque molto fragile e probabilmente si bloccherebbe prima o poi, quindi non dovresti farlo comunque. Pertanto:

Non. Le librerie dinamiche devono collegarsi dinamicamente alle librerie di sistema e qualsiasi eseguibile che si collega alle librerie dinamiche deve anche collegare le librerie di sistema in modo dinamico.

Vorrei anche ricordare che il collegamento di GNU libc con un'applicazione non GPL in modo statico è illegale, poiché LGPL esclude solo il codice collegato dinamicamente. Questo è fatto apposta per consentire il bugfixing della libreria senza ricompilare l'eseguibile per quale fonte potrebbe non essere disponibile. È piuttosto comune in Linux aggiornare le librerie condivise con la versione bugfix senza ricompilare gli eseguibili dipendenti; gli sviluppatori di libc sanno come farlo.

+0

@ Hudec: Grazie per il tuo gentile ricordo. Il mio collega ha già cambiato la sua libreria per usare standard malloc() in libc.so. Ma solo per curiosità, perché il seguente esempio ha funzionato su PC gcc, ma non è riuscito in ARM gcc: $ cat libtest.c '#include void foo() {printf ("% d \ n ", 42); } ' $ cat main.c '#include extern void foo(); int main() {puts ("La risposta è:"); foo(); } ' ' gcc -shared -fPIC libtest.c -o libtest.so -static-libgcc -Wl, -Bstatic -lc && gcc -c main.c -o main.o && gcc main.o -o test. /libtest.so && LD_PRELOAD =./libtest.so./test' ====> 42, funzionante. –

+0

@Hudec: dove posso trovare queste informazioni? _Don't. Le librerie dinamiche devono collegarsi dinamicamente alle librerie di sistema e qualsiasi eseguibile che si collega alle librerie dinamiche deve anche collegare dinamicamente le librerie di sistema. E a cosa serve libc.a? –

+0

@DavidChyi: Dipende da ciò che contiene in realtà la libc.a su quel particolare sistema in cui si sta provando. Potrebbe funzionare su una particolare installazione e non su un'altra. Molte installazioni non hanno nemmeno una versione di libc statica installata. –

Problemi correlati