Building a c++ dll with visual studio 2022 v17.7.2

copied the (release) redist and dll into where they're meant to to run from as the dll is a plugin for another program.

On running, the executed javascript runs absolutely fine, but when cleaning up the V8 resources, I get this:

A breakpoint instruction (__debugbreak() statement or a similar call) was executed in notepad++.exe.

call stack looks like this:

	v8_libbase.dll!00007ffa957fbbe0()	Unknown
 	v8.dll!00007ffa54e1dd9b()	Unknown
>	JSLintNpp.dll!JSLint::CheckScript(const std::string & strOptions, const std::string & strScript, int nppTabWidth, int jsLintTabWidth, std::list<JSLintReportItem,std::allocator<JSLintReportItem>> & items) Line 233	C++
 	JSLintNpp.dll!doJSLint() Line 373	C++
 	JSLintNpp.dll!jsLintCurrentFile() Line 168	C++

the IDE shows that the code is stopped at

    isolate->Dispose();
    v8::V8::Dispose(); <------HERE

python build.py
.....

• branch 555c8b467c21e2c4b22d00e87e3faa0431df9ac2 -> FETCH_HEAD
  Reset branch 'Branch_555c8b467c21e2c4b22d00e87e3faa0431df9ac2'
  Traceback (most recent call last):
  File ".\build.py", line 196, in
  vs_install_dir = os.path.abspath(os.path.join(os.environ['VCINSTALLDIR'], os.pardir))
  File "C:\Python27\lib\os.py", line 425, in getitem
  return self.data[key.upper()]
  KeyError: 'VCINSTALLDIR'
  PS D:\ghprj\v8-nuget>

So im trying to compile an example using v8pp.
Im following this https://explorerplusplus.com/blog/2019/03/07/embedding-v8-c++-application
So after passing through the compile-time errors im getting this one that i dont know how to fix...
Here is the fork with my current local clone and the example which im trying to run
https://github.com/Vasika-uso/v8-nuget-build

Other details:
OS : Windows 10 Pro
Version: 10.0.19043 gen 19043
Type: x64 system
Compiler: MSVC , Visual Studio 2022

latest C++ Redistributable
Microsoft Visual C++ 2015-2022 Redistributable (x64) - 14.32.31332
Microsoft Visual C++ 2015-2022 Redistributable (x86) - 14.32.31332
packages v8.redist-v142-x86.7.5.288.23 && v8-v142-x86.7.5.288.23
...

hello.

Could you be able to share a args.gn file that would produce static libraries and not be monolithic.

my current args.gn
args.txt

Getting undefined reference errors for the functions.

best regards.
Nihal

I have installed v8-v140-x64 (v5.9.211.28) into Visual Studio 2017 using the in-built NuGet Package Manager. The doco says "All necessary files (*.lib, *.dll, *.pdb) should be referenced in the project automatically with MsBuild property sheets.", but I had to add the Additional Include Directories, Additional Library Directories and Linker Additional Dependencies manually.

I can see that the .props files exist, and there are no errors in the Package Manager Output window.

When I ask for detailed logging of the build, the only reference to .props files is:

Task "Error" skipped, due to false condition; (!Exists('packages\v8.redist-v140-x64.5.9.211.28\build\native\v8.redist-v140-x64.props')) was evaluated as (!Exists('packages\v8.redist-v140-x64.5.9.211.28\build\native\v8.redist-v140-x64.props')).
Task "Error" skipped, due to false condition; (!Exists('packages\v8-v140-x64.5.9.211.28\build\native\v8-v140-x64.props')) was evaluated as (!Exists('packages\v8-v140-x64.5.9.211.28\build\native\v8-v140-x64.props')).

which I don't know whether is positive or negative.

Did I do something wrong, or does it not work with Visual Studio 2017?

I've had a request to merge in changes to plv8 to allow for easier msvc compilation - this relies on nuget (see plv8/plv8#239).

I'm hesitant to do this until v8-nuget is updated to 6.4.388.14 or above, since this is the version that mitigates spectre and meltdown (see: https://chromium-review.googlesource.com/c/v8/v8/+/848921 and v8/v8@a060a4f), and plv8 is currently patched to above this version.

plv8 is also pegged to the version that node is using: 6.4.388.40, but I'm ok with a minor difference as long as it's at 6.4.388.14 or above.

any chance of getting this updated?

thanks!

Looks like windows x64/x86 fails to build on latest and 11.9.169.4. Tested via github workflow and manual build. Seems like an linker error with abseil.

build_log.txt

Win10 has iccuc.dll at system32 , it won't work in many situations because loading system32/iccuc.dll first.
Can this project consider different dll name or version name iccuc.dll like iccuc230.dll?

Everything works fine at compile time, but there are two scenarios that require some tweaking in the project created:

No snapshot option

There could be an option/way to disable the snapshot use.

Snapshot option

If using snapshot (Which is by default), you have to move the working directory of the project, which is the project's one.

Any idea if this can be fixed out of the box without having to modify the solution debug options?

~Regards

Hi~
I have received your v8(10.0.139.9) NugetPackage for vs2022.
There is v8_build_config.json file in the package. I built v8 with it and made v8.dll, v8_libbase.dll, and so on.
But, When I compiled my MFC project with v8.dll made by me, link error took place. The error message is "error LNK2019: "class std::unique_ptr<class v8::Platform,struct std::default_delete > __cdecl v8::platform::NewDefaultPlatform(int,enum v8::platform::IdleTaskSupport,enum v8::platform::InProcessStackDumping,class std::unique_ptr<class v8::TracingController,struct std::default_delete >)" (?NewDefaultPlatform@platform@v8@@ya?AV?$unique_ptr@VPlatform@v8@@U?$default_delete@VPlatform@v8@@@std@@@std@@HW4IdleTaskSupport@12@W4InProcessStackDumping@12@V?$unique_ptr@VTracingController@v8@@U?$default_delete@VTracingController@v8@@@std@@@4@@z)""
By the way, your v8.dll is linked with my project normally. It would be greatly appreciated if you could tell me what environment you compiled into.

Assuming depot_tools is a prerequisite (not mentioned in README.md - installed separately), the build process does not work out of the box. These are the known missing things:

set VisualStudioVersion=15.0
#need to set vc install dir
...

Also can you upload the pdb files to nuget?

I would like to use this package in a project that must support Windows XP. Since Visual Studio 2012 and up have a different version for XP, it would be nice if these packages worked with that toolset as well.

When attempting to extend the console of v8 I have found that v8::debug::ConsoleDelegate is missing from the header files. However by digging around in the pdb files (v8.symbols-v142-x64.7.5.288.23\lib\Debug\v8.dll.pdb), this data does indeed exist, it just isn't in the header. Is there a way to access these classes and functions?

Hello
Could you help please with next issue:
Under Win7 x64, VS2015, Python27
Tryed VCINSTALLDIR
this 'c:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/'
and 'c:/Program Files (x86)/Microsoft Visual Studio 14.0/'
And got the same errors on build.py - https://puu.sh/zX00i/7cd26bd53a.png

I would be grateful for your help

How to get V8 Static Library ?
At present seems to be DLL

Just installed v8-v140_xp-x64 in my project, didn't change any project settings, and now get the above error on build.

• MSVS Community 2015 u3
• Win10 Pro

I can't help but notice that the nuget packages you have published do not come with pdb files, nor can I find any reference to such file on the commonly known debug symbol distribution sites for nuget packages.

