Building v8 shared library on windows

[Bad]

Hi

I've been trying to implement v8 in a project of mine for more than a month and a half.

It looks like I'm missing some step, as I've been able to obtain v8 header files, and .lib files, but I don't get how to build a DLL out of these.

If someone finds a spare minute to help me, it would be very helpfull.

My project is a c# project, but once I'll have the .dll I think I'll figure it out on my own,

Thank you

[Bill Ticehurst]

Are you building with MSVC or Clang? The "component" build of V8 has some issues with MSVC, but I believe should just work if using Clang.

Note: "component" build means a DLL build. Check that "is_component_build = true" in your output folder's args.gn file, and then you should see v8*.dll files in your output folder after the build.

[Bad_At_Life]

Sorry for the late answer.

I don't know if I'm building with clang or msvc. I'm following the guide.

Meanwhile I managed to build dll files, but I can't make them work in a VS2019 project because of two errors:

-the linker can't resolve external symbols for NewDefaultPlatform

-Even if I comment out the part that causes the first error, I get runtime entry point errors on icu18n.dll and v8.dll.

I'm getting quite desperate about this project.

[Ron Burk]

While you wait for someone *much* more knowledgeable to reply... :-)

I'm not brave enough to build on Windows, but presumably many things are similar.

> I'm following the guide.

More than one guide (or parts of guide) to follow! :-)  Maybe you followed this one: https://v8.dev/docs/embed

In which case, you built a directory like "v8/out.gn/x64.release" and that directory

would contain a file named "args.gn" and you could confirm that file contains a line

like "is_clang = true" to know that your build used clang.

Or if you followed the instructions here: https://v8.dev/docs/build-gn

then I guess you would find "args.gn" in something like "v8/out/x64.release"

> resolve external symbols for NewDefaultPlatform

That problem should be conquerable. A symbol I would expect to find

in the library built to contain the "libplatform" code from "v8/src/libplatform".

I would next see if there's a library with "libplatform" in the name and confirm

whether I've really successfully told the linker to look there. Or you could

resort to dumping all the symbols from all the DLLs you built and confirm

the missing symbol really does exist and where it is defined.

> I'm getting quite desperate about this project.

Many have trudged ahead of you and suffered the same, if it's any consolation :-).

[Nagendra Y]

OP should also take a look at this thread
https://groups.google.com/forum/#!topic/v8-users/Jb1VSouy2Z0

I'm facing the same linking issue on using v8 shared libs on CentOS 8

[Bad_At_Life]

Ok, wonderful

this is the content of my args.gn file:

is_debug = false

target_cpu = "x64"

is_component_build = true

in my out.gn/x64.release folder I have both "v8_libplatform.dll.lib" and "v8_libplatform.dll".

I'm posting a screenshot of the folder.

In my c++ solution I have these files in Properties > Linker > Input > Additional Dependencies:

- v8.dll.lib

- v8_libbase.dll.lib

- v8_libplatform.dll.lib

- icuuc.dll.lib

- icui18n.dll.lib

- libc++.dll.lib

Under Properties > Linker > General > Additional Library Directories

- the directory containing those 6 files above

Under Properties > C/C++ > General > Additional Include Directories

- the include directory containing the header files (posting also that screeshot)

Thank you, I do really appreciate your help.

If there is anything else I need to tell about my setup, I'll be glad to post.

