How to Link to V8 in Visual Studio 2003

[har...@telstra.com]

Sharing what i experienced in linking to v8 under VS2003 case anyone
else has the same issues.

Summary:
Compiled V8 as a shared library under VC8.0 (Visual Studio 2005) using
scons (statically linking produces lots of unresolved dependencies for
standard calls that don't exist).
Altered the v8.h to remove all the default function values that use v8
templates to fix the v8.h(509): fatal error C1001: INTERNAL COMPILER
ERROR (compiler file 'msc1.cpp', line 2708), a patch for this is
below.
Finally remembered to add the define "USING_V8_SHARED" to fix the
unresolved external symbol "private: static class
v8::HandleScope::Data v8::HandleScope::current_" when linking against
the dll.

Detail:
I have been experimenting with replacing a preexisting propriety
javascript engine with v8 in our project. There are many reasons for
doing so, primarily the speed increase it would provide and the lack
of debug support in the preexisting engine. However currently the
project is only compatible with Visual Studio 2003, this of course is
a major annoyance but the time involved in porting it forward to
2005/08 is considerable (20K+ errors to attend to).

So the solution was to compile v8 under VC8.0 using scons and link
against it in VC7.1. The first problem was encountered very quickly.

Including the v8.h header produced a very strange compiler error:

v8.h(509): fatal error C1001: INTERNAL COMPILER ERROR (compiler file
'msc1.cpp', line 2708)

This with some experimentation was fixed by removing the default
function arguments in the header that used v8 template. This required
changes to the code I had written to reflect the loss of these default
arguments. Not a huge issue but strange none the less. Given that this
is a side project I didn't devote much time to working out why this
was happening. Note i created a separate v8-2003.h header with the
changes in it. V8 is still being compiled using the original dll.

After that it was quickly found that statically linking to the v8
library produced a bunch of unresolved dependencies so I quickly
switched to using the shared library. Which then produced an
unresolved symbol when linking against the dll:

unresolved external symbol "private: static class
v8::HandleScope::Data v8::HandleScope::current_"

It was the end of a long day so I surrendered at this point. This
morning when I took a quick look at the v8 header I noted the define
USING_V8_SHARED. Adding this to the preprocessor definitions solved
the problem and it compiled and ran without error.

I hope my rambling saves someone the messing around I had. Loving the
library so keep up the good work!

Below is the patch I used to solve the Internal Compiler Error, based
on svn revision 768 (dated 17th November 2008) for v8.h.

510,511c510,511
< Handle<Integer> resource_line_offset = Handle<Integer>
(),
< Handle<Integer> resource_column_offset =
Handle<Integer>())
---
> Handle<Integer> resource_line_offset,
> Handle<Integer> resource_column_offset)
1444,1446c1444,1446
< InvocationCallback callback = 0,
< Handle<Value> data = Handle<Value>(),
< Handle<Signature> signature = Handle<Signature>());
---
> InvocationCallback callback,
> Handle<Value> data,
> Handle<Signature> signature);
1676,1679c1676,1678
< static Local<Signature> New(Handle<FunctionTemplate> receiver =
< Handle<FunctionTemplate>(),
< int argc = 0,
< Handle<FunctionTemplate> argv[] = 0);
---
> static Local<Signature> New(Handle<FunctionTemplate> receiver,
> int argc,
> Handle<FunctionTemplate> argv[]);
2093,2095c2092,2094
< ExtensionConfiguration* extensions = 0,
< Handle<ObjectTemplate> global_template = Handle<ObjectTemplate>
(),
< Handle<Value> global_object = Handle<Value>());
---
> ExtensionConfiguration* extensions,
> Handle<ObjectTemplate> global_template,
> Handle<Value> global_object);