Creazione di una versione "lite" della libreria condivisa su Linux / POSIX in aggiunta alla versione completa

Question

Creazione di una versione "lite" della libreria condivisa su Linux / POSIX in aggiunta alla versione completa

#1 da (-2 voti)

-1

Ho una grande libreria condivisa, una raccolta di funzioni create da numerosi file .a in libeverything.so . Il codice per i file .a è ovviamente compilato con -fPIC . Ho anche libeverything.a che contiene un'istruzione GROUP ( part1.a part2.a part3.a ... partN.a ) che include tutte le librerie statiche .a .

Non voglio contribuire alla proliferazione .so , quindi non ho part1.so , part2.so , part3.so , ..., partN.so come I ho part1.a , part2.a , part3.a , ..., partN.a .

Ora, supponiamo che molte applicazioni richiedano solo part1.a e part2.a . Per supportare le suddette applicazioni, voglio creare una versione "lite" della libreria condivisa, libsomethings.so collegato da libsomethings.a contenente GROUP ( part1.a part2.a ) .

Può una libreria condivisa "lite" contenente un sottoinsieme di una libreria condivisa più grande causare alcuni effetti negativi? Ovviamente, sono consapevole del fatto che lo spazio su disco e l'utilizzo della memoria sono leggermente meno efficienti, ma al giorno d'oggi non è un problema.

Sono principalmente preoccupato per i problemi di collegamento. Dì, ad esempio libfoo.so che richiede libeverything.so e libbar.so che richiedono libsomethings.so . Il collegamento di libfoo.so e libbar.so nella stessa applicazione può causare effetti negativi?

Ad esempio, considera cosa succede se part1.a definisce una variabile globale. Sarà incluso due volte se sia libeverything.so che libsomethings.so sono collegati nella stessa applicazione tramite libfoo.so e libbar.so ?

Questa versione "lite" di una libreria condivisa è una pessima idea dal punto di vista dell'ingegneria del software su ambienti Linux / POSIX?

Una soluzione sarebbe avere libpart1.so , libpart2.so , libpart3.so , ... libpartN.so ma ciò porterebbe esattamente al tipo di proliferazione .so che sto cercando di evitare.

C'è un modo elegante per evitare la proliferazione di .so e anche i cattivi effetti di collegamento?

linux linking static-linking dynamic-linking posix

posta juhist 10.05.2018 - 15:18

fonte

1 risposta

Leggi altre domande sui tag linux linking static-linking dynamic-linking posix

Progettazione di un'applicazione con tasking parallelo sicuro Angular JS vs Modern MVC frameworks

score -2 · Answer 1

Poiché nessuno ha inviato una risposta in 2 ore, ho deciso di indagare da solo.

Ho creato i seguenti file:

user@machine:~/libtest$ cat liba.h
void calla(void);
user@machine:~/libtest$ cat liba.c
#include <stdio.h>
#include "liba.h"

static int avar;

void calla(void)
{
  printf("%p\n", &avar);
}
user@machine:~/libtest$ cat libb.h
void callb(void);
user@machine:~/libtest$ cat libb.c
#include <stdio.h>
#include "libb.h"

static int bvar;

void callb(void)
{
  printf("%p\n", &bvar);
}
user@machine:~/libtest$ cat libfoo.h
void callfoo(void);
user@machine:~/libtest$ cat libfoo.c
#include "libfoo.h"
#include "liba.h"

void callfoo(void)
{
  calla();
}
user@machine:~/libtest$ cat libbar.h
void callbar(void);
user@machine:~/libtest$ cat libbar.c
#include "libbar.h"
#include "liba.h"

void callbar(void)
{
  calla();
}
user@machine:~/libtest$ cat test.c
#include "libfoo.h"
#include "libbar.h"

int main(int argc, char **argv)
{
  callfoo();
  callbar();
}
user@machine:~/libtest$ cat Makefile
.PHONY: all
all: test

liba.so: liba.c
    cc -shared -fPIC -o liba.so liba.c

libb.so: liba.c libb.c
    cc -shared -fPIC -o libb.so liba.c libb.c

libfoo.so: liba.so libfoo.c
    cc -shared -fPIC -o libfoo.so libfoo.c -L. -Wl,-rpath,. -la

libbar.so: libb.so libbar.c
    cc -shared -fPIC -o libbar.so libbar.c -L. -Wl,-rpath,. -lb

test: libbar.so libfoo.so test.c
    cc -o test test.c -L. -Wl,-rpath,. -lfoo -lbar

Ora quando corro:

user@machine:~/libtest$ ./test
0x7fd26264402c
0x7fd26264402c

... quindi sembra che la risposta sia negativa; Ad esempio, non sto creando problemi di collegamento con questo libeverything.so / libsomethings.so split. Ha ancora una sola copia di questa variabile statica, anche se è una volta in liba.so e la seconda volta in libb.so .

Tuttavia, nei commenti è stato sollevato un punto valido: in questo giorno ed età di enorme spazio di archiviazione, enorme RAM e connessioni Internet veloci, potrebbe non avere senso evitare i file mega- .so .

Inoltre, la proliferazione .so potrebbe essere evitata avendo libeverything.so dipendente da libsomethings.so , in modo che le parti in libsomethings.so non verrebbero duplicate.