Newsgroup: it.comp.programmare.win32
Titolo: [C++] Problemi con linking di librerie statiche

Ciao a tutti,
Ho qualche problema a creare una piccola applicazione di test che faccia 
uso di una libreria[1] esterna. Premesso che uso g++ di cygwin sotto 
WindowsXP, la mia situazione è la seguente:
- una libreria esterna di cui ho i files .lib e i files di header .h;
- una applicazione testlib.cpp che contiene solo un main() all'interno 
del quale viene instanziato un oggetto di una classe definita nella 
libreria (in pratica *una sola* riga di codice);
Quando vado a compilare, se non do alcuna direttiva -l, mi da diversi 
errori di tipo "undefined referece" in corrispondenza dei 
costruttori/distruttori della classe, se inceve provo a dare una 
direttiva -l ed il path dei files .lib mi dice che non riesce a trovare 
il file (anche se il path è corretto).
Qualcuno può aiutarmi?
Ciao e grazie,
Giulio
[1]: la libreria esterna in questione è POCO (
http://poco.appinf.com
)
-- 
OnAir:

 - una libreria esterna di cui ho i files .lib e i files di header .h;
Non credo proprio che puoi utilizzare con il gcc i file lib.
Questi possono essere utilizzati con i compilatori come il VC o Borland

 Questi possono essere utilizzati con i compilatori come il VC o Borland
Ok, ma non avrebbe dovuto darmi un errore sul "tipo" di file?
E, visto che ho i .dll, come posso utilizzare questi invece?
Grazie,
Giulio
-- 
OnAir:

 E, visto che ho i .dll, come posso utilizzare questi invece?
Come ti ho già risposto in un altro thread...
Anzicchè innondare il newsgroup con questi messaggi, se cerchi su 
internet trovi non migliaia, ma MILIONI di esempi e di spiegazioni di 
come si usano le DLL con MinGW!!!
Anzi se vedi nel progetto scaricato, troverai anche esempi di come 
compilarlo utilizzando il MinGW...quindi prendi spunto da là.

 compilarlo utilizzando il MinGW...quindi prendi spunto da là.
Di cui nessuno funziona.
Peraltro - ultima scoperta - è impossibile compilare la libreria con 
"make" di cygwin, ed il motivo è nel messaggio di errore qui sotto:
 >> /usr/local/POCO/build/script/makedepend.gcc: line 10: $'\r': command 
not found
Bizzarro (per non dire assurdo), no?
Ciao,
Giulio
-- 
OnAir:

 Quindi mi devo scaricare/installare pure MinGW :-/
Fai una bella cosa...scaricati wxDev-cpp che è un bel IDE e RAD che 
utilizza MinGW e lo usi visualmente linkando le librerie e vedi che 
tutto funzionerà.

 tutto funzionerà.
Si, ce lo avevo ma lo ho disinstallato. Se volessi un IDE ho a mia 
disposizione sia Eclipse+CDT, che NetBeans che VisualStudio. Il fatto è 
che il progetto andrà portato avanti con Vim ;-).
Andando avanti nei tentativi sono riuscito a ricompilare le librerie con 
g++, il problema è sempre che il linker (ld) non trova il percorso 
indicato dalla -l.
Ora vedo di "indagare" più a fondo o, come dicono i miei "colleghi" 
tedeschi "take a deeper look" ;-)
Ciao e grazie,
Giulio
-- 
OnAir:

 tutto funzionerà.
Scaricato,
Installato,
Linkato.
Stesso problema di quando lo faccio a mano.


Ciao e grazie
Ciao

 Stesso problema di quando lo faccio a mano.
Hai linkato il file .lib nel progetto!?!?

 Hai linkato il file .lib nel progetto!?!?
Ho linkato il linkabile ;-) (in pratica tutto!!!)


 
Uhm...allora hai dei problemi di esportazioni delle funzioni.
Sicuramente se hai usato VisualC per creare la DLL, il file .lib
contiene signature non valide o almeno valide solo per VisualC.
C'è un programma che si chiama Depends, apre e visualizza le funzioni
esportate all'interno di una DLL...
Il sistema di mangling è diverso da compilatore a compilatore ecco 
perchè ottieni problemi di linkaggio.
dovresti esportare le funzioni usando la parola riservata: extern "C",
che ti evita il mangling dei nomi da parte del comp. C++

 E, visto che ho i .dll, come posso utilizzare questi invece?
