Trent Nelson wrote:
Hi,
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.
#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 ;-)
Things are somewhat more complicated than that depending on which version and
what form the runtime libraries take when building for WIN64A. Whether or not
the bufferoverflowU.lib code is required totally independent of what flags have
been selected when compiling your own code.
Try the following which I've just repeated with the Visual Studio Express 2005
compiler to confirm its behaviour.
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("hello\n");
return(0);
}
cl x.c
This will fail with LIBCMT which includes a reference to the security cookie and
therefore requires that the application link in bufferoverflowU.lib.
cl /MD x.c
This works - as the DLL form for the C runtime includes the necessary logic to
handle things.
Adding /GS- (to explicitly disable this stuff) does not change either of these.
Your suggestion of the #if line block does indeed work around the issue for
Visual Studio Express 2005 at least so that is an alternate approach to consider
although adding in library references via pragmas feels somewhat strange.
Tim.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
