Windows Linking Errors

[Garry]

I'm getting this liner error:

>> TestV8.obj : error LNK2001: unresolved external symbol "private: static class v8::HandleScope::Data v8::HandleScope::current_" (?current_@HandleScope@v8@@0VData@12@A)

Compiling v8 using this line:

>> scons mode=release snapshot=on library=shared

At first I thought it could have been because my target app uses /MD,
and the library uses /MT, so after fixing that:

>> d:\...\trunk\src\third_party/dtoa/dtoa.c(1528) : error C2220: warning treated as error - no 'object' file generated
>> d:\...\googlev8\trunk\src\third_party/dtoa/dtoa.c(1528) : warning C4273: 'gay_strtod' : inconsistent dll linkage

But after removing /WX (treat warning as error) I get the same result:

TestV8.obj : error LNK2001: unresolved external symbol "private:
static class v8::HandleScope::Data v8::HandleScope::current_" (?
current_@HandleScope@v8@@0VData@12@A)


Any help/advice is appreciated, I'm using the latest SVN code as of
the time on this post

[Søren Gjesse]

When compiling an application using v8.dll remember to define USING_V8_SHARED, see http://code.google.com/p/v8/wiki/BuildingOnWindows section "Building the hello_world sample on Windows" where there is an example on linking with v8.dll.

When building the v8.dll in release mode you should use /MT, as you should when compiling you application in release mode. Use /MTd for both in debug mode.

Regards,

Søren

[Garry]

Doh, thanks, now I feel like an idiot.

What's the reason for having to use /MT instead of /MD? The rest of my
app uses /MD - isn't it dangerous to be mixing them?

garry

On Sep 26, 12:40 pm, "Søren Gjesse" <sgje...@chromium.org> wrote:
> When compiling an application using v8.dll remember to

> define USING_V8_SHARED, see <http://code.google.com/p/v8/wiki/BuildingOnWindows>http://code.google.com/p/v8/wiki/BuildingOnWindows

> <http://code.google.com/p/v8/wiki/BuildingOnWindows>section
> "Building the hello_world sample on Windows" where there is an example on
> linking with v8.dll.
> When building the v8.dll in release mode you should use /MT, as you should
> when compiling you application in release mode. Use /MTd for both in debug
> mode.
>
> Regards,
> Søren
>

[Søren Gjesse]

In the V8 build we have decided to use /MT (and /MTd) in order to minimize the external dependencies. One could argue that if building a DLL the DLL itself should use DLL's as much as possible, or there should be another option to determin whether the V8 DLL should use the static or dynamic CRT library. I don't think mixing /MT and /MD is a problem here as we are not using CRT library stuff across the V8 API boundary. Off cause mixing /MT and /MD will give you two copies of the CRT library in your application.

Regards,

Søren

[codedread]

Sorry to resurrect this, but I have a question surrounding this exact
topic:

- I have a rather large code base that heavily uses SDL (http://
www.libsdl.org/faq.php?action=listentries&category=4#43 ) which must
be /MD (Multithreaded DLL)
- I have integrated V8 into my code (the DLL is apparently built
using /MT as you state)
- I am using Visual Studio 2005 SP1
- I have included the distributable runtime files (msvcm80.dll,
msvcp80.dll, msvcr80.dll)

I can run my app just fine on my computer. In fact, it seems I can
run the file on any computer installed with VS 2005.

However, since integrating V8, people without VC 2005 cannot run my
executable program, they get a "The application failed to initialize
properly" dialog and then it quits. I have tried to integrate v8 as a
static library or as a shared library (/DUSING_V8_SHARED) with the
same result. Again, I get no errors upon compiling or linking, it's
only at the client end that the error occurs.

1) Are there other DLLs that I need to include with my distributable?
2) Is there a way to build V8 with /MD so that all are consistent? I
tried to do this and I get 'inconsistent dll linkage' errors
surrounding strtod/gay_strtod...

I realliy appreciate any clues you can give me.

Thanks,
Jeff

On Oct 2, 2:51 am, "Søren Gjesse" <sgje...@chromium.org> wrote:
> In the V8 build we have decided to use /MT (and /MTd) in order to minimize
> the external dependencies. One could argue that if building a DLL the DLL
> itself should use DLL's as much as possible, or there should be another
> option to determin whether the V8 DLL should use the static or dynamic CRT
> library. I don't think mixing /MT and /MD is a problem here as we are not
> using CRT library stuff across the V8 API boundary. Off cause mixing /MT and
> /MD will give you two copies of the CRT library in your application.
> Regards,
> Søren
>

