[Linuxtrent] Re: problemi di compilazione con OpenSSL
- From: "Laura Gatti" <lalo.gatti@xxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Mon, 15 Oct 2007 14:35:27 +0200
Rieccomi.
On 10/12/07, Emanuele Olivetti <emanuele@xxxxxxxxxxxxxx> wrote:
>
> Roberto Resoli wrote:
> > Il 11/10/07, Laura Gatti<lalo.gatti@xxxxxxxxx> ha scritto:
> >
> >> Grazie del suggerimento, Roberto, intanto in privato Emanuele mi ha
> risolto
> >> il problema. Ora devo andare in riunione e non ho tempo per spiegare
> com'e'
> >> andata, ma appena posso lo faro'.
> >>
> >
> > grazie, sono curioso ...
> >
> > Rob
> >
> Faccio un breve report io visto che Laura non e' al computer oggi.
> Inoltre segnalo un comportamento bizzarro che ancora non ha spiegazione
> (non ci abbiamo dedicato abbastanza tempo pero').
Alla fine ha gia' detto tutto lui, tranne qualche piccola imprecisione che
pero' non e' influente, tipo
la versione di openssl di sistema e' la 0.9.8a e non la 0.9.8c
Il nocciolo del problema di Laura era legato alla presenza di due versioni
> di openssl: la 0.9.8c (di sistema) e la 0.9.8e (installata in /usr/local).
> A causa di un problema di configurazione della versione in local, durante
> la compilazione il g++ prendeva gli header della "e" e i .so della "c".
> Quindi si generavano errori in compilazione, peraltro poco indicativi
> della situazione sottostante.
>
> Riguardo l'errore di configurazione di openssl installato in local: quando
> compili dai sorgenti il config di openssl come default NON crea shared
> libraries (ovvero alla fine non ci sono libssl.so e libcrypto.so in
> /usr/local/ssl/lib) ma solo la versione per compilazione
> statica (ovvero libssl.a e libcrypto.a). Laura necessitava delle shared
> libraries e non si era accorta della loro assenza. A dirla tutta, nell'
> installazione in local erano stati creati dei link simbolici che
> puntavano
> al nulla con il nome libssl.so e libcrypto.so. Il g++, non trovando le
> librerie
> libcrypto e libssl nei path indicati alla riga di comando le ha
> poi giustamente cercate - e trovate - nei path di sistema (/lib e
> /usr/lib)
> ma purtroppo di una versione incompatibile rispetto agli header, creando
> l'errore riportato.
All'inizio avevo compilato senza lo shared, poi avevo letto e intuito che mi
servisse e allora ho ricompilato sopra a quello non shared, senza cancellate
niente, e le due configurazioni si sono sovrapposte generando un gran casino
(tipo link che puntavano a niente)
Capito questo il problema si e' risolto ricompilando localmente
> openssl-0.9.8e dopo aver lanciato "./config shared" al posto del solito
> "./config". Con la configurazione "shared" vengono create libssl.so e
> libcrypto.so. Poi ha funzionato tutto, come e' giusto che sia.
esatto
Nel fare qualche altra prova abbiamo riscontrato questo strano problema.
> Almeno per me e' strano. Eccolo: provando una compilazione statica,
> ovvero:
> g++ libssl.a libcrypto.a dh_creation.cpp -o dh_creation
> e' risultato un problema di simboli non risolti:
> ---
> /tmp/ccHopaUB.o: In function `seed_rng()':
> dh_creation.cpp:(.text+0x10a): undefined reference to `RAND_add'
> dh_creation.cpp:(.text+0x15c): undefined reference to `RAND_add'
> dh_creation.cpp:(.text+0x1ae): undefined reference to `RAND_add'
> /tmp/ccHopaUB.o: In function `main':
> dh_creation.cpp:(.text+0x22b): undefined reference to
> `DH_generate_parameters_ex'
> collect2: ld returned 1 exit status
> ---
> Cambiando invece l'ordine dei file passati a g++ il problema sparisce:
> g++ dh_creation.cpp libcrypto.a libssl.a -o dh_creation
> infatti compila correttamente.
>
> Io ho sempre creduto che l'ordine dei file fosse ininfluente...
>
> Qualcuno sa spiegarmi perche' non e' vero? Non ho approfondito
> ma appena ho tempo lo faccio. Ma se mi potete evitare la
> ricerca... :)
>
> Ciao,
>
> Emanuele
>
>
> --
> Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
> "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
>
>
> com'e' che non vedo la risposta di Matteo?
ciao
Laura
Other related posts: