Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node.js 10.1.0 build broken on ppc64[le] #20642

Closed
sgallagher opened this issue May 9, 2018 · 45 comments
Closed

Node.js 10.1.0 build broken on ppc64[le] #20642

sgallagher opened this issue May 9, 2018 · 45 comments
Labels
ppc Issues and PRs related to the Power architecture. v8 engine Issues and PRs related to the V8 dependency.

Comments

@sgallagher
Copy link
Contributor

  • Version: 10.1.0
  • Platform: Fedora Linux
  • Subsystem: Build system

Attempting to build 10.1.0 on ppc64 and ppc64le architectures results in a build failure. This failure was not present on 10.0.0.

My guess is that one of the assembler changes that came in between v8 6.6.346.27 and 6.6.346.24 broke something.

In file included from ../deps/v8/src/base/base-export.h:8:0,
                 from ../deps/v8/src/base/bits.h:11,
                 from ../deps/v8/src/ppc/macro-assembler-ppc.cc:10:
../deps/v8/src/ppc/macro-assembler-ppc.cc: In member function 'void v8::internal::TurboAssembler::Prologue()':
../deps/v8/src/ppc/macro-assembler-ppc.cc:853:15: error: expected primary-expression before '!=' token
   DCHECK(base != no_reg);
               ^
../deps/v8/include/v8config.h:346:54: note: in definition of macro 'V8_UNLIKELY'
 # define V8_UNLIKELY(condition) (__builtin_expect(!!(condition), 0))
                                                      ^~~~~~~~~
../deps/v8/src/base/logging.h:63:27: note: in expansion of macro 'DCHECK_WITH_MSG'
 #define DCHECK(condition) DCHECK_WITH_MSG(condition, #condition)
                           ^~~~~~~~~~~~~~~
../deps/v8/src/ppc/macro-assembler-ppc.cc:853:3: note: in expansion of macro 'DCHECK'
   DCHECK(base != no_reg);
   ^~~~~~
@addaleax addaleax added the v8 engine Issues and PRs related to the V8 dependency. label May 9, 2018
@addaleax
Copy link
Member

addaleax commented May 9, 2018

This might have been “fixed” by v8/v8@7f90312 because that simply removes the DCHECK.

@nodejs/v8

@addaleax addaleax added the ppc Issues and PRs related to the Power architecture. label May 9, 2018
@sgallagher
Copy link
Contributor Author

Yeah, that patch gets quite a bit further. However, it fails further on while trying to build the debugging node with:

  g++ -pthread -rdynamic -m64 -Wl,--whole-archive,/builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/libnode.a -Wl,--no-whole-archive -Wl,-z,noexecstack -Wl,--whole-archive /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/v8/gypfiles/libv8_base.a -Wl,--no-whole-archive -Wl,-z,relro  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o /builddir/build/BUILD/node-v10.1.0/out/Release/node -Wl,--start-group /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/node/src/node_main.o /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/libnode.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/v8/gypfiles/libv8_libplatform.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/tools/icu/libicui18n.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/cares/libcares.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/v8/gypfiles/libv8_base.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/v8/gypfiles/libv8_libbase.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/v8/gypfiles/libv8_libsampler.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/tools/icu/libicuucx.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/tools/icu/libicudata.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/tools/icu/libicustubdata.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/v8/gypfiles/libv8_snapshot.a -lz -lhttp_parser -luv -lnghttp2 -lcrypto -lssl -ldl -lrt -Wl,--end-group
  LD_LIBRARY_PATH=/builddir/build/BUILD/node-v10.1.0/out/Debug/lib.host:/builddir/build/BUILD/node-v10.1.0/out/Debug/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../deps/v8/gypfiles; mkdir -p /builddir/build/BUILD/node-v10.1.0/out/Debug/obj.target/v8_snapshot/geni; "/builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot" --startup_src "/builddir/build/BUILD/node-v10.1.0/out/Debug/obj.target/v8_snapshot/geni/snapshot.cc" ""
