Openssl unresolved external BN_is_zero - c

Question

During the development of a small project using statically linked OpenSSL 1.0.2e I encountered a strange error in VS13:
Error LNK2001: unresolved external symbol _BN_is_zero
Quite often, this happens when you forget to properly liked .lib file in the project properties, but all of the properties were double-checked - they are correct.
Configuration - Release, MT, libs are MT, bh.h included.
And even if one of the libraries is not linked properly, I should have multiple compiler errors complaining about unresolved external symbols of all the elements used in the project, but in my case unresolved external symbol is the only BN_is_zero.
After quick googling there wasn't found any issues, related to openssl bugs and I guess that the problem resides at my project.
Any tips will be appreciated.
UPD
Here is some screens:

Answer 1

I actually forked the csrp github project and compiled it against the particular openssl libraries you are pointing at. I had to slightly modify test_srp.c and src.c to add some code that isn't available on VS2013. A fork of csrp with the changes applied and the visual studio project for VS2013 to compile it can be found here:
https://github.com/sigmoidal/csrp
Note that you need to change the paths of the openssl path on BOTH the debug and release versions to reflect your VS Configuration Properties:
C/C++ > General > Additional Include Directories
D:\dev\openssl\openssl-1.0.2e-vs2013\include
(you should not point it to $openssl_path/include/openssl, it will not work)
and also:
Linker > Input > Additional Dependencies:
For release configuration:
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\libeay32MT.lib
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\ssleay32MT.lib
For debug configuration:
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\libeay32MTd.lib
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\ssleay32MTd.lib
(notice the "d" suffix on debug libs)
Compiled ok for me.

Answer 2

I'm guessing here, but according to the OpenSSL source BN_is_zero is defined as a macro:
http://osxr.org/openssl/source/crypto/bn/bn.h#0407
So perhaps the module that is compiled into srp.obj is making a call to BN_is_zero but is not including bn/bn.h and in the absence of a prototype the compiler is generating a default one.
If this is the case, including the bn.h definitions should avoid the linker error.

Answer 3

It was tricky, but I've finally solved it based on the Drew MacInnis tips.
The matter is that openssl 1.0.2e broke the BN_is_zero functionality by simply removing the macros-containing header from sources. So, the solution is:
Download the bn.h include file from 1.0.1h (or here)
Place bn.h to %OPENSSL_HOME%/crypto/bn directory
Change #include <openssl/bn.h> for #include <../crypto/bn/bn.h>