Newsgroup: it.comp.lang.c
Titolo: Re: librerie e link

 Grazie.
¡De nada!
--
Cingar
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Mi sono avvicinata da poco al C.
Ho fatto oggi una scoperta: quando in un sorgente si chiama una funzione di
libreria, questa non necessariamente e non sempre viene inclusa
nell'eseguibile finale, ma spesso viene solo linkata. Questo fatto non l'ho
capito, ad esser sincera. Ho letto che anche printf() sarebbe linkata. I
miei dubbi, sono:
1) come č possibile che la funzione printf() sia gia' presente in un sistema
operativo?
2) come si fa a stabilire se una funzione debba essere solo linkata ovvero
inclusa nell'eseguibile?
3) qual č l'estensione tipica delle librerie? .lib?
Grazie.

 quali in librerie statiche.
Quasi tutto chiro. Grazie mille!
Il punto che mi resta oscuro è.... vediamo un po'.
Da quanto mi hai detto devo dedurre che la funzione di libreria printf()
possa essere linkata sia staticamente che dinamicamente a seconda del mio
compilatore e delle sue impostazioni. Io uso Icc impostato con tutte le
opzioni di default: che tu sappia, le funzioni printf(9 e scanf(9 vengono
linkate dinamicamente o staticamente in queste condizioni?
Ad ogni modo, credo di aver capito che se una libreria è linkata
dinamicamente, ad esempio la printf() nel caso del mio Icc, per poter
eseguire il .exe è necessario che sul PC sia presente la libreria che
contiene printf(). Ora, io penso che magari alcune librerie siano
distribuite con il sistema operativo, mentre altre debbano essere
distribuite assieme all'eseguibile: giusto?
Quindi, ipotizzando che il mio Icc di default linki dinamicamente una
determinata libreria, se decidessi di copiare il mio eseguibile su un pc su
cui non è presente la libreria (poichè non di sistema e neppure presente in
una cartella di un eventuale Icc presente su questo nuovo PC), mi troverei
ad eseguire un programma non funzionante?
Grazie

 ad eseguire un programma non funzionante?
Esatto. Ti verrebbe fuori un errore a run time di impossibilita` di
reperire la libreria in questione.
Saluti,
Marco

 usano l'estensione ".a"; in altri compilatori, chi lo sa...
GCC non GPP :)
Cmq non e` nato per Linux. Linus Torvalds ha fatto il primo porting del
gcc sotto il proprio sistema operativo :)
Il suffisso .a e`, nuovamente, comune a molti (se non tutti) gli Unix.
Saluti,
Marco

 Grazie
Prego
Saluti,
Marco

 non saprei proprio, non ci programmo mai.
Intemdi dire che il sistema operativo ha come sua parte costitutiva la
libreria standard del c sia come libreria statica che dinamica?
Quindi magari anche per windows potrebbe essere lo stesso?
Infine: mettendo che ci sia un collegamento dinamico ad una libreria, per
distribuire il programma, bisogna fornire anche il file libreria, no? Come
ci si regola con il path a cui si trova la libreria?
Grazie

 ci si regola con il path a cui si trova la libreria?
Se la libreria e' una libreria di sistema non c'e' bisogno,
altrimenti si. 
Tutti i sistemi oprrativi hanno un loro metodo per la ricerca delle
librerie dinamiche. Se non vuoi casini sotto Windows, metti la dll
nella stessa cartella dell'eseguibile che la richiama: e' il primo
posto dove il S.O. effetua la ricerac (a meno che la DLL non si
chiami come una DLL di sistema, in quel caso prende quella nelle
cartelle di default system e syste32).
HTH
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 e' msvcrt.dll
Quindi se io cancellassi provvisoriamente questo file e provassi ad eseguire
un programmino realizzato in c che richiama funzioni di libreria incluse in
msv..., dovrei ricevere un jmessaggio di errore??
Opure tale libreria è compresa anche nel compilatore C?
Grazie

 Opure tale libreria č compresa anche nel compilatore C?
E' una libreria di sistema. Viene data assieme a Windows e viene
aggiornata all'aggiornamento del sistema, i compilatori non l'hanno
a corredo (e non solo per problemi di copyright)...


...

Benvenuta nel problema delle dipendenze!
Certo, se al momento dell'esecuzione un programma non trova le
librerie che deve utilizzare dinamicamente ("al volo"), non funzionerà
(ti è mai capitato, su Windows, che un programma ti dica "Manca
VB6RUN.DLL" o qualcosa del genere?).
Il vantaggio di compilare staticamente è che non hai il problema delle
librerie, ma per contro il binario risulta più grosso e pesante
(immagina anche solo un piccolo editor di testo che però fa uso di un
intero set di librerie di interfaccia...).
Al contrario, un binario "dinamically linked" è molto più leggero, ma
strettamente dipendente dalle librerie. Inoltre, un grande vantaggio
dei binari linkati dinamicamente è che se, ad esempio, 10 programmi
usano la libreria PIPPO, una volta che essa viene caricata dal primo
ad essere lanciato, gli altri 9 la troveranno già in memoria, ed essa
sarà condivisa, migliorando la velocià del tutto.
Ciao,
--
      ______________
(*)--[::::::::::::::]--(*)
(*)--[>::d1s4st3r::<]--(*)
(*)--[::::::::::::::]--(*)
(*)--[::wonder'ing::]--(*)
(*)--[::what's::::::]--(*)
(*)--[::^happening::]--(*)
(*)--[::|^::::::::::]--(*)
(*)--[__||__________]--(*)
 |......................|
http://xoomer.virgilio.it/
 +------> mental_insomnia/
(*) <-------------------+

 a corredo (e non solo per problemi di copyright)...
Grazie per le spiegazioni.
Ad ogni modo è corretto dire che ogni compilatore deve cmq avere le librerie
nel caso in cui le si voglia includere (linking statico) nell'eseguibile?
Grazie

 nel caso in cui le si voglia includere (linking statico) nell'eseguibile?
Spero che a nessuno benga in mente di linkare staticamente il runtime
del C, ma penso che la risposta sia SI.
Ciao Angelo