[Pete Gontier]

If you are distributing a debug build of your app, it depends on the debug builds of the shared libraries for the C/C++ runtime, and the only way to get those libraries is to have the appropriate version of Visual Studio installed. Happily, the Express flavors are enough. Alternatively, distribute the release build of your app.

If you are not distributing a debug build of your app, and people still have problems, then you probably want to play around with Dependency Walker and see if you can figure out why. If nothing jumps out at you, then consider finding a way for the people experiencing the problems to do the same. If there is a problem loading your app, Dependency Walker will make it glaringly obvious, and a screen shot should be enough.

Pete Gontier <http://pete.gontier.org/>

[codedread]

I am only distributing the release version of my app. Can you give
more specific explanation of how dependency walker will help?

Thanks,
Jeff

On Oct 13, 8:16 pm, Pete Gontier <p...@gontier.org> wrote:
> If you are distributing a debug build of your app, it depends on the  
> debug builds of the shared libraries for the C/C++ runtime, and the  
> only way to get those libraries is to have the appropriate version of  
> Visual Studio installed. Happily, the Express flavors are enough.  
> Alternatively, distribute the release build of your app.
>
> If you are not distributing a debug build of your app, and people  
> still have problems, then you probably want to play around with  
> Dependency Walker and see if you can figure out why. If nothing jumps  
> out at you, then consider finding a way for the people experiencing  
> the problems to do the same. If there is a problem loading your app,  
> Dependency Walker will make it glaringly obvious, and a screen shot  
> should be enough.
>
> Pete Gontier <http://pete.gontier.org/>
>
> On Oct 13, 2008, at 1:29 PM, codedread wrote:
>
>
>
> > Sorry to resurrect this, but I have a question surrounding this exact
> > topic:
>
> > - I have a rather large code base that heavily uses SDL (http://

> >www.libsdl.org/faq.php?action=listentries&category=4#43) which must

[Pete Gontier]

Anything I explain here will pale in comparison to the experience of running the Dependency Walker app against your own app and reading the documentation if it what Dependency Walker tells you doesn't make sense immediately. In any case, this is a Windows issue rather than a V8 issue.

Pete Gontier <http://pete.gontier.org/>

On Oct 13, 2008, at 7:05 PM, codedread wrote:

I am only distributing the release version of my app.  Can you give
more specific explanation of how dependency walker will help?

If you are distributing a debug build of your app, it depends on the  

debug builds of the shared libraries for the C/C++ runtime, and the  

only way to get those libraries is to have the appropriate version of  

Visual Studio installed. Happily, the Express flavors are enough.  

Alternatively, distribute the release build of your app.

If you are not distributing a debug build of your app, and people  

still have problems, then you probably want to play around with  

Dependency Walker and see if you can figure out why. If nothing jumps  

out at you, then consider finding a way for the people experiencing  

the problems to do the same. If there is a problem loading your app,  

Dependency Walker will make it glaringly obvious, and a screen shot  

should be enough.

[codedread]

Ok, but my question still stands - is there a way to build V8 using
Multithreaded DLL? Wouldn't it make sense to provide this option to
people already building against that runtime?

Thanks,
Jeff

[MikeM]

coeddread,

Visual Studio has a redistributable installer package that you need to
run on other machines (where Visual Studio is not installed).
You can't just have the Visual Studio DLL's present. They have to
actually be installed property.
This is due to manifests that MS introduced.
If you don't install them right it won't run. (I've been there)
Its not like the VC 6 days.

Try that and see what happens.

If it doesn't work, do what Pete says. Run dependancy walker.
Run it on the client machine that isn't working (not on your dev
machine).

> Ok, but my question still stands - is there a way to build V8 using
> Multithreaded DLL?  Wouldn't it make sense to provide this option to
> people already building against that runtime?

Just to throw my 3 cents in on this...
I personally use Multi-threaded DLL (/MD) exclusively.
This needs to be an option if its not.
Stupid question...Why can't you just open the V8 project files and
change the runtime library setting to /MD?

[codedread]

On Oct 13, 11:57 pm, MikeM <Mi...@reteksolutions.com> wrote:
> coeddread,
>
> Visual Studio has a redistributable installer package that you need to
> run on other machines (where Visual Studio is not installed).
> You can't just have the Visual Studio DLL's present.  They have to
> actually be installed property.
> This is due to manifests that MS introduced.
> If you don't install them right it won't run.  (I've been there)
> Its not like the VC 6 days.
>

I can do this, but I consider that a deal-breaker. Plus, I'm not sure
I buy it - why would Microsoft do this, it would discourage wide
deployment of apps built using their premiere development suite.
There _must_ be a way around this. Are you saying that everyone who
creates applications using VS 2005 includes this Visual Studio
installer package in their own installer package?

> Just to throw my 3 cents in on this...
> I personally use Multi-threaded DLL (/MD) exclusively.
> This needs to be an option if its not.
> Stupid question...Why can't you just open the V8 project files and
> change the runtime library setting to /MD?

I tried this, it led to errors (well, warnings the Garry mentions
above). I ignore the warnings and add in the libraries that should be
ignored. This results in the static libraries being built. I change
the output result to a DLL instead of static library and then I get
further errors:

1>Linking...
1> Creating library C:\v8\tools\visual_studio\Release\lib
\v8_base.lib and object C:\v8\tools\visual_studio\Release\lib
\v8_base.exp
1>bootstrapper.obj : error LNK2019: unresolved external symbol
"public: static class v8::internal::Vector<char const > __cdecl
v8::internal::Natives::GetScriptSource(int)" (?
GetScriptSource@Natives@internal@v8@@SA?AV?$Vector@$$CBD@23@H@Z)
referenced in function "public: static class
v8::internal::Handle<class v8::internal::String> __cdecl
v8::internal::Bootstrapper::NativesSourceLookup(int)" (?
NativesSourceLookup@Bootstrapper@internal@v8@@SA?AV?
$Handle@VString@internal@v8@@@23@H@Z)
1>bootstrapper.obj : error LNK2019: unresolved external symbol
"public: static class v8::internal::Vector<char const > __cdecl
v8::internal::Natives::GetScriptName(int)" (?
GetScriptName@Natives@internal@v8@@SA?AV?$Vector@$$CBD@23@H@Z)
referenced in function "private: static bool __cdecl
v8::internal::Genesis::CompileBuiltin(int)" (?
CompileBuiltin@Genesis@internal@v8@@CA_NH@Z)
1>debug.obj : error LNK2001: unresolved external symbol "public:
static class v8::internal::Vector<char const > __cdecl
v8::internal::Natives::GetScriptName(int)" (?
GetScriptName@Natives@internal@v8@@SA?AV?$Vector@$$CBD@23@H@Z)

