Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-15 Thread Dan Elphick
My suggested fix there doesn't seem to work MSVC non-component builds so probably won't work for component builds either. I think https://chromium-review.googlesource.com/c/v8/v8/+/1918249 should work. On Fri, 15 Nov 2019 at 15:05, Dan Elphick wrote: > No worries. You're finding real bugs which

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-15 Thread Dan Elphick
No worries. You're finding real bugs which clang/gcc which don't show up with clang/gcc because of the way they do dll import/exports. In this case there's a missing inline keyword at: https://cs.chromium.org/chromium/src/v8/src/objects/hash-table.h?sq=package:chromium=0=150 It should be: static

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-15 Thread Ben Ernst
Dan, I resynced with your landed changes, and reverted 7186b6 as you suggested. I encounter the error message below. As ever, I appreciate your ongoing correspondence, I am sure it must be a painful process. Ben [exec] FAILED: obj/d8/async-hooks-wrapper.obj [exec] ninja -t msvc -e

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-14 Thread Clemens Backes
FYI: There is an open bug about cleaning up utils.h , and I worked a bit on that last Friday, but did not get to split out the BitField class, and others. Thanks for taking this over! On Thu, Nov 14, 2019 at 4:55 PM Dan Elphick wrote: > The utils.h header file is a

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-14 Thread Dan Elphick
The utils.h header file is a bit of a mess. I've just uploaded (but not yet committed) https://chromium-review.googlesource.com/c/v8/v8/+/1916604, which splits out the parts of that used by the problematic executable. I've checked the preprocessor output on Linux and it looks like it's not

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-14 Thread Ben Ernst
Dan, the patch very nearly did the trick, there's just one last unresolved external symbol. Ben. [exec] [5/686] LINK bytecode_builtins_list_generator.exe bytecode_builtins_list_generator.exe.pdb [exec] FAILED: bytecode_builtins_list_generator.exe

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-14 Thread Dan Elphick
So the problem is that utils.h includes include/v8.h. That declares things like IsolateFromNeverReadOnlySpaceObject, which is appearing in the preprocessor outputs as: __declspec(dllexport) internal::Isolate* IsolateFromNeverReadOnlySpaceObject(Address obj); It's marked as export because it's

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-14 Thread Dan Elphick
If instead of building everything, does torque build? e.g. ninja -C torque. It looks like it does from the log but just want to check. It seems odd that it can build that one but not the other simpler executable. Below is the command line for building bytecode-operands.obj from your log. It

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-13 Thread Marcelo Rocha
Hi, I suggest removing the line "is_clang=false", to use the default value. I had problem using this configuration in the past. Em qua., 13 de nov. de 2019 às 08:32, Ben Ernst escreveu: > My full gn args are as follows: > > is_debug = false > target_cpu = "x64" > treat_warnings_as_errors=false

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-13 Thread Dan Elphick
That's very odd. bytecode_builtins_list_generator is a very small executable that depends on base and generates a header file. It should not be using any of the symbols in your log below and would usually be built and linked before compiling the files containing those symbols. Could you do a

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-13 Thread Ben Ernst
My full gn args are as follows: is_debug = false target_cpu = "x64" treat_warnings_as_errors=false is_component_build=true v8_enable_i18n_support=false v8_use_snapshot=true use_custom_libcxx=false is_clang=false But when I try to build V8 (n.b. on Windows) (n.b. V8 version 7.8.279) I get the

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-06 Thread Ben Ernst
Thanks Hans, I'm sure I tried that before, but I'll give that a shot again. Ben. On Monday, 4 November 2019 17:46:08 UTC+10:30, Hans Maier wrote: > > Hi, > > the libc provided together with v8 is incompatible with the msvc-libc. > I had to provide "use_custom_libcxx=false" to be able to link it

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-03 Thread Hans Maier
Hi, the libc provided together with v8 is incompatible with the msvc-libc. I had to provide "use_custom_libcxx=false" to be able to link it with my own program. Am Sonntag, 3. November 2019 12:43:57 UTC+1 schrieb Ben Ernst: > > Of note, the sample utilities "d8" and "v8_hello_world" build

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-03 Thread Ben Ernst
Of note, the sample utilities "d8" and "v8_hello_world" build fine, and they don't get this same linker error. I can't see anything I'm doing differently, however. On Sunday, 3 November 2019 22:08:27 UTC+10:30, Ben Ernst wrote: > > Thanks Jakob, is there by any chance a correpsonding buildbot

Re: [v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-11-01 Thread Jakob Kummerow
Yes, the component build is expected to work for every version, and our buildbot thinks it does: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20shared The component build is also the default in Debug mode, which most V8 developers compile/use every day. On Fri, Nov 1, 2019 at 1:00

[v8-users] Is "is_component_build" expected to work at all in v8 7.8?

2019-10-31 Thread Ben Ernst
Is the idea of a "component build", where you specify "is_component_build=true" in the arguments to GN, actually supposed to work at all in V8 (v7.8)? In particular, I am getting this unresolved external symbol: 1>ezv8_platform.obj : error LNK2019: unresolved external symbol