Error graph-builder-tester.h:172:56: error: no matching function for call to 'v8::internal::compiler::SimplifiedOperatorBuilder::ChangeFloat64ToTagged()' when trying to build V8 with GCC 7.1.0

[Georgi Sotirov]

Hello,

I'm trying to build V8 with the following command:

time make V=1 ia32.release GYPFLAGS='-Dclang=0 -Dwerror= -Dcomponent=shared_library'

with GCC 7.1.0, but I'm stuck with the following error:

g++ '-DV8_GYP_BUILD' '-DCR_CLANG_REVISION=308728-3' '-DV8_TARGET_ARCH_IA32' '-DENABLE_GDB_JIT_INTERFACE' '-DV8_DEPRECATION_WARNINGS' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-DV8_INTL_SUPPORT' '-DV8_USE_EXTERNAL_STARTUP_DATA' '-DV8_CHECK_MICROTASKS_SCOPES_CONSISTENCY' '-DBUILDING_V8_SHARED' '-DUSING_V8_BASE_SHARED' '-DUSING_V8_PLATFORM_SHARED' '-DENABLE_HANDLE_ZAPPING' -I../. -I../include  -Wall -Wno-unused-parameter -pthread -Wmissing-field-initializers -Wno-strict-overflow -fno-strict-aliasing -fvisibility=hidden -fPIC -Wno-uninitialized -B/usr/src/v8/third_party/binutils/Linux_ia32/Release/bin -msse2 -mfpmath=sse -mmmx -B/usr/src/v8/third_party/binutils/Linux_ia32/Release/bin -msse2 -mfpmath=sse -mmmx -m32 -m32 -fdata-sections -ffunction-sections -O3 -fdata-sections -ffunction-sections -O3 -Wnon-virtual-dtor -fno-exceptions -fno-rtti -std=gnu++11 -MMD -MF /usr/src/v8/out/ia32.release/.deps//usr/src/v8/out/ia32.release/obj.target/cctest/test/cctest/compiler/test-js-context-specialization.o.d.raw   -c -o /usr/src/v8/out/ia32.release/obj.target/cctest/test/cctest/compiler/test-js-context-specialization.o ../test/cctest/compiler/test-js-context-specialization.cc
In file included from ../test/cctest/compiler/test-js-context-specialization.cc:16:0:
.././test/cctest/compiler/graph-builder-tester.h: In member function 'v8::internal::compiler::Node* v8::internal::compiler::GraphBuilderTester<ReturnType>::ChangeFloat64ToTagged(v8::internal::compiler::Node*)':
.././test/cctest/compiler/graph-builder-tester.h:172:56: error: no matching function for call to 'v8::internal::compiler::SimplifiedOperatorBuilder::ChangeFloat64ToTagged()'
     return NewNode(simplified()->ChangeFloat64ToTagged(), a);
                                                        ^
In file included from .././test/cctest/compiler/graph-builder-tester.h:15:0,
                 from ../test/cctest/compiler/test-js-context-specialization.cc:16:
.././src/compiler/simplified-operator.h:409:19: note: candidate: const v8::internal::compiler::Operator* v8::internal::compiler::SimplifiedOperatorBuilder::ChangeFloat64ToTagged(v8::internal::compiler::CheckForMinusZeroMode)
   const Operator* ChangeFloat64ToTagged(CheckForMinusZeroMode);
                   ^~~~~~~~~~~~~~~~~~~~~
.././src/compiler/simplified-operator.h:409:19: note:   candidate expects 1 argument, 0 provided
make[1]: *** [test/cctest/cctest.target.ia32.release.mk:386: /usr/src/v8/out/ia32.release/obj.target/cctest/test/cctest/compiler/test-js-context-specialization.o] Error 1
rm bdc92efe44eca1954fdff70fd086c7e138d0fbb1.intermediate
make[1]: Leaving directory '/usr/src/v8/out'
make: *** [Makefile:315: ia32.release] Error 2

Any help is appreciated.

[Jakob Kummerow]

Feel free to delete the offending function (in test/cctest/compiler/graph-builder-tester.h:171-173), it doesn't seem to be used (which is presumably why clang doesn't complain here).

Also, next time, please indicate the version of V8 that you're compiling.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Georgi Sotirov]

Feel free to delete the offending function (in test/cctest/compiler/graph-builder-tester.h:171-173), it doesn't seem to be used (which is presumably why clang doesn't complain here).

Sure, I did it and build continues, but isn't this supposed to be fixed upstream? I though V8 is buildable with both Clang and GCC.
 

I'm trying to build V8 with the following command:

Sorry, cloned from the source repository like this:

$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
$ export PATH=`pwd`/depot_tools:"$PATH"
$ fetch v8

Because cloning directly V8 from GitHub as shown below results in error about missing third party software:

$ git clone 'https://github.com/v8/v8.git'
$ time make V=1 ia32.release GYPFLAGS='-Dclang=0 -Dwerror= -Dcomponent=shared_library'
make: *** No rule to make target 'third_party/icu/icu.gypi', needed by 'out/Makefile.ia32.release'.  Stop.

[Jakob Kummerow]

On Wed, Aug 2, 2017 at 9:55 AM, Georgi Sotirov <gdso...@gmail.com> wrote:

Feel free to delete the offending function (in test/cctest/compiler/graph-builder-tester.h:171-173), it doesn't seem to be used (which is presumably why clang doesn't complain here).

Sure, I did it and build continues, but isn't this supposed to be fixed upstream? I though V8 is buildable with both Clang and GCC.

Yes, sure. We have gcc-4.8 bots on our waterfall and they're happy. Feel free to submit a patch for gcc-7.1 support :-)

 

I'm trying to build V8 with the following command:

Sorry, cloned from the source repository like this:

That's fine, we also have official documentation. 

When I asked about version, I did mean version, not cloning instructions. "fetch v8" gives you a different thing every day, because V8 is under active development. (You can "git pull && gclient sync" to stay up to date after the initial "fetch v8".)

[Georgi Sotirov]

Yes, sure. We have gcc-4.8 bots on our waterfall and they're happy. Feel free to submit a patch for gcc-7.1 support :-)

 
GCC 4.8 is at least 4 years old and as I see in GitHub V8 is under very active development, so strange that only newer GCC versions are not considered... A patch commenting out the offending function? OK, I could submit such patch, but I'm not sure this is the right solution and I do not know V8's source at all to make a real fix.

 

That's fine, we also have official documentation. 

When I asked about version, I did mean version, not cloning instructions. "fetch v8" gives you a different thing every day, because V8 is under active development. (You can "git pull && gclient sync" to stay up to date after the initial "fetch v8".)

Yes, I got you point, but I find V8 version numbering as confusing as the official documentation and the procedure I referred was the only one working for me so far. And I pretty much understand what cloning means, so at least it's clear the problem is in the most recent source. However, I'm just trying to build V8 library without having to read tons of documentation and learning new tools (mostly used internally in Google as it seems), because V8 is not my primary development interest, but just a dependency I need to satisfy.

Anyway, now that I was able to build V8 with the help of the people from this group (including you) how could I install it? There is no "make install":

$ make install
$ make: *** No rule to make target 'install'.  Stop.

Perhaps I also need to elaborate my own installation script?

My ultimate goal is to build a package in order to redistribute V8 library more easily and conveniently, but frankly V8 is the toughest software in terms of building and packaging that I met since long ago.

[Jakob Kummerow]

On Wed, Aug 2, 2017 at 1:04 PM, Georgi Sotirov <gdso...@gmail.com> wrote:

Yes, sure. We have gcc-4.8 bots on our waterfall and they're happy. Feel free to submit a patch for gcc-7.1 support :-)

 
GCC 4.8 is at least 4 years old and as I see in GitHub V8 is under very active development, so strange that only newer GCC versions are not considered...

GCC 4.8 is what ships in Ubuntu Trusty, which is still our main development platform. Usually ensuring that older toolchains are still supported is more difficult (and hence more important) than supporting newer toolchains.

Most people build with the bundled clang; GCC support is mostly community driven at this point. The fact that it has been broken for a while until you found it tells you how few people care about it...

 

A patch commenting out the offending function? OK, I could submit such patch, but I'm not sure this is the right solution and I do not know V8's source at all to make a real fix.