I'm clearly lost here, so again - any help is appreciated.

[Pete Gontier]

On Oct 13, 2008, at 10:24 PM, codedread wrote:

Are you saying that everyone who creates applications using VS 2005 includes this Visual Studio installer package in their own installer package?

I can't speak for everyone, but I've shipped many products to many thousands of users, and I've always statically linked the C/C++ runtime libraries for (at least) three reasons:

• I haven't wanted to answer the question you are asking.
• The static libraries have never been enough burden to notice much less matter.
• I am skeptical other developers will install/remove the dynamic libraries correctly.

However, there are situations in which the dynamic C/C++ runtime libraries must be used, such as when an app and its plug-ins need to communicate in terms of or via these libraries. If this is true in your case, then you must find the answer to your question.

If you are able to statically link the C/C++ runtime libraries, then one diagnostic you could try is to do so, and, if the problem goes away, you can choose whether to keep things this way or figure out how to handle the redistributables. If the problem doesn't go away, one tool that can help you figure out why not is Dependency Walker.

Pete Gontier <http://pete.gontier.org/>

[jakov....@gmail.com]

On Oct 14, 7:24 am, codedread <codedr...@gmail.com> wrote:
> Are you saying that everyone who creates applications using
> VS 2005 includes this Visual Studio installer package in their
> own installer package?

Yes, that is exactly what I'm saying. Provided they don't link
statically against CRT, of course.

[Søren Gjesse]

This is now supported on bleeding_edge r817. Use the SCons option
msvcrt building

scons msvcrt=shared sample=shell

will have shell.exe load MSVCR80.DLL.

See http://codereview.chromium.org/11564 for details.

Regards,
Søren