Se vuoi richiamare una funzione che sta dentro la DLL potresti utilizzare
le API di windows (SDK) LoadLibrary/FreeLibrary per caricare la dll e 
GetProcAddress che dovrebbe restituirti un puntatore alla funzione
da chiamare.
 
Ciao,
Marco.

 file .a che funzionano con g++. 
Ti spiego la situazione in maniera più "completa".
I sorgenti hanno sia gli script per la compilazione con VisualStudio che 
i Makefile.
- La prima volta li ho compilati con VS, ma evidentemente c'è qualche 
errore negli script perchè un comando che viene richiamato (cl.exe, 
credo sia qualcosa "interno" a VS) va in errore e non sono riuscito a 
tracciare
l'errore visto che il messaggio di errore che viene generato non è 
proprio eloquente ;-) Ho ricompilato modulo per modulo con VisualStudio 
ottenendo diversi files .lib e .dll ma non sono riuscito a linkarli per 
la mia micro-applicazione di test (sviluppata senza VS).
- Ho optato per una soluzione un po' più "fantasiosa". Ho fatto uno 
scriptino in Pyhton che analizzava la cartella dei sorgenti e creava i 
comandi da dare al g++ per creare le librerie (come ha detto un mio 
collega/amico ho scritto un programma per creare un programma che poi 
sarebbe stato utilizzato per creare un programma ;-) ).  I comandi che 
vengono dati al g++ sono i seguenti (e qui posso aver fatto qualche 
"cappella" perchè - e credo sia palese - non è che sia praticissimo di 
programmazione in C++):
a) compilare con ">>g++ -c ..." tutti i files sorgenti in files .o;
b) creare una libreria con ">>ar cr ..." che comprende tutti i files .o 
ottenuti al passo precedente. Le opzioni "cr" le ho trovate in rete. 
Altrove ho trovato "ruv" ma di questa ultima combinazione non è che 
abbia capito il senso... La libreria in questione - compilata con il g++ 
- diventa un files .a, giusto? Oppure sbaglio l'estensione?
c) compilare la mia applicazione con ">>g++ <sorgente>.c -o 
<fileeseguibile>.exe -I ./path_che_contiene_gli_headers -lpath_alla_libreria
Sempre e comunque ho un errore del linker (ld).
- Ora ho scaricato la versione per i sistemi POSIX (Linux/Solaris) e 
cerco di ricompilarla con cygwin (quelli per  Win non sono compilabili 
tramite make perchè nei fies degli script utilizzati viene usato il \r\n 
come separatore di linea... ARGH!!! :-D)
Ciao e grazie per i consigli,
Giulio
-- 
OnAir: Mario del Monaco - "Largo al factotum" da "Il Barbiere di
Siviglia" (G. Rossini)

 
Gia'... 
E' per questo che inizialmente chiedevo di vedere il codice (poi
mi sono dimenticato).
Se le funzioni della dll "esterna" non sono state inserite dentro
ad un blocco extern "C" le potra' richiamare solo compilando il "chiamante" 
con lo stesso compilatore che ha prodotto la dll. E questo vale anche tentando
di chiamare direttamente le funzioni che stanno dentro alla dll con
LoadLibrary e GetProcAddress.
Ciao,
Marco.

 contiene signature non valide o almeno valide solo per VisualC.
No, ho utilizzato g++.
Ciao,
Giulio
-- 
OnAir:

 
Aehh allora il problema non è di questo tipo...
c'è altro che viene sbagliato!

 c'è altro che viene sbagliato!
Già... tutto sta nel capire *cosa* e *perchè* ;-)


Ciao e grazie per i consigli,
Prego, ciao
Flix

 garantisco...)
No problem, è il concetto che conta.
;-)
Ciao e grazie,
Giulio
-- 
OnAir: Ark - "Feed the Fire"

 Ciao e grazie,
Prego!

 linkare.
Il problema è questo: dando la direttiva -l in tutte le salse, mi dice 
che la libreria non esiste (!!). Ora ho provato a ricompilare tutto 
sotto cygwin, ottenendo le librerie in formato .so o .so.4. Quando vado 
a compilare le mie applicazioni che linkano a quelle librerie, stavolta 
ho un errore a runtime (ma la sostanza non cambia):
"error while loading shared libraries: libPocoFoundation.so.4: cannot 
open shared object file: No such file or directory"
Grazie per le dritte,
Giulio
-- 
OnAir: Death - "Overactive Imagination"