Tomorrow (it's evening for me) I'll try compiling with "is_clang = true"

[Ron Burk]

> I'll try compiling with "is_clang = true"

Shouldn't hurt, although my suspicion is since you didn't override it, it defaulted to true, due to these lines from "build/config/BUILDCONFIG.gn":

  is_clang = current_os != "linux" ||
             (current_cpu != "s390x" && current_cpu != "s390" &&
              current_cpu != "ppc64" && current_cpu != "ppc" &&
              current_cpu != "mips" && current_cpu != "mips64")

You've passed up my meager knowledge, I've never used any but command-line tools on Windows.

If the linker really is searching your libplatform library, then that still leaves the possibility of a disagreement about name mangling. Seems most likely you built that library with V8's included clang (and a large number of command-line options that you would have to go poking around to discover). If the thing you're trying to link against these libraries isn't being built with the exact same tool/options, it's possible they disagree on how to write symbols that contain their function's signature. On Linux, even using the same exact clang on both sides, I had to add the rather obscure clang command-line option "-D_LIBCPP_ABI_VERSION=Cr" in order to get all the def/ref symbol names in agreement and eliminate the last of my "missing symbol" linker errors.

To not abandon hope, remember that if you can build/run the included sample executables, then it is somehow possible!

[Nagendra Y]

You can also try building , setting the gn argument

use_custom_libcxx_for_host = true

Argument overview:
Use libc++ instead of stdlibc++ when using the host_cpu toolchain, even if
use_custom_libcxx is false. This is useful for cross-compiles where a custom
toolchain for the target_cpu has been set as the default toolchain, but use_custom_libcxx should still be true when building for the host.

This issue is because of the libc++ mismatch during the linking process of clang. I fixed the exact same issue as yours on Linux, with this.

[Bad_At_Life]

Ok

I'm still going to compile with "is_clang = true", but I'll also add Nagendra's "use_custom_libcxx_for_host = true".

Don't expect me to disappear from this platform.

Thank you very much

[Bad_At_Life]

Nagendra, what do you mean with "using libc++ insead of stdlibc++ when using the host_cpu toolchain"?  I don't get it.

Right now I'll compile with "is_clang = true" and "use_custom_libcxx_for_host = true".

Thank you both.

[Stefan Wörthmüller]

Note that Microsoft also offers prebuild verrions of v8 via the package manager or direct to download.

I.e. https://www.nuget.org/packages/v8-v140-x64/ click on "Download" at the right and rename the archive to zip. Works well for me.

[Bill Ticehurst]

To be clear, NuGet is a Microsoft run package manager, but "Microsoft" doesn't offer any pre-built V8 binaries. A user account named "pmed" created/uploaded that package, not a Microsoft account.

If you are building V8 in a default manner with Clang as it appears, then you can't link it with a project you're building with the MSVC compiler. Those are two different compilers and C++ doesn't have a cross compiler stable ABI (especially if using "custom_libcxx", which means they are also using a different standard C++ library - V8 the Clang provided "libc++", and MSVC will use it's own).

If you build V8 with Clang, you'll should build your project with Clang too (ideally using the same build toolchain - i.e. by updating the BUILD.gn file to include a target for your project - the doc at https://v8.dev/docs/embed details the Process and Shell sample apps which build via BUILD.gn and you can follow as an example). If you do decide to build V8 with MSVC, then as mentioned previously, "component build" isn't working currently, and you'll need to static link everything together ("is_component_build = false"), resulting in a large binary, rather than several V8 DLLs and a small application exe).

 - Bill

[Stefan Wörthmüller]

The v8 libraries from nuget can be used well with VC2017. Thats all i know.

[Ivan Pizhenko]

Hi Bill, so what needs to be fixed to get DLL build (i.e. is_component_build=true) built successfully with MSVC compiler? 

I've recently run into the same linking issue with DLL build compiled using clang. And to say truth, it's weird that DLL build works only with clang. 

p.s. I cannot use prebuilt binaries from nuget and cannot use clang to build my app. Need to use strictly MSVC 2017.

- Ivan

[Bad_At_Life]

Ok Bill

Then I'll build it statically with "is_component_build = false". I don't really need them to be dynamic, I just need them to work.

What file extension should I look for? .lib?

Thank you

[Bill Ticehurst]

I'm not clear on what is needed to fix this. The bug has been open quite a while (see https://bugs.chromium.org/p/v8/issues/detail?id=8791).

[Bill Ticehurst]

