On Sun, Aug 6, 2017 at 3:17 AM, Georgi Sotirov <gdsoti...@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. -- -- 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. For more options, visit https://groups.google.com/d/optout.