Unused functions, especially in tests, can just be deleted. (No point in commenting out code that doesn't work, just drop it.)

 

When I asked about version, I did mean version, not cloning instructions. "fetch v8" gives you a different thing every day, because V8 is under active development. (You can "git pull && gclient sync" to stay up to date after the initial "fetch v8".)

Yes, I got you point, but I find V8 version numbering as confusing as the official documentation and the procedure I referred was the only one working for me so far. And I pretty much understand what cloning means, so at least it's clear the problem is in the most recent source. However, I'm just trying to build V8 library without having to read tons of documentation and learning new tools (mostly used internally in Google as it seems), because V8 is not my primary development interest, but just a dependency I need to satisfy.

I wasn't asking you to learn any new tool or understand V8 version numbering. I was just saying: next time you report a problem, please indicate the version you were using. The git hash of your most recent commit is perfectly fine for that.

 

Anyway, now that I was able to build V8 with the help of the people from this group (including you) how could I install it? There is no "make install":

$ make install
$ make: *** No rule to make target 'install'.  Stop.

Indeed, there is no "make install". V8 is designed to be embedded/bundled; installing it as a system library does not make much sense.

[Georgi Sotirov]

GCC 4.8 is what ships in Ubuntu Trusty, which is still our main development platform. Usually ensuring that older toolchains are still supported is more difficult (and hence more important) than supporting newer toolchains.

Most people build with the bundled clang; GCC support is mostly community driven at this point. The fact that it has been broken for a while until you found it tells you how few people care about it...

Well, I won't argue here, but still I believe the error reported by GCC 7.1.0 is something that should be fixed into the sources no matter of the compiler used (apparently some ignore it while others report it). I tried clang for building V8, but I had much more errors (than with GCC), which would perhaps be a subject for another thread when I'm unable to fix the GCC build myself (or with some help from the community).
 

Unused functions, especially in tests, can just be deleted. (No point in commenting out code that doesn't work, just drop it.)

 
Why it is there in first place then? Shouldn't it be removed upstream, so I do not have to manage my own patches for this?

I wasn't asking you to learn any new tool or understand V8 version numbering. I was just saying: next time you report a problem, please indicate the version you were using. The git hash of your most recent commit is perfectly fine for that.

Yes, OK, I though it's clear enough that I cloned the repository, so using the most recent version (i.e. or several days old). However, you're right it's sometimes important to know the last hash, because changes are committed constantly. Nevertheless I do not think this information would have been of a match use, because what you wrote there doesn't give me much optimism that the problem would be fixed upstream (e.g. it doesn't matter much whether I use version 1, 2 or more days old).
 

Indeed, there is no "make install". V8 is designed to be embedded/bundled; installing it as a system library does not make much sense.

Even when eventually it would be shared between several applications? Hmm... I'll check what exactly the dependent application requires.

[Jakob Kummerow]

On Sun, Aug 6, 2017 at 3:17 AM, Georgi Sotirov <gdso...@gmail.com> wrote:

GCC 4.8 is what ships in Ubuntu Trusty, which is still our main development platform. Usually ensuring that older toolchains are still supported is more difficult (and hence more important) than supporting newer toolchains.

Most people build with the bundled clang; GCC support is mostly community driven at this point. The fact that it has been broken for a while until you found it tells you how few people care about it...

Well, I won't argue here, but still I believe the error reported by GCC 7.1.0 is something that should be fixed into the sources no matter of the compiler used

Absolutely. Feel free to submit a patch. 

Unused functions, especially in tests, can just be deleted. (No point in commenting out code that doesn't work, just drop it.)

 
Why it is there in first place then?

Probably forgotten in a refactoring.

 

Shouldn't it be removed upstream, so I do not have to manage my own patches for this?

Absolutely. Feel free to submit a patch.

 

I wasn't asking you to learn any new tool or understand V8 version numbering. I was just saying: next time you report a problem, please indicate the version you were using. The git hash of your most recent commit is perfectly fine for that.

Yes, OK, I though it's clear enough that I cloned the repository, so using the most recent version (i.e. or several days old). However, you're right it's sometimes important to know the last hash, because changes are committed constantly. Nevertheless I do not think this information would have been of a match use, because what you wrote there doesn't give me much optimism that the problem would be fixed upstream (e.g. it doesn't matter much whether I use version 1, 2 or more days old).

Agreed, in this case it didn't make a difference, but we didn't know that up front; it may well have mattered (if compilation issues get committed at all, they are usually fixed or reverted in minutes to hours, because they block everyone else's work). 

All I said was: next time, please mention the version.

Indeed, there is no "make install". V8 is designed to be embedded/bundled; installing it as a system library does not make much sense.

Even when eventually it would be shared between several applications? Hmm... I'll check what exactly the dependent application requires.

The situation is complicated. V8 evolves quickly, with usually-ABI-incompatible versions every six weeks, and minor bugfix updates in between. You'd end up having to recompile dependent applications a lot. Another issue is that if a user e.g. wants Chromium and node.js on their system, but the respective current versions of both require different V8 versions, then sharing the V8 package is simply impossible. You'd have to have support for several versions of V8 installed side by side, with each application using one of them, so you effectively wouldn't get any sharing. Also, Node.js often floats additional patches on top of upstream V8, which would also be very difficult to support in a shared-system-library deployment model.

As a data point: AFAIK Gentoo offered a V8 package for a while, and then dropped it because it wasn't worth it.