I have been using 6.8.275.2 (which someone should really update - current release branch is at least 6.8.275.26.

If there is an older release that includes pdb files, please point me to that, willing to go all the way back to 6.1 to resolve my issue.

I installed v8-142-x64 via the package manager in Visual Studio 2019.
My project dll builds fine, but when I try to load my dll (windows 10), i get:

The entry point it can't find is in the icuuc.dll, but the v8.dll does not appear to import it.

I have two alternative configurations apart from the typical Debug and Release. They are named "Debug DLL" and "Release DLL" and failed to link throwing a "cannot open input file v8.dll.lib" error.

If I duplicate the folders inside "\packages\v8-$PlatformToolset-$Platform.$Version\lib" and name them "Debug DLL" and "Release DLL" it works like a charm.

C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\include\xutility(4036): error C2280: 'std::unique_ptr<cppgc::CustomSpaceBase,std::default_deletecppgc::CustomSpaceBase> &std::unique_ptr<cppgc::CustomSpaceBase,std::default_deletecppgc::CustomSpaceBase>::operator =(const std::unique_ptr<cppgc::CustomSpaceBase,std::default_deletecppgc::CustomSpaceBase> &)'

first of all, thank you for your contribution. that error occurs when 'is_clang' arg is false. could you let me know how to solve that error?

See //build/config/BUILDCONFIG.gn:570:9: which caused the file to be included.
[ "//build/config/win:default_cygprofile_instrumentation" ]
^------------------------------------------------------
Traceback (most recent call last):

File "C:/src/v8-nuget/v8/build/compute_build_timestamp.py", line 120, in <module>

  sys.exit(main())

File "C:/src/v8-nuget/v8/build/compute_build_timestamp.py", line 104, in main

  last_commit_timestamp = int(open(lastchange_file).read())

IOError: [Errno 2] No such file or directory: 'C:\src\v8-nuget\v8\build\util\LASTCHANGE.committime'

i have been using your nuget package... i am looking for a no snapshot build, and also a build that does not require dll to be present.. i want to be able to include v8 static libs into my project and have it produce a single exe or dll without the external deps within the dir

I'm getting this error after running build.py (without any parameter)

Fetch https://chromium.googlesource.com/external/github.com/google/protobuf@b68a347f56137b4b1a746e8c7438495a6ac1bd91@HEAD into v8/third_party/protobuf
fatal: remote error: Git repository not found
RETRY: v8/third_party/protobuf
Initialized empty Git repository in F:/ISAE/R109/Javascript/v8nuget/v8-nuget/v8/third_party/protobuf/.git/
fatal: remote error: Git repository not found
Traceback (most recent call last):
File "build.py", line 89, in
git_fetch(deps[dep], dep)
File "build.py", line 63, in git_fetch
subprocess.check_call(fetch_args, cwd=target)
File "F:\ISAE\R109\Javascript\depot_tools\bootstrap-3_8_0b1_chromium_1_bin\python\bin\lib\subprocess.py", line 186, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['git', 'fetch', '--depth=1', '--update-shallow', '--update-head-ok', '--quiet', 'https://chromium.googlesource.com/external/github.com/google/protobuf@b68a347f56137b4b1a746e8c7438495a6ac1bd91', 'HEAD']' returned non-zero exit status 128

I think the difference is that as of today, inside the DEPS file of v8, protobuf URL is defined as:

'v8/third_party/protobuf':
Var('chromium_url') + '/external/github.com/google/protobuf'+ '@' + 'b68a347f56137b4b1a746e8c7438495a6ac1bd91',

the git_fetch() function inside build.py is splitting the URL by '.git@'
But since there is no ".git" in the DEPS' protobuf URL, the parsing becomes incorrect.

As a workaround, I added special handling for protobuf:
# ray: special handling for protobuf
if target != 'v8/third_party/protobuf':
parts = url.split('.git@')
else:
parts = url.split('@')

Please clarify whether this is my environment problem.
Because after applying the workaround, I still get another error further down the road:
-> This time for fetching android_ndk
KeyError: 'VCINSTALLDIR'
I have Visual C++ 2017 installed. Although I have VS2013 also in this machine.
As a workaround, i temporarily modified this line in build.py
from "14.0" to "15.0"

vs_version = vs_versions[os.environ.get('VisualStudioVersion', '15.0')]

I also hardcoded my VS path to this:

vs_install_dir = 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional'
because I don't have "VCINSTALLDIR" Environment variable.

Finally, it proceeded to the Ninja build process. But that too failed

ninja: build stopped: subcommand failed.
Traceback (most recent call last):
File "build.py", line 167, in
subprocess.check_call([NINJA, '-C', out_dir, 'v8'], cwd='v8', env=env)
File "F:\ISAE\R109\Javascript\depot_tools\bootstrap-3_8_0b1_chromium_1_bin\python\bin\lib\subprocess.py", line 186, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['F:\ISAE\R109\Javascript\v8nuget\v8-nuget\bin\ninja.exe', '-C', 'out.gn\lkgr\v141\x86\Debug', 'v8']' returned non-zero exit status 1

For this last error, I saw there are Link Errors above:
FAILED: bytecode_builtins_list_generator.exe bytecode_builtins_list_generator.exe.pdb

Followed by ~100 instances of errors like this:

bytecode-operands.obj : error LNK2001: unresolved external symbol "public: static void __cdecl v8::internal::Internals::CheckInitializedImpl(class v8::Isolate *)" (?CheckInitializedImpl@Internals@internal@v8@@SAXPAVIsolate@3@@Z)

I currently don't have a workaround or solution to this link error.
I already tried using the VS Developer Command prompt to run build.py.
So I would appreciate any help.

Hi,

Ae you going to provide the package build with CVE-2022-1096 fix?

Thanks,
Vladimir

Is possible to have a monolith version of v8 without dependencies with vcredist? (With runtime /MT)

Hi,
i'm not able to build using VS2017 or VS2019. I tried with your last provided version vom V8 - but i get build errors:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.16.27023\include\type_traits(616): error C2139: "v8::internal::Cell": Eine nicht definierte Klasse ist nicht als Argument f�r die systeminterne Typeigenschaft "__is_convertible_to" des Compilers zul„ssig. D:\data\XXX_FSCCache\Build_v8\_work\v8\out.gn\library_monolithic\gen\torque-generated/internal-class-definitions.h(81): note: Siehe Deklaration von "v8::internal::Cell" D:\data\XXX_FSCCache\Build_v8\_work\v8\src/codegen/tnode.h(267): note: Siehe Verweis auf die Klasse Vorlage-Instanziierung "std::is_convertible<T,v8::internal::Object>", die kompiliert wird. with [ T=v8::internal::Cell ] D:\data\XXX_FSCCache\Build_v8\_work\v8\src/codegen/code-stub-assembler.h(1619): note: Siehe Verweis auf die Klasse Vorlage-Instanziierung "v8::internal::is_subtype<v8::internal::Cell,v8::internal::Cell>", die kompiliert wird. D:\data\XXX_FSCCache\Build_v8\_work\v8\src/objects/objects.h(275): note: Siehe Verweis auf die Klasse Vorlage-Instanziierung "v8::internal::TaggedImpl<v8::internal::HeapObjectReferenceType::STRONG,v8::internal::Address>", die kompiliert wird.

Any idea/help what is wrong in my environment?

Inconsistent symbol lists between lib and dll files...
The symbols in the include folder and lib files are consistent, but they are inconsistent with the symbol table in the dll.

The relevant API file is v8-exception.h.

If you use the include files which in the package, you can compile successfully, but errors occur during execution. If you use the newer version of v8-exception.h file, problems occur during the linking phase.

The relevant function in the dll is: public: static class v8::Local<class v8::Value> __cdecl v8::Exception::TypeError(class v8::Local<class v8::String>,class v8::Local<class v8::Value>)

// Old version:
class V8_EXPORT Exception {
 public:
  static Local<Value> RangeError(Local<String> message);
  static Local<Value> ReferenceError(Local<String> message);
  static Local<Value> SyntaxError(Local<String> message);
  static Local<Value> TypeError(Local<String> message);
  static Local<Value> WasmCompileError(Local<String> message);
  static Local<Value> WasmLinkError(Local<String> message);
  static Local<Value> WasmRuntimeError(Local<String> message);
  static Local<Value> Error(Local<String> message);

  /**
   * Creates an error message for the given exception.
   * Will try to reconstruct the original stack trace from the exception value,
   * or capture the current stack trace if not available.
   */
  static Local<Message> CreateMessage(Isolate* isolate, Local<Value> exception);

  /**
   * Returns the original stack trace that was captured at the creation time
   * of a given exception, or an empty handle if not available.
   */
  static Local<StackTrace> GetStackTrace(Local<Value> exception);
};

// New version:

class V8_EXPORT Exception {
 public:
  static Local<Value> RangeError(Local<String> message,
                                 Local<Value> options = {});
  static Local<Value> ReferenceError(Local<String> message,
                                     Local<Value> options = {});
  static Local<Value> SyntaxError(Local<String> message,
                                  Local<Value> options = {});
  static Local<Value> TypeError(Local<String> message,
                                Local<Value> options = {});
  static Local<Value> WasmCompileError(Local<String> message,
                                       Local<Value> options = {});
  static Local<Value> WasmLinkError(Local<String> message,
                                    Local<Value> options = {});
  static Local<Value> WasmRuntimeError(Local<String> message,
                                       Local<Value> options = {});
  static Local<Value> Error(Local<String> message, Local<Value> options = {});

  /**
   * Creates an error message for the given exception.
   * Will try to reconstruct the original stack trace from the exception value,
   * or capture the current stack trace if not available.
   */
  static Local<Message> CreateMessage(Isolate* isolate, Local<Value> exception);

  /**
   * Returns the original stack trace that was captured at the creation time
   * of a given exception, or an empty handle if not available.
   */
  static Local<StackTrace> GetStackTrace(Local<Value> exception);
};

The affected NuGet version is: https://globalcdn.nuget.org/packages/v8-v143-x64.11.8.172.15.nupkg

@pmed Did you ever build the 7.2-lkgr and/or lkgr (7.3) branches recently? I am getting segfaults when running the unittests.exe for these branches.

Some documentation and tests are here:
https://github.com/Jan-E/v8
Take a look at the screenshots of debug sessions in VS2017.

See the Appveyor builds as well
https://ci.appveyor.com/project/Jan-E/v8/history

Appveyor only runs the tests. I had to do the actual building locally (install.bat and build.bat) to circumvent the Appveyor time limits.

Even the 'successfull' builds contain the segfaults. I suppressed the errors to make sure the artifacts are available. When running a unittests.exe in one of those artifacts you can reproduce the segfaults yourself.

In the folder, only those files are available, no v8.lib, why? We need it when linking to v8 in our project.

03/24/2019 07:10 PM 10,326,064 icudtl.dat
03/24/2019 07:10 PM 1,674,752 icui18n.dll
03/24/2019 07:10 PM 1,111,552 icuuc.dll
03/24/2019 07:10 PM 2,995 natives_blob.bin
03/24/2019 07:10 PM 247,264 snapshot_blob.bin
03/24/2019 07:10 PM 12,392,448 v8.dll
03/24/2019 07:10 PM 117,248 v8_libbase.dll
03/24/2019 07:10 PM 65,536 v8_libplatform.dll