> I tried to build 0.9.8g with Visual Studio 2008 x64 vi 'perl
> Configure VC-WIN64A'. The resulting nt.mak and ntdll.mak files had
> 'bufferoverflowU.lib' added to LFLAGS, courtesy of a few lines in
> util/pl/VC-32.pl that look like this:
> $ex_libs.=' bufferoverflowu.lib' if ($FLAVOR =~ /WIN64/);
> There are two problems here. First, /GS isn't ever added to CFLAGS,
> which means the security checks aren't even enabled, making the
> specification of bufferoverflowu.lib pointless. I assume this was
> left out by mistake.
> Secondly, it's not appropriate/necessary to link to
> bufferoverflowu.lib when building with newer versions of Visual
> Studio and/or the Platform SDK. On my development server, I've got
> Visual Studio .NET 2003 Professional, Visual Studio 2005 Professional
> and Visual Studio 2008 Professional installed, as well as Platform
> SDKs 5.0, 6.0a and 6.1. Given that, consider the following:
> ...
> There's a relevant discussion about the issue at
> http://forums.microsoft.com/MSDN/Sho...72235&SiteID=1.
> Providing the following in a header somewhere is probably the most
> suitable option, otherwise the Perl build framework would need to be
> modified to correctly detect which VC or PSDK environment is being
> used:
> #if _MSC_FULL_VER > 140000000 && _MSC_FULL_VER <= 140040310 #pragma
> comment(lib,"bufferoverflowU.lib") #endif
> Again, all of this is moot if /GS isn't added as a CFLAG ;-)

Well, the link you've provided yourself mentions that some of libraries
provided with some Platform SDKs required the library in question, i.e.
even without specifying /GS on your own code. In other words, adding of
the library in question was not a coincidence, mistake or omission. As
we see now it didn't hold in long run, but by that time it was required.
Something will be done about this. Cheers. A.
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org