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 <dthomp...@prinpay.com> > > From: owner-openssl-us...@openssl.org 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 openssl-users@openssl.org > Automated List Manager majord...@openssl.org > >
