Re: [v8-users] Building v8 as a static library generates build errors, but ptoduces usable libraries
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. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Building v8 as a static library generates build errors, but ptoduces usable libraries
On Wed, May 2, 2018 at 11:27 PM, A.M. wrote: > 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. V8 by default links statically against the bundled libc++ in buildtools/third_party/libc++ but dynamically against libc, librt, etc. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Building v8 as a static library generates build errors, but ptoduces usable libraries
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. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Building v8 as a static library generates build errors, but ptoduces usable libraries
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. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Building v8 as a static library generates build errors, but ptoduces usable libraries
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. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Building v8 as a static library generates build errors, but ptoduces usable libraries
On Mon, Apr 30, 2018 at 3:25 PM, A.M. 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.) -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Building v8 as a static library generates build errors, but ptoduces usable libraries
> 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 -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Building v8 as a static library generates build errors, but ptoduces usable libraries
On Sat, Apr 28, 2018 at 7:25 PM, A.M. wrote: > 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. 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. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Building v8 as a static library generates build errors, but ptoduces usable libraries
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. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Building v8 as a static library generates build errors, but ptoduces usable libraries
On Sat, Apr 28, 2018 at 1:06 AM, A.M. wrote: > 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! 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. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[v8-users] Building v8 as a static library generates build errors, but ptoduces usable libraries
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! -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
