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); --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
