On Tue, Mar 17, 2020 at 2:42 PM Chris Fischer <[email protected]> wrote:
> > > > 1. Modify the third_party/zlib/BUILD.gn configuration to rename the > zlib.dll to something different (conflicted with other 3rd party > dependencies in our system). > 2. Modify src/heap/memory-measurement.cc to provide explicit > constructor and assignment move operations (also had to ! treat warnings as > errors). > > > > Not sure if these are worth pushing. Advice? > I assume there's not much interest in upstreaming (1), as it sounds like an environment-specific issue, and the renaming might cause issues elsewhere. (2) sounds more interesting, if you can describe more clearly when it's needed (we have an MSVC builder, why wasn't it a problem there?), and if it's still applicable to the current sources. See https://v8.dev/docs/contribute for the process. Not treating warnings as errors is expected for non-standard toolchains. That said, if the errors are reasonable, I'd be happy to accept patches to fix them. (Sometimes specific compilers find things that are worth fixing; sometimes they just have weird issues that would require weird workarounds.) What is the governing philosophy @V8 related to link & runtime > compatibility with “native” compile environments for different operating > systems? It seems like Centos7 & RHEL7 are still very common in data > centers and fertile grounds where embedded JavaScript solutions add value. > The GLIBC requirement for 2.18 seems onerous for embedders on those > platforms. Also, issue #2 (especially if there is no effort to correct or > curtail API additions like that) will eventually force embedders to abandon > V8 or convert their full stacks to use CLANG or at least libc++. In our > case, we have over a dozen open source or third party components that we > need to update to change something like compiler platform or OS version. > The governing philosophy is that we are interested in keeping GCC/MSVC/libstdc++ builds working; nobody should be forced to use Clang or libc++. As I pointed out in my last email, we do have some ongoing test coverage. And we are happy to accept (reasonably non-intrusive) patches to improve compatibility (e.g. for GCC versions older or younger than what our bots test with). Regarding versions, we don't break older distros on purpose, but e.g. at some point we decide "it's okay to use C++14 features in the code now", and then that means that we require system libraries that support that. RHEL/CentOS, especially still-supported-but-not-current versions, have historically often been quite far behind all other distros. In that particular case, linking against a custom libc++ might help -- just as much as linking against a custom (newer than what the system provides) libstdc++ would help. I'm not sure we have spelled out an explicit policy somewhere, when in doubt we'd probably follow Google Chrome's requirements <https://support.google.com/chrome/answer/95346>. Effectively I think it mostly boils down to "supported stable Debian / Ubuntu-LTS" as the minimum version. -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAKSzg3Qdiz6OF4U47hTYhOWXYJZgMgH1q8c9kkbERLhCNJ9Zpw%40mail.gmail.com.
