Re: [v8-users] Re: Building v8 shared library on windows
oken MSVC component release builds. Trying to >>> keep this configuration working without a bot is a losing battle. >>> >>> - Bill >>> >>> >>> On Friday, January 17, 2020 at 8:50:48 AM UTC-8, Bill Ticehurst wrote: >>>> >>>> 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 >>>>> >>>>> >>>>> On Sat, 11 Jan 2020 at 19:26, Bill Ticehurst >>>>> wrote: >>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> On Saturday, December 21, 2019 at 3:19:42 PM UTC-8, Bill Ticehurst >>>>>> wrote: >>>>>>> >>>>>>> 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 <http://out.gn/msvc>* >>>>>>> >>>>>>> If you want to run the tests for good meas
Re: [v8-users] Re: Building v8 shared library on windows
t;> >>>>> 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 >>>>> >>>>> >>>>> On Saturday, December 21, 2019 at 3:19:42 PM UTC-8, Bill Ticehurst >>>>> wrote: >>>>>> >>>>>> 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 <http://out.gn/msvc>* >>>>>> >>>>>> If you want to run the tests for good measure: >>>>>> >>>>>> * python tools/run-tests.py --outdir out.gn/msvc >>>>>> <http://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 >>>>>> >>>>>> >>>>>> On Friday, December 20, 2019 at 10:29:07 AM UTC-8, Ivan Pizhenko >>>>>> wrote: >>>>>>> >>>>>>> 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:
Re: [v8-users] Re: Building v8 shared library on windows
> 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 >>>>> >>>>> >>>>> On Saturday, December 21, 2019 at 3:19:42 PM UTC-8, Bill Ticehurst >>>>> wrote: >>>>>> >>>>>> 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 <http://out.gn/msvc>* >>>>>> >>>>>> If you want to run the tests for good measure: >>>>>> >>>>>> * python tools/run-tests.py --outdir out.gn/msvc >>>>>> <http://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 >>>>>> >>>>>> >>>>>> On Friday, December 20, 2019 at 10:29:07 AM UTC-8, Ivan Pizhenko >>>>>> wrote: >>>>>>> >>>>>>> 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 >>>>>
Re: [v8-users] Re: Building v8 shared library on windows
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 <http://out.gn/msvc>* >>>>> >>>>> If you want to run the tests for good measure: >>>>> >>>>> * python tools/run-tests.py --outdir out.gn/msvc <http://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 >>>>> >>>>> >>>>> On Friday, December 20, 2019 at 10:29:07 AM UTC-8, Ivan Pizhenko wrote: >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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 noth
Re: [v8-users] Re: Building v8 shared library on windows
t;> >>>> * ninja -C out.gn/msvc <http://out.gn/msvc>* >>>> >>>> If you want to run the tests for good measure: >>>> >>>> * python tools/run-tests.py --outdir out.gn/msvc <http://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 >>>> >>>> >>>> On Friday, December 20, 2019 at 10:29:07 AM UTC-8, Ivan Pizhenko wrote: >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> 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 >>>>> >>>>> On Wednesday, December 18, 2019 at 10:06:42 AM UTC-8, Bill Ticehurst >>>>> wrote: >>>>> >>>>> 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). >>>>> >>>>> On Tuesday, December 17, 2019 at 12:44:14 PM UTC-8, Ivan Pizhenko >>>>> wrote: >>>>> >>>>> 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. >>>>
Re: [v8-users] Re: Building v8 shared library on windows
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 > > > On Sat, 11 Jan 2020 at 19:26, Bill Ticehurst > wrote: > >> 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 >> >> >> On Saturday, December 21, 2019 at 3:19:42 PM UTC-8, Bill Ticehurst wrote: >>> >>> 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 <http://out.gn/msvc>* >>> >>> If you want to run the tests for good measure: >>> >>> * python tools/run-tests.py --outdir out.gn/msvc <http://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 >>> >>> >>> On Friday, December 20, 2019 at 10:29:07 AM UTC-8, Ivan Pizhenko wrote: >>>> >>>> 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 &
Re: [v8-users] Re: Building v8 shared library on windows
Following with interest. Ben On Sat, 11 Jan 2020 at 19:26, Bill Ticehurst wrote: > 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 > > > On Saturday, December 21, 2019 at 3:19:42 PM UTC-8, Bill Ticehurst wrote: >> >> 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 <http://out.gn/msvc>* >> >> If you want to run the tests for good measure: >> >> * python tools/run-tests.py --outdir out.gn/msvc <http://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 >> >> >> On Friday, December 20, 2019 at 10:29:07 AM UTC-8, Ivan Pizhenko wrote: >>> >>> 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 >>> >>> >>> >>> 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 fixabl
Re: [v8-users] Re: Building v8 shared library on windows
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 On Saturday, December 21, 2019 at 3:19:42 PM UTC-8, Bill Ticehurst wrote: > > 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 <http://out.gn/msvc>* > > If you want to run the tests for good measure: > > * python tools/run-tests.py --outdir out.gn/msvc <http://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 > > > On Friday, December 20, 2019 at 10:29:07 AM UTC-8, Ivan Pizhenko wrote: >> >> 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 >> >> >> >> 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 >> >> On Wednesday, December 18, 2019 at 10:06:42 AM UTC-8, Bill Ticehurst >> wrote: >> >> I'm not clear on what is needed to fix this. The bug has been open quite >&g
RE: [v8-users] Re: Building v8 shared library on windows
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? From: Ivan Pizhenko<mailto:ivan.pizhe...@genesys.com> Sent: Friday, December 20, 2019 20:29 To: v8-users@googlegroups.com<mailto:v8-users@googlegroups.com> Subject: RE: [v8-users] Re: Building v8 shared library on windows 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<mailto:v8-users@googlegroups.com> Sent: Friday, December 20, 2019 20:02 To: v8-users<mailto:v8-users@googlegroups.com> 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 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 On Wednesday, December 18, 2019 at 10:06:42 AM UTC-8, Bill Ticehurst wrote: 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). On Tuesday, December 17, 2019 at 12:44:14 PM UTC-8, Ivan Pizhenko wrote: 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 On Tuesday, December 17, 2019 at 6:36:12 PM UTC+2, Bill Ticehurst wrote: 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
Re: [v8-users] Re: Building v8 shared library on windows
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 On Sun, 22 Dec. 2019, 9:49 am Bill Ticehurst, wrote: > 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 <http://out.gn/msvc>* > > If you want to run the tests for good measure: > > * python tools/run-tests.py --outdir out.gn/msvc <http://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 > > > On Friday, December 20, 2019 at 10:29:07 AM UTC-8, Ivan Pizhenko wrote: >> >> 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 >> >> >> >> 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 >> >> On Wednesday, December 18, 2019 at 10:06:42 AM UTC-8, Bill Ticehurst >> wrote: >> >> 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). >> >> On Tuesday, December 17, 2019 at 12:44:14 PM UTC-8, Ivan Pizhenko wrote: >> >> 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 >> >> >> On Tuesday, December 17, 2019 at 6:36:12 PM UTC+2, Bill Ticehurst wrote: >>
Re: [v8-users] Re: Building v8 shared library on windows
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 On Friday, December 20, 2019 at 10:29:07 AM UTC-8, Ivan Pizhenko wrote: > > 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 > > > > 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 > > On Wednesday, December 18, 2019 at 10:06:42 AM UTC-8, Bill Ticehurst > wrote: > > 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). > > On Tuesday, December 17, 2019 at 12:44:14 PM UTC-8, Ivan Pizhenko wrote: > > 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 > > > On Tuesday, December 17, 2019 at 6:36:12 PM UTC+2, Bill Ticehurst wrote: > > 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). > > > &g
RE: [v8-users] Re: Building v8 shared library on windows
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<mailto:v8-users@googlegroups.com>
Sent: Friday, December 20, 2019 20:02
To: v8-users<mailto:v8-users@googlegroups.com>
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<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<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
On Wednesday, December 18, 2019 at 10:06:42 AM UTC-8, Bill Ticehurst wrote:
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<https://bugs.chromium.org/p/v8/issues/detail?id=8791>).
On Tuesday, December 17, 2019 at 12:44:14 PM UTC-8, Ivan Pizhenko wrote:
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
On Tuesday, December 17, 2019 at 6:36:12 PM UTC+2, Bill Ticehurst wrote:
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<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
On Tuesday, December 17, 2019 at 4:31:52 AM UTC-8, Stefan Wörthmüller wrote:
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/<https://www.nuget.org/packages/v8-v140-x64/>
click on "Download" at the right and rename the archive to zip. Works well for
me.
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users<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<mailto:v8-users+unsubscr...@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<https://groups.google.com/d/msgid/v8-users/a0a7c08b-7ff7-40cf-9104-021a97912018%40googlegroups.com?utm_medium=email_source=footer>.
--
--
v8-users mailing list
v8-u
RE: [v8-users] Re: Building v8 shared library on windows
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. From: 'Bill Ticehurst' via v8-users<mailto:v8-users@googlegroups.com> Sent: Thursday, December 19, 2019 20:43 To: v8-users<mailto:v8-users@googlegroups.com> Subject: Re: [v8-users] Re: Building v8 shared library on windows Just the header file for the public V8 API (https://chromium.googlesource.com/v8/v8.git/+/refs/heads/master/include/v8.h#18<https://chromium.googlesource.com/v8/v8.git/+/refs/heads/master/include/v8.h#18>) includes , , , , and 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 On Thursday, December 19, 2019 at 7:55:52 AM UTC-8, ClearScript Developers wrote: 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. On Wednesday, December 18, 2019 at 1:58:41 PM UTC-5, Ivan Pizhenko wrote: 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 From: 'Bill Ticehurst' via v8-users Sent: Wednesday, December 18, 2019 20:22 To: v8-users Subject: [v8-users] Re: Building v8 shared library on windows 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<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 On Wednesday, December 18, 2019 at 3:09:50 AM UTC-8, Bad_At_Life wrote: 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 -- -- v8-users mailing list v8-u...@googlegroups.com http://groups.google.com/group/v8-users<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-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<https://groups.google.com/d/msgid/v8-users/554c96a8-82e1-4a6d-86c7-2a65d51c5797%40googlegroups.com?utm_medium=email_source=footer>. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users<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<mailto:v8-users+unsubscr...@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<https://groups.google.com/d/msgid/v8-users/c64e6
Re: [v8-users] Re: Building v8 shared library on windows
Just the header file for the public V8 API ( https://chromium.googlesource.com/v8/v8.git/+/refs/heads/master/include/v8.h#18) includes , , , , and 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 On Thursday, December 19, 2019 at 7:55:52 AM UTC-8, ClearScript Developers wrote: > > 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. > > On Wednesday, December 18, 2019 at 1:58:41 PM UTC-5, Ivan Pizhenko wrote: >> >> 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 >> >> >> >> >> >> *From: *'Bill Ticehurst' via v8-users >> *Sent: *Wednesday, December 18, 2019 20:22 >> *To: *v8-users >> *Subject: *[v8-users] Re: Building v8 shared library on windows >> >> >> >> 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 >> >> On Wednesday, December 18, 2019 at 3:09:50 AM UTC-8, Bad_At_Life wrote: >> >> 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 >> >> -- >> -- >> 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-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 >> >> <https://groups.google.com/d/msgid/v8-users/554c96a8-82e1-4a6d-86c7-2a65d51c5797%40googlegroups.com?utm_medium=email_source=footer> >> . >> >> >> > -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/c64e6796-74f7-4bbd-9701-750632714cd7%40googlegroups.com.
Re: [v8-users] Re: Building v8 shared library on windows
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. On Wednesday, December 18, 2019 at 1:58:41 PM UTC-5, Ivan Pizhenko wrote: > > 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 > > > > > > *From: *'Bill Ticehurst' via v8-users > *Sent: *Wednesday, December 18, 2019 20:22 > *To: *v8-users > *Subject: *[v8-users] Re: Building v8 shared library on windows > > > > 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 > > On Wednesday, December 18, 2019 at 3:09:50 AM UTC-8, Bad_At_Life wrote: > > 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 > > -- > -- > 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-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 > > <https://groups.google.com/d/msgid/v8-users/554c96a8-82e1-4a6d-86c7-2a65d51c5797%40googlegroups.com?utm_medium=email_source=footer> > . > > > -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/44b4d4f7-60c1-42b3-adca-fbf656788fe6%40googlegroups.com.
Re: [v8-users] Re: Building v8 shared library on windows
Thank you for sharing that workaround Ivan, I believe I'm hitting the same problem, and your workaround might help me. On Thursday, 19 December 2019 05:28:41 UTC+10:30, Ivan Pizhenko wrote: > > 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 > > > > > > *From: *'Bill Ticehurst' via v8-users > *Sent: *Wednesday, December 18, 2019 20:22 > *To: *v8-users > *Subject: *[v8-users] Re: Building v8 shared library on windows > > > > 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 > > On Wednesday, December 18, 2019 at 3:09:50 AM UTC-8, Bad_At_Life wrote: > > 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 > > -- > -- > 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-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 > > <https://groups.google.com/d/msgid/v8-users/554c96a8-82e1-4a6d-86c7-2a65d51c5797%40googlegroups.com?utm_medium=email_source=footer> > . > > > -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/9905e52d-3f40-4ab7-9e9f-c1f781f527b6%40googlegroups.com.
RE: [v8-users] Re: Building v8 shared library on windows
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 From: 'Bill Ticehurst' via v8-users<mailto:v8-users@googlegroups.com> Sent: Wednesday, December 18, 2019 20:22 To: v8-users<mailto:v8-users@googlegroups.com> Subject: [v8-users] Re: Building v8 shared library on windows 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<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 On Wednesday, December 18, 2019 at 3:09:50 AM UTC-8, Bad_At_Life wrote: 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 -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users<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<mailto:v8-users+unsubscr...@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<https://groups.google.com/d/msgid/v8-users/554c96a8-82e1-4a6d-86c7-2a65d51c5797%40googlegroups.com?utm_medium=email_source=footer>. -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CY4PR10MB20235E157BF2E042427E9B33FF530%40CY4PR10MB2023.namprd10.prod.outlook.com.