I believe this is still mostly correct - (some filenames might be out of date, but should give you a general starting point). If you're already building V8 successfully with MSVC, you should be able to skip down to the "Embedding V8 into a custom application" part.

https://medium.com/angular-in-depth/how-to-build-v8-on-windows-and-not-go-mad-6347c69aacd4

Disclaimer: As should be obvious by now (and by the above post), this stuff is a moving target (e.g. changing compilers and build outputs over time), non-trivial, and not a first-class supported scenario. The "well trodden" and best supported path is to build your code via a new BUILD.gn target with Clang along with the rest of V8, that way you can ensure your compiler and build settings are all consistent, and the dependencies are largely managed for you. Good luck!

 - Bill

[Ivan Pizhenko]

That’s clear, the instruction under the link suggests to build V8 as static library, which we already know to be working. But the point was to build and use V8 as DLL. Meanwhile, I’ve found following workaround: add 2 new custom functions to the libplatform, the first one returns normal pointer extracted from return value of the NewDefaultPlatform() and second to delete v8::Platform object (this is to ensure we use both new and delete from libc++), and export these functions from DLL. This way I’ve gotten rid of dependency on the std::unique_ptr version coming from libc++. And based on this experience I’d generally suggest to V8 developers to keep all public V8 APIs w/o any STL stuff for the sake of better integration with different compilers, which with very high probability have different STL implementations than libc++.

- Ivan

--
--
v8-users mailing list
v8-u...@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+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/554c96a8-82e1-4a6d-86c7-2a65d51c5797%40googlegroups.com.

 

[Ben Ernst]

Thank you for sharing that workaround Ivan, I believe I'm hitting the same problem, and your workaround might help me.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-u...@googlegroups.com.

[ClearScript Developers]

Unfortunately this issue transcends export naming. V8 seems to be embracing STL data types all over its API.

By sheer luck std::unique_ptr is likely to work across STL implementations (at least when used without a stateful deleter), but other data types aren't so lucky. V8 already has a bunch of APIs that pass or return std::shared_ptr, and that's pretty much guaranteed to fail.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-u...@googlegroups.com.

[Bill Ticehurst]

Just the header file for the public V8 API (https://chromium.googlesource.com/v8/v8.git/+/refs/heads/master/include/v8.h#18) includes <memory>, <string>, <type_traits>, <utility>, and <vector> from the C++ standard library. I'm unclear what they are all needed for, but I think it's safe to say mixing C++ standard libraries when building and consuming V8 is always going to be high risk, unsupported, and if you do manage to get it working today - very fragile going forward.

 - Bill

[Bill Ticehurst]

FWIW: I played around with the last night for a couple hours and got a release build working using a "component build" and MSVC. It was mostly moving some inline functions and adding some V8_EXPORT_PRIVATE statements (which effectively add the "__declspec(dllexport)" statements to expose functions across DLLs with MSVC). You can see the changes over the current V8 v8.0 branch at https://github.com/v8/v8/compare/8.0-lkgr...billti:v8.0-msvc-fixes?expand=1

This is very rough code, hacking away at one build break at a time until it worked. I'll need to clean it up with a consistent approach before it would be ready for a CL. It also only works for the product binaries & D8 so far (i.e. build with "ninja -C out.gn\x64.release d8"), so I need to fix up the failures when building the test code (which means figuring out some of the subtlety in https://github.com/v8/v8/blob/master/src/base/export-template.h ).

Bottom line: It seems fixable without major changes, and should be very low risk (as the V8_EXPORT_* macros effectively compile to nothing in static builds - which is what Chromium and Node.js use for release).

 - Bill

[Ivan Pizhenko]

Yes, that’s true. But fortunately, I don’t use all that stuff that has STL classes in the interface, except libplatform, so works for me, and may work for someone else.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/c64e6796-74f7-4bbd-9701-750632714cd7%40googlegroups.com.

 

[Ivan Pizhenko]

Oh, that’s great. Thank you. I will try to apply similar patch locally to the 7.8.279.23, since I am allowed to use only “stable” versions of V8.

- Ivan

 

 

From: 'Bill Ticehurst' via v8-users
Sent: Friday, December 20, 2019 20:02
To: v8-users
Subject: [v8-users] Re: Building v8 shared library on windows

 

FWIW: I played around with the last night for a couple hours and got a release build working using a "component build" and MSVC. It was mostly moving some inline functions and adding some V8_EXPORT_PRIVATE statements (which effectively add the "__declspec(dllexport)" statements to expose functions across DLLs with MSVC). You can see the changes over the current V8 v8.0 branch at https://github.com/v8/v8/compare/8.0-lkgr...billti:v8.0-msvc-fixes?expand=1

--

--
v8-users mailing list
v8-u...@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+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/a0a7c08b-7ff7-40cf-9104-021a97912018%40googlegroups.com.

 

[Bad_At_Life]

There are a couple of things I don't understand:

-How can I use V8 with VS2019, if working DLLs can't be obtained?

-Will the MSVC way ever be fixed?

I cannot use precompiled DLLs if I don't know if I will be able to update them to a newer version of V8, that wouldn't be sustainable.

Thank you very much, everybody

[Bill Ticehurst]

I spent a little more time on this and pushed another commit to my fork of the 8.0 branch (see comparison with upstream 8.0 at https://github.com/v8/v8/compare/8.0-lkgr...billti:v8.0-msvc-fixes?expand=1). 

The tests now compile and pass with MSVC too now. For those following along, this was how I ran the build/test.

From the root folder, run the below to generate a x64 release build using MSVC and building DLLs (assuming you're on Windows, obviously)

  python tools\dev\v8gen.py -b x64.release msvc -- is_clang=false is_component_build=true

Run the build, which should complete without error:

  ninja -C out.gn/msvc

If you want to run the tests for good measure:

  python tools/run-tests.py --outdir out.gn/msvc

You should find the resulting v8.dll, along with supporting dlls and .lib files, in the .\out.gn\msvc directory.

I haven't tested much beyond running the tests and doing a few ad-hoc D8 experiments, and obviously this is unsupported/untested upstream (where the are no bots building/testing/fuzzing this configuration).

I'll tidy this up, open a CL, and see if this is something we can get upstreamed, as several folks seem to want this option. Assuming V8/Google doesn't want to run bots for this configuration but is happy to take fixes, is would then be beholden on us (the V8 community) to keep it working. (Personally, it seems to me like the only long-term sustainable solution for cross-compiler support is a C-based API, similar to N-API for Node.js, but I doubt there's much appetite for this currently).

 - Bill

To unsubscribe from this group and stop receiving emails from it, send an email to v8-u...@googlegroups.com.

[Ben Ernst]

Bill,

Just wanted to say your work is appreciated. Anything interested parties can do to help keep msvc builds working? Willing to learn new skills to contribute, but could use pointing in a good direction.

Ben

To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/fa4f75c9-4ef9-4eb7-9cbf-511c9f0dc4a3%40googlegroups.com.

[Ivan Pizhenko]

Still can’t get it working. Note - I am trying to compile v8 7.8.279.23

 

For example:

 

[105/1253] L:/depot_tools/bootstrap-3_8_0b1_chromium_1_bin/python/bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./bytecode_builtins_list_generator.exe /PDB:./bytecode_builtins_list_generator.exe.pdb @./bytecode_builtins_list_generator.exe.rsp

FAILED: bytecode_builtins_list_generator.exe bytecode_builtins_list_generator.exe.pdb

L:/depot_tools/bootstrap-3_8_0b1_chromium_1_bin/python/bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./bytecode_builtins_list_generator.exe /PDB:./bytecode_builtins_list_generator.exe.pdb @./bytecode_builtins_list_generator.exe.rsp

generate-bytecodes-builtins-list.obj : error LNK2019: unresolved external symbol "public: static void __cdecl v8::internal::Internals::CheckInitializedImpl(class v8::Isolate *)" (?CheckInitializedImpl@Internals@internal@v8@@SAXPEAVIsolate@3@@Z) referenced in function "public: static void __cdecl v8::internal::Internals::CheckInitialized(class v8::Isolate *)" (?CheckInitialized@Internals@internal@v8@@SAXPEAVIsolate@3@@Z)

 

and many more of that.

 

Seems like such unresolved functions are located in the source code files that were not compiled.

 

For example:

 

bytecode-operands.obj : error LNK2001: unresolved external symbol "private: static void __cdecl v8::Int32::CheckCast(class v8::Value *)" (?CheckCast@Int32@v8@@CAXPEAVValue@2@@Z)

 

This one is located in the v8/src/api/api.cc

 

But when I am checking my v8\out.gn.windows\x64.debug\.ninja.log api.obj is not mentioned there.

 

Is these some missing dependency in the build files?

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CY4PR10MB2023C7A740F804FB0D5648D0FF2D0%40CY4PR10MB2023.namprd10.prod.outlook.com.

 

[Bill Ticehurst]

Being that this wouldn't be a "high priority" issue, the chance of getting it back-ported to older shipped branches is probably low. Sorry for those of you stuck on older builds. (Good news is, with v8 shipping every 6 weeks, you don't have to wait long until 'master' becomes 'legacy' :-)  ).

I actually managed to simplify the changes somewhat by just suppressing a harmless MSVC warning that was being treated as an error. I've opened a CL against the tip of master at https://chromium-review.googlesource.com/c/v8/v8/+/1996157 . With this change you should be able to build a release DLL of V8 with MSVC.

There was one linker error in the tests unfortunately I couldn't fix (yet) without breaking other platforms, so I had to comment that test out for MSVC DLL builds. I'll take another crack at it later. Debug builds of DLLs also have further issues on MSVC I haven't tackled yet.

 - Bill

[Ben Ernst]

Following with interest.

Ben

To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/e738b2fd-3d7e-4684-8f45-9642b8e2c221%40googlegroups.com.

[Bill Ticehurst]

I got the fix merged. Any by the time I sync'ed to master a built, it was broken again already :-(  This will likely be a pain to maintain.

The additional fix (https://chromium-review.googlesource.com/c/v8/v8/+/2005528) has now also been merged. (The V8 core team are really very good at prompt code reviews and a pleasure to work with).

Please grab it and test it while it works. I'll try and build it on a regular basis to keep things humming along.

To clarify: Release STATIC builds with MSVC work and usually do (Node.js relies on these, and they are part of the V8 CI tests). This change fixes Release DLL (or "component" in V8 parlance) builds. Debug DLL builds still have issues, but that's a much bigger problem I'll look into as I have time.

FYI: Below are the contents of my args.gn to build Release DLLs with MSVC. Good luck! 

 - Bill

is_debug = false
target_cpu = "x64"

is_clang=false
is_component_build=true

On Monday, January 13, 2020 at 2:54:11 PM UTC-8, Ben Ernst wrote:

Following with interest.

Ben

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/e738b2fd-3d7e-4684-8f45-9642b8e2c221%40googlegroups.com.

[Bill Ticehurst]

Unless we add a bot for the MSVC component release build, I think I'm going to give up on this. It just breaks too regularly.

I just got a fixed merged for an issue if you're just building the product binaries (see https://chromium-review.googlesource.com/c/v8/v8/+/2124886 ). I then went to do a full build, and there's a couple more breaks due to unresolved external symbols:

js-call-reducer-unittest.obj and redundancy-elimination-unittest.obj both fail due to:

  unresolved external symbol "__declspec(dllimport) public: static class v8::internal::Handle<class v8::internal::FeedbackMetadata> __cdecl v8::internal::FeedbackMetadata::New<class v8::internal::Isolate>(class v8::internal::Isolate *,class v8::internal::FeedbackVectorSpec const *)"

This appears to be due to changes in src/objects/feedback-vector.{h,cc} merged in March as part of https://chromium-review.googlesource.com/c/v8/v8/+/2066965

node-cache-unittest.obj has multiple failures related to "v8::internal::compiler::NodeCache". This appears to be due to https://chromium-review.googlesource.com/c/v8/v8/+/2087405 also merged in March which contains changes to src/compiler/node-cache.{h,cc} that removed the explicit template instantiation declarations/definitions of NodeCache<int32_t> and NodeCache<int64_t>.

Both those change lists were written and reviewed by some of the best V8 devs there are, and still broken MSVC component release builds. Trying to keep this configuration working without a bot is a losing battle.

 - Bill

[Himanshu Bansla]

Seems like MSVC component Release build is broken again. Anyone looking at this ?

Thanks,
Himanshu

[Jackzenko]

Im having same trouble here with VS2022 + v8 9.9

I copied the code from v8\samples\hello-world.cc

calling v8::platform::NewDefaultPlatform() generates unresolved external symbol error

however for the first two lines of hello-world.cc it calls v8.dll.lib works perfectly fine.

i commented out platform related code, then it can be compiled but it has runtime exception due to platform is not correctly initialized.

the problem only happens with v8_libplatform.dll.lib even it is located in same folder has same path as other libs.

seems VS2019 works fine? problem only happens with VS2022?

following is the error message:

Error    LNK2001    unresolved external symbol "class std::unique_ptr<class v8::Platform,struct std::default_delete<class v8::Platform> > __cdecl v8::platform::NewDefaultPlatform(int,enum v8::platform::IdleTaskSupport,enum v8::platform::InProcessStackDumping,class std::unique_ptr<class v8::TracingController,struct std::default_delete<class v8::TracingController> >)" (?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)    v8RunJS    C:\Data\Code\v8RunJS\v8RunJS\main.obj    1

Can someone please help?

[LAGUNA DU]

I've got the same issues.

After I build on below args.gn, I got error building my projects.

error LNK2019: unresolved external symbol "class std::unique_ptr<class v8::Platform,struct std::default_delete<class v8::Platform> > __cdecl v8::platform::NewDefaultPlatform(int,enum v8::platform::IdleTaskSupport,enum v8::platform::InProcessStackDumping,class std::unique_ptr<class v8::TracingController,struct std::default_delete<class v8::TracingController> >)" (?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) referenced in function main

```

is_component_build = true

is_debug = false
target_cpu = "x64"

use_goma = false
v8_enable_backtrace = true
v8_enable_disassembler = true
v8_enable_object_print = true
v8_enable_verify_heap = true
dcheck_always_on = false

```

and if I don't wanna use clang , I even can't build v8.dll successfully.

'void std::vector<std::unique_ptr<cppgc::CustomSpaceBase,std::default_delete<cppgc::CustomSpaceBase>>,std::allocator<std::unique_ptr<cppgc::CustomSpaceBase,std::default_delete<cppgc::CustomSpaceBase>>>>::assign<std::unique_ptr<cppgc::CustomSpaceBase,std::default_delete<cppgc::CustomSpaceBase>>*,0>(_Iter,_Iter)'
        with
        [
            _Iter=std::unique_ptr<cppgc::CustomSpaceBase,std::default_delete<cppgc::CustomSpaceBase>> *
        ]

```

is_component_build = true

is_debug = false
target_cpu = "x64"

use_goma = false
v8_enable_backtrace = true
v8_enable_disassembler = true
v8_enable_object_print = true
v8_enable_verify_heap = true
dcheck_always_on = false

is_clang = false

```

There muse be a solution, because my win10-chrome is working fine, but I couldn't figure it out.

jack...@gmail.com 在 2022年6月15日 星期三上午11:45:54 [UTC+8] 的信中寫道：