Building v8 as a static library generates build errors, but ptoduces usable libraries

[A.M.]

I have two questions related to building the v8 as a static library.

1. I'm building on Windows and the build fails very close to the end with this output:

ninja -C out.gn/x64.debug
ninja: Entering directory `out.gn/x64.debug'
[1/1] Regenerating ninja files
[1441/1543] LINK unittests.exe unittests.exe.pdb
FAILED: unittests.exe unittests.exe.pdb
C:/dev/v8/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe ../../build/toolchain/win/tool_wrapper.py
    link-wrapper environment.x64 False link.exe /nologo /OUT:./unittests.exe /PDB:./unittests.exe.pdb @./unittests.exe.rsp
LINK : warning LNK4001: no object files specified; libraries used
LINK : error LNK1218: warning treated as error; no output file generated
[1446/1543] CXX obj/test/cctest/cctest_sources/test-code-generator.obj
ninja: build stopped: subcommand failed.Enter code here...

Apparently, no object files were supplied to the linker, only libraries, which is a warnings, but warnings are treated as errors, hence it fails the build. By the time it reaches this point, all v8 libraries are built, so I can use the v8 for my purposes, but it would be nice if it built as it is supposed to.

Anybody has any idea how to remedy this problem?

2. Static v8 libraries are build against static VC++ CRT (i.e. with the `/MT` and `/MTd` flags), which means that they will not pick up any security updates from MS and also that the project cannot share memory C++ allocations (i.e. `malloc`/`operator new`), CRT callbacks and some other things with the rest of the code, so it would need to be completely encapsulated within its own DLL. I found a really old thread from 2012:

https://groups.google.com/forum/#!topic/v8-users/PpA3mhICTiM

, but it's just too old to be of any significance.

Is there a way to build v8 static libraries against VC++ DLL CRT (i.e. with `/MD` and `/MDd` flags)?

Thanks!

[Ben Noordhuis]

I don't know about (1), haven't run into that myself, but apropos (2),
the CRT linking logic is effectively hard-coded in
build/config/win/BUILD.gn; look for 'default_crt'. You could try
sending a CL that adds a build flag to override the default or simply
patch the file locally.

[A.M.]

Thanks for responding, Ben. Your feedback is always appreciated.

> but apropos (2),
> the CRT linking logic is effectively hard-coded in
> build/config/win/BUILD.gn;

This is surprising - it makes the static build of v8 quite expensive and error-prone to maintain for a multi-DLL project, given that hundreds of implementation callbacks would have to be implemented with `extern "C"` linkage, as none of the STL, etc stuff can be shared between DLLs.

> You could try
> sending a CL that adds a build flag to override the default or simply
> patch the file locally.

If this is hard-coded in this day and age, it makes me think that Google did it for a reason that I may not realize until I'm too deep into the project.

May be I should switch to Chakra for this project. It's not as fast as the v8, but there will be no compatibility issues when running multi-threaded JavaScript within a Node process.

[Ben Noordhuis]

The reason is probably that V8 is designed to be shipped as part of a
monolithic binary (Chromium, Node.js) rather than a standalone
library.

Dynamically linking to the CRT there doesn't gain you much and you
lose some in predictability and reproducibility. From a QA
perspective, it's great to have full control over all your components.

[A.M.]

> Dynamically linking to the CRT there doesn't gain you much

Not sure what you mean. Linking in dynamic CRT gives you so much that one should even consider whether to even work with a statically-linked CRT for any large project. The biggest issue is the heap CRT uses - if a project uses multiple DLLs, which is pretty much the norm for any large project, then the code linking against static v8 libraries must also use static CRT, which means that it cannot share memory allocations with the rest of the code, which in turn means I cannot even pass around things like `std::string` between these DLLs because if memory is moved to a string constructed in another DLL, it will just corrupt memory. There are other reasons as well, but this one is significant on its own and the bottom line that one has to design a whole interface to move things carefully across the boundary of such DLL. Not a trivial task.

> Node.js) rather than a standalone library.

Node.js is not suffering from this because it's using the component build, which uses a CRT in a DLL

[Ben Noordhuis]

On Mon, Apr 30, 2018 at 3:25 PM, A.M. <cis7...@gmail.com> wrote:
> Node.js is not suffering from this because it's using the component build,
> which uses a CRT in a DLL

Node.js doesn't use GN. It uses a monolithic GYP build that links
everything together with /MT. (And yes, it's not without its
downsides, too.)

[A.M.]

On Monday, 30 April 2018 10:16:10 UTC-4, Ben Noordhuis wrote:

Node.js doesn't use GN.  It uses a monolithic GYP build that links
everything together with /MT.

Interesting. Didn't know that. Thanks for pointing out.

[A.M.]

On Monday, 30 April 2018 10:16:10 UTC-4, Ben Noordhuis wrote:

Node.js doesn't use GN.  It uses a monolithic GYP build that links
everything together with /MT.

Never had to look inside node-gyp/Node.lib before and was wondering how one of the apps I was working on links against the dynamic VC++ CRT and realized that Node.lib an import library and everything is exported from node.exe, so modules are free to use whatever option they need. I see now how /MT is working out for Node.

[A.M.]

On Saturday, 28 April 2018 05:30:17 UTC-4, Ben Noordhuis wrote:

the CRT linking logic is effectively hard-coded in
build/config/win/BUILD.gn; look for 'default_crt'.  You could try
sending a CL that adds a build flag to override the default or simply
patch the file locally.

Ben, thank you for pointing out where to change the CRT type in the GN build. You saved me a ton of time trying to figure out how to do it. After spending a few hours trying to isolate memory allocations in a large app I ended up changing `default_crt` to `dynamic_crt` and it's working fine in all of my tests.

The application I'm working on is a Windows app, but it will be ported to Linux at some point. Do you know if the static v8 libraries link against a static `libstdc++` or any other critical libraries like this one? Thanks, again.

[Ben Noordhuis]

V8 by default links statically against the bundled libc++ in
buildtools/third_party/libc++ but dynamically against libc, librt,
etc.

[A.M.]

On Thursday, 3 May 2018 12:44:14 UTC-4, Ben Noordhuis wrote:

V8 by default links statically against the bundled libc++ in
buildtools/third_party/libc++ but dynamically against libc, librt,
etc.

Hmm... seeing how `v8.h` includes `memory`, it could cause problems regardless of whether it's a static build or not if the v8 itself was built against `buildtools/third_party/libc++` and the project including `v8.h` included `memory` from the standard include path. I guess I will cross this Rubicon when I get there. It's good to know about the bundled `libc++`.

Thanks again for your insights, Ben.

[Steven An]

Hi all,

I'm getting similar errors on Windows, VS 2017, when building for static link:

[520/529] LINK cctest.exe cctest.exe.pdb

FAILED: cctest.exe cctest.exe.pdb

C:/Users/stevenan/gh/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./cctest.exe /PDB:./cctest.exe.pdb @./cctest.exe.rsp

LINK : warning LNK4001: no object files specified; libraries used

LINK : error LNK1218: warning treated as error; no output file generated

[525/529] LINK v8_simple_wasm_globals_section_fuzzer.exe v8_simple_wasm_globals_section_fuzzer.exe.pdb

ninja: build stopped: subcommand failed.

The build does totally succeed if I build without these gn args:

is_component_build = false

v8_static_library = true

But this does not produce v8_base.lib. All other libs I need appear to be there, but not v8_base.lib. I do however see v8_base_0.lib and v8_base_1.lib - are those useable..?

[Steven An]

Ah OK. As others have discovered, you simply need to link in both v8_base_0.lib and v8_base_1.lib and it works now. Great!

[A.M.]

On Monday, 7 May 2018 16:16:46 UTC-4, Steven An wrote:

Ah OK. As others have discovered, you simply need to link in both v8_base_0.lib and v8_base_1.lib and it works now. Great!

Yes, for most apps you will need all of them:

icui18n.lib
icuuc.lib
v8_base_0.lib
v8_base_1.lib
v8_external_snapshot.lib
v8_init.lib
v8_initializers.lib
v8_libbase.lib
v8_libplatform.lib
v8_libsampler.lib
v8_nosnapshot.lib
v8_snapshot.lib

, plus a few runtime bits:

icudtl.dat
natives_blob.bin
snapshot_blob.bin