#
# Fatal error in ../deps/v8/src/allocation.cc, line 146
# Debug check failed: address == AlignedAddress(address, alignment) (0x1fafde041000 vs. 0x1fafde040000).
#
#
#
#FailureMessage Object: 0x7fffcec97d68
==== C stack trace ===============================
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::base::debug::StackTrace::StackTrace()+0x24) [0x1268e4704]
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(+0x154fe14) [0x12654fe14]
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(V8_Fatal(char const*, int, char const*, ...)+0x128) [0x126544458]
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(+0x15444a8) [0x1265444a8]
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(V8_Dcheck(char const*, int, char const*)+0x30) [0x1265444f0]
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::internal::AllocatePages(void*, unsigned long, unsigned long, v8::PageAllocator::Permission)+0x318) [0x125f10988]
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::internal::VirtualMemory::VirtualMemory(unsigned long, void*, unsigned long)+0x8c) [0x125f10bbc]
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::internal::AlignedAllocVirtualMemory(unsigned long, unsigned long, void*, v8::internal::VirtualMemory*)+0x40) [0x125f10d80]
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::internal::CodeRange::SetUp(unsigned long)+0xcc) [0x125a2f5ec]
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::internal::Heap::SetUp()+0xb4) [0x1259bd604]
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::internal::Isolate::Init(v8::internal::StartupDeserializer*)+0x5b8) [0x125a94298]
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::SnapshotCreator::SnapshotCreator(long const*, v8::StartupData*)+0x14c) [0x12561690c]
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::V8::CreateSnapshotDataBlob(char const*)+0x78) [0x1256895f8]
    /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(main+0x15c) [0x12561320c]
    /lib64/libc.so.6(+0x24778) [0x7fffa3a94778]
    /lib64/libc.so.6(__libc_start_main+0xc4) [0x7fffa3a94984]
/bin/sh: line 1: 29054 Trace/breakpoint trap   (core dumped) "/builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot" --startup_src "/builddir/build/BUILD/node-v10.1.0/out/Debug/obj.target/v8_snapshot/geni/snapshot.cc" ""
make[1]: *** [deps/v8/gypfiles/v8_snapshot.target.mk:13: /builddir/build/BUILD/node-v10.1.0/out/Debug/obj.target/v8_snapshot/geni/snapshot.cc] Error 133
make: *** [Makefile:91: node_g] Error 2

(This failure also occurs on s390x)

@bnoordhuis
Copy link
Member

@nodejs/platform-ppc @nodejs/platform-s390

@john-yan
Copy link

Hello, which v8 branch/hash are you using? Can V8 be built on your environment?

@mhdawson
Copy link
Member

mhdawson commented May 11, 2018

The other key question is which compiler level and binutils levels are you using? @jBarz would it be possible for you to find a fedora system to see if you can replicate with the required compiler level. Of note the compiler level requirement was increased for 10.x (actually it was increased for earlier release as well but we only move the community machines up for 10.x) but it may only be more recent levels of v8 that have introduced dependencies.

@sgallagher
Copy link
Contributor Author

This specific one was run with GCC 8.1 and binutils 2.30.

I can't build v8 separately from Node.js at the moment as I don't have any build scripts for it that I can use for our buildsystem (since I don't have direct access to the builders for those arches).

@jBarz I can help you get access to https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers for a PPC64 or PPC64le machine (I'll get one of them updated to F28 if that's the approach we want to go).

For the time being, I've just disabled the debug build on our packages on those arches; it'll have only the release binary node and not our debug-enabled version node_g.

@mhdawson
Copy link
Member

Ok, those compiler/binutils levels are higher than the ones used in the community so we'd expect it to be ok. Thinking about it more I see its only the debug one that is failing and we don't build that in the community.

@jBarz
Copy link
Contributor

jBarz commented May 14, 2018

@sgallagher Can we get access to a ppc64le fedora?

@sgallagher
Copy link
Contributor Author

@jBarz Yes, I've got someone working on getting you access to a public test machine. He will reply on this issue as soon as it's ready. Sorry for the delay.

@mhdawson
Copy link
Member

@sgallagher ping

@sgallagher
Copy link
Contributor Author

Pong. This isn’t forgotten, but it’s taking me longer than anticipated to get you access to a machine. I’m out of the office today, but I’ll look into things tomorrow. Apologies on the delay.

@sgallagher
Copy link
Contributor Author

@mhdawson @jBarz If you could please create a Fedora account at https://admin.fedoraproject.org/accounts and sign the FPCA then I can give you access to one of our test machines. Please reply (or direct email me at sgallagh (at) redhat (dot) com) with the account(s) you created and I'll have them added to the ACL for the machine.

(Note: the FPCA does not impact copyright ownership, it is just an assertion that if you make a contribution, you assert that you have the rights to make that contribution and that the contribution is being made under an acceptable open-source license).

@mhdawson
Copy link
Member

@jBarz any update on this?

@jBarz
Copy link
Contributor

jBarz commented Jun 20, 2018

Had some trouble setting up the machine but all set now.
Will update soon.

@jBarz
Copy link
Contributor

jBarz commented Jul 24, 2018

Sorry about the delay, just had some time to investigate.
First thing to note is that this also happens on ppcle ubuntu using gcc 4.9

@mhdawson
Copy link
Member

@jBarz so it sounds like it is more an issue with building in debug mode versus the specific OS/compiler?

@jBarz
Copy link
Contributor

jBarz commented Aug 2, 2018

Yes I believe it is.
I submitted a preliminary fix for it here but there is still some ongoing discussion.

https://chromium-review.googlesource.com/c/v8/v8/+/1149515

@jBarz
Copy link
Contributor

jBarz commented Aug 7, 2018

After some discussions with a chromium developer, the following fix was merged for PPC.
https://chromium-review.googlesource.com/c/v8/v8/+/1161210

I have to submit one more fix myself before this issue is resolved.

@mhdawson
Copy link
Member

mhdawson commented Aug 7, 2018

Sounds good, I assume we'll have to float that on 10.X

@jBarz
Copy link
Contributor

jBarz commented Aug 16, 2018

One more fix needs to be submitted to v8 because of 64K page size on linux ppc64.

--- a/src/base/platform/platform-posix.cc
+++ b/src/base/platform/platform-posix.cc
@@ -252,7 +252,7 @@ void* OS::GetRandomMmapAddr() {
   raw_addr &= uint64_t{0x03FFFFFFF000};
 #else
   // Little-endian Linux: 48 bits of virtual addressing.
-  raw_addr &= uint64_t{0x3FFFFFFFF000};
+  raw_addr &= uint64_t{0x3FFFFFFF0000};
 #endif
 #elif V8_TARGET_ARCH_MIPS64
   // We allocate code in 256 MB aligned segments because of optimizations using

@john-yan
Copy link

@mhdawson
Copy link
Member

@sgallagher this was fixed in 10.12.0. Can you validate and then close this issue if you agree?

@sgallagher
Copy link
Contributor Author

@mhdawson I've got it on my plate to build 10.13.0 and 11.0.0 for Fedora today or tomorrow; I'll make sure to validate this when I do. I didn't realize it was in 10.12.0 or I'd have dropped my workaround then.

@sgallagher
Copy link
Contributor Author

@mhdawson Looks like it's still an issue, I'm afraid.

g++ -o /builddir/build/BUILD/node-v10.13.0/out/Release/mksnapshot -pthread -rdynamic -m64 -m64 -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,--start-group /builddir/build/BUILD/node-v10.13.0/out/Release/obj.target/mksnapshot/deps/v8/src/snapshot/mksnapshot.o /builddir/build/BUILD/node-v10.13.0/out/Release/obj.target/deps/v8/gypfiles/libv8_base.a /builddir/build/BUILD/node-v10.13.0/out/Release/obj.target/deps/v8/gypfiles/libv8_init.a /builddir/build/BUILD/node-v10.13.0/out/Release/obj.target/deps/v8/gypfiles/libv8_libbase.a /builddir/build/BUILD/node-v10.13.0/out/Release/obj.target/deps/v8/gypfiles/libv8_libplatform.a /builddir/build/BUILD/node-v10.13.0/out/Release/obj.target/deps/v8/gypfiles/libv8_nosnapshot.a /builddir/build/BUILD/node-v10.13.0/out/Release/obj.target/deps/v8/gypfiles/libv8_libsampler.a /builddir/build/BUILD/node-v10.13.0/out/Release/obj.target/deps/v8/gypfiles/libv8_initializers.a -lz -lhttp_parser -luv -lnghttp2 -lcrypto -lssl -licui18n -licuuc -licudata -ldl -lrt -Wl,--end-group
LD_LIBRARY_PATH=/builddir/build/BUILD/node-v10.13.0/out/Debug/lib.host:/builddir/build/BUILD/node-v10.13.0/out/Debug/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../deps/v8/gypfiles; mkdir -p /builddir/build/BUILD/node-v10.13.0/out/Debug/obj.target/v8_snapshot/geni; "/builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot" --turbo_instruction_scheduling --startup_src "/builddir/build/BUILD/node-v10.13.0/out/Debug/obj.target/v8_snapshot/geni/snapshot.cc"
#
# Fatal error in ../deps/v8/src/base/platform/platform-posix.cc, line 350
# Debug check failed: 0 == size % CommitPageSize() (0 vs. 32768).
#
#
#
#FailureMessage Object: 0x7ffff7ad1588
==== C stack trace ===============================
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(v8::base::debug::StackTrace::StackTrace()+0x24) [0x11fa8d4d4]
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(+0x14d8104) [0x11f8e8104]
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(V8_Fatal(char const*, int, char const*, ...)+0x128) [0x11f8dcaf8]
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(+0x14ccb48) [0x11f8dcb48]
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(V8_Dcheck(char const*, int, char const*)+0x30) [0x11f8dcb90]
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(v8::base::OS::SetPermissions(void*, unsigned long, v8::base::OS::MemoryPermission)+0xdc) [0x11f8e752c]
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(v8::base::PageAllocator::SetPermissions(void*, unsigned long, v8::PageAllocator::Permission)+0x24) [0x11f8df4c4]
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(v8::internal::SetPermissions(void*, unsigned long, v8::PageAllocator::Permission)+0x88) [0x11f27daa8]
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(v8::internal::VirtualMemory::SetPermissions(unsigned long, unsigned long, v8::PageAllocator::Permission)+0x54) [0x11f27dfe4]
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(v8::internal::StoreBuffer::SetUp()+0x248) [0x11ed9f7a8]
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(v8::internal::Heap::SetUp()+0x6ac) [0x11ed249bc]
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(v8::internal::Isolate::Init(v8::internal::StartupDeserializer*)+0x598) [0x11edf4138]
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(v8::SnapshotCreator::SnapshotCreator(v8::Isolate*, long const*, v8::StartupData*)+0x15c) [0x11e9835dc]
    /builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot(main+0x1b8) [0x11e97e9d8]
    /lib64/libc.so.6(+0x24b78) [0x7fffa3624b78]
    /lib64/libc.so.6(__libc_start_main+0xb4) [0x7fffa3624d64]
/bin/sh: line 1:  3432 Trace/breakpoint trap   (core dumped) "/builddir/build/BUILD/node-v10.13.0/out/Debug/mksnapshot" --turbo_instruction_scheduling --startup_src "/builddir/build/BUILD/node-v10.13.0/out/Debug/obj.target/v8_snapshot/geni/snapshot.cc"
rm 96f08d0c5e7ab00954e304dfbc38f739728ed951.intermediatemake[1]: *** [deps/v8/gypfiles/v8_snapshot.target.mk:13: /builddir/build/BUILD/node-v10.13.0/out/Debug/obj.target/v8_snapshot/geni/snapshot.cc] Error 133
 533846947f8231dddad62b76de1f325ce4bd46be.intermediate
make: *** [Makefile:103: node_g] Error 2

@sgallagher
Copy link
Contributor Author

Full logs for the above can be found at https://koji.fedoraproject.org/koji/taskinfo?taskID=30596168

@mhdawson
Copy link
Member

mhdawson commented Nov 2, 2018

@john-yan can you take another look.

@john-yan
Copy link

john-yan commented Nov 15, 2018

@sgallagher Hello I have signup a username (johnyan) under https://admin.fedoraproject.org/accounts. Would you give me access to one of your systems please? Thanks.

@mhdawson
Copy link
Member

@sgallagher ping.

@sgallagher
Copy link
Contributor Author

@john-yan At minimum, you need to sign Fedora's Contributor License Agreement (can be done from the account tool you linked above). Then I need to get you added to some FAS group with access to the testing machines.

@sgallagher
Copy link
Contributor Author

@john-yan Oh, you'll also need to make sure to add an SSH public key to your FAS account so we can use that to grant you access. (Please don't submit your private SSH key... that causes chaos and paperwork 😄)

@john-yan
Copy link

@sgallagher OK I just signed it. sorry I created the account without knowing I also need to sign it after.

@sgallagher
Copy link
Contributor Author

@john-yan OK, once you have the SSH key uploaded, I'll get you access.

@john-yan
Copy link

@sgallagher Thanks, Just uploaded ssh public key.

@sgallagher
Copy link
Contributor Author

@john-yan OK, you should now have access to any of the machines listed at https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers#Available_Machines.2FInstances

@john-yan
Copy link

@sgallagher Thanks, I will have a look.

@mhdawson
Copy link
Member

@john-yan any update?

@miladfarca
Copy link
Contributor

miladfarca commented Jan 28, 2019

Applying 2 more patches to the above patches will fix the debug compiling, here is a diff:

diff --git a/deps/v8/src/base/platform/platform-posix.cc b/deps/v8/src/base/platform/platform-posix.cc
index f85f7fe942..e6ca0fe222 100644
--- a/deps/v8/src/base/platform/platform-posix.cc
+++ b/deps/v8/src/base/platform/platform-posix.cc
@@ -244,11 +244,11 @@ void* OS::GetRandomMmapAddr() {
   // Use extra address space to isolate the mmap regions.
   raw_addr += uint64_t{0x400000000000};
 #elif V8_TARGET_BIG_ENDIAN
-  // Big-endian Linux: 44 bits of virtual addressing.
+  // Big-endian Linux: 42 bits of virtual addressing.
   raw_addr &= uint64_t{0x03FFFFFFF000};
 #else
-  // Little-endian Linux: 48 bits of virtual addressing.
-  raw_addr &= uint64_t{0x3FFFFFFFF000};
+  // Little-endian Linux: 46 bits of virtual addressing.
+  raw_addr &= uint64_t{0x3FFFFFFF0000};
 #endif
 #elif V8_TARGET_ARCH_MIPS64
   // We allocate code in 256 MB aligned segments because of optimizations using
diff --git a/deps/v8/src/heap/store-buffer.cc b/deps/v8/src/heap/store-buffer.cc
index 724edf5721..d48a471e52 100644
--- a/deps/v8/src/heap/store-buffer.cc
+++ b/deps/v8/src/heap/store-buffer.cc
@@ -57,7 +57,7 @@ void StoreBuffer::SetUp() {
   }
 
   if (!reservation.SetPermissions(reinterpret_cast<Address>(start_[0]),
-                                  kStoreBufferSize * kStoreBuffers,
+                                  RoundUp(kStoreBufferSize * kStoreBuffers, CommitPageSize()),
                                   PageAllocator::kReadWrite)) {
     V8::FatalProcessOutOfMemory("StoreBuffer::SetUp");
   }
diff --git a/deps/v8/src/ppc/macro-assembler-ppc.cc b/deps/v8/src/ppc/macro-assembler-ppc.cc
index 68efa84c72..8105612064 100644
--- a/deps/v8/src/ppc/macro-assembler-ppc.cc
+++ b/deps/v8/src/ppc/macro-assembler-ppc.cc
@@ -168,7 +168,7 @@ void TurboAssembler::Call(Register target) {
 }
 
 void MacroAssembler::CallJSEntry(Register target) {
-  DCHECK(target == ip);
+  DCHECK(target == r5);
   Call(target);
 }
 
@@ -850,7 +850,6 @@ void TurboAssembler::StubPrologue(StackFrame::Type type) {
 }
 
 void TurboAssembler::Prologue() {
-  DCHECK(base != no_reg);
   PushStandardFrame(r4);
   if (FLAG_enable_embedded_constant_pool) {
     // base contains prologue address

@mhdawson
Copy link
Member

@miladfarca thanks for the update :). I guess the next steps are potentially getting into V8 master if the problem still exists there as a pre-req for floating in Node.js.

@miladfarca
Copy link
Contributor

@mhdawson no problem, master already includes these fixes, either with the exact code or a modified version past this branch, I have confirmed this by looking at the v8 master as well v8 in nodejs master. I have also built the latest nodejs on fedora/ppc64 and it builds with no errors.

I am going to work on backporting this fix to an abandoned branch of v8 in nodejs 10.1.0

@miladfarca
Copy link
Contributor

PR submitted for backport to v10.x

#25827

@mhdawson
Copy link
Member

mhdawson commented Feb 1, 2019

@miladfarca thanks for the update and the PRs :)

@miladfarca
Copy link
Contributor

@mhdawson Not a problem.

@mhdawson
Copy link
Member

mhdawson commented Mar 1, 2019

Looks like PR landed so we just need to wait for the next v10.x release :)

@BethGriggs
Copy link
Member

@sgallagher, #25827 landed and was released in v10.15.3, so I believe this is now fixed. Thanks @miladfarca

@sgallagher
Copy link
Contributor Author

I can confirm that this worked in my Fedora builds. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ppc Issues and PRs related to the Power architecture. v8 engine Issues and PRs related to the V8 dependency.
Projects
None yet
Development

No branches or pull requests

8 participants