#2 was already fixed. I mentioned that commit earlier in this thread. See https://chromium-review.googlesource.com/c/v8/v8/+/2042874
You could provide explicit members (I have a comment in that CL with a Gist to explain the problem which does exactly that - see https://gist.github.com/billti/bb83220ef70d2bd58e9889b83664b752 ). You can also just not export the class as it's not needed elsewhere, which is what my CL did. - Bill On Tuesday, March 17, 2020 at 7:49:59 AM UTC-7, Jakob Kummerow wrote: > > On Tue, Mar 17, 2020 at 2:42 PM Chris Fischer <[email protected] > <javascript:>> 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/6840d036-d3ee-4a75-9876-f8cc4193f95a%40googlegroups.com.
