OpenSSL migration - Linking issues

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSSL migration - Linking issues

Hankyaku
Dear All,

I'm working on a bigger poject where openSSL is used. Right now I'm doing the migration from 1.0.0e to 1.0.1c. On the way I get a number of linking errors, like: "ssleay32.lib(ssl_sess.obj) : error LNK2001: unresolved external symbol _BUF_strdup"

This problem relates to the new additions only, and the problem is quite interesting.
I manage to compile the ssleay32 project (containing openSSL) perfectly, but when I compile another project relying on ssleay32, I get linking errors similar to that one above.
What did I get wrong? I checked all references, refreshed the files, made clean rebuilds, I tried everything. :(

Do you have any suggestions or did you ran into something similar already?
 
Thanks!!!!
Han
Reply | Threaded
Open this post in threaded view
|

RE: OpenSSL migration - Linking issues

Dave Thompson-5
> From: [hidden email] On Behalf Of Hankyaku
> Sent: Friday, 31 August, 2012 05:29

> I'm working on a bigger poject where openSSL is used. Right
> now I'm doing the migration from 1.0.0e to 1.0.1c. On the way
> I get a number of linking errors, like: "ssleay32.lib(ssl_sess.obj)
> : error LNK2001: unresolved external symbol _BUF_strdup"
>
> This problem relates to the new additions only, and the
> problem is quite interesting. I manage to compile the ssleay32
> project (containing openSSL) perfectly, but when I compile
> another project relying on ssleay32, I get linking errors
> similar to that one above. What did I get wrong? I checked
> all references, refreshed the files, made clean rebuilds,
> I tried everything. :(

OpenSSL normally builds to two libraries -- libssl.* and
libcrypto.* on Unix, ssleay32.* and libeay32.* on Windows.
Your application needs to link both, and depending on the
linker it may need to link them in that order (I'm not sure
about the MS linker, or linkers, in this regard).

But this shouldn't be different in 1.0.1 or even 1.0.0 --
it's been this way for years. Possibly your "1.0.0e"
wasn't a standard build but a modified one that combined
into a single library?

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL migration - Linking issues

Hankyaku
Thank you for the answer, I think I know now what the problem is:
I'm using the ssleay32 and libeay32 in another project, BUT I forgot to update that project with the newly added files. 
So while the libraries compile nice, the linker doesn't kick in yet, but it does at the project where I refer to them. That's why I got the error messages only when compiling (and then linking!) my project referring to the libs.
I'm working on the update, will write back once I succeeded.

2012/9/1 Dave Thompson <[hidden email]>
> From: [hidden email] On Behalf Of Hankyaku
> Sent: Friday, 31 August, 2012 05:29

> I'm working on a bigger poject where openSSL is used. Right
> now I'm doing the migration from 1.0.0e to 1.0.1c. On the way
> I get a number of linking errors, like: "ssleay32.lib(ssl_sess.obj)
> : error LNK2001: unresolved external symbol _BUF_strdup"
>
> This problem relates to the new additions only, and the
> problem is quite interesting. I manage to compile the ssleay32
> project (containing openSSL) perfectly, but when I compile
> another project relying on ssleay32, I get linking errors
> similar to that one above. What did I get wrong? I checked
> all references, refreshed the files, made clean rebuilds,
> I tried everything. :(

OpenSSL normally builds to two libraries -- libssl.* and
libcrypto.* on Unix, ssleay32.* and libeay32.* on Windows.
Your application needs to link both, and depending on the
linker it may need to link them in that order (I'm not sure
about the MS linker, or linkers, in this regard).

But this shouldn't be different in 1.0.1 or even 1.0.0 --
it's been this way for years. Possibly your "1.0.0e"
wasn't a standard build but a modified one that combined
into a single library?

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]