On Thu, 14 Aug 2025 14:44:21 GMT, Julian Waters <jwat...@openjdk.org> wrote:
>> According to >> https://github.com/openjdk/jdk/pull/26661#issuecomment-3162014034, we should >> not build gtest with `/EHsc`. >> >> I can honestly say I don't fully understand the consequences of this change, >> but at least it passes building and testing on Oracle CI. And it does seem >> to make sense that we build the gtest version of libjvm as close as possible >> to the real version. For libgtest I just thought it was prudent to keep the >> flags in sync with how we build libjvm. This might not be the correct >> decision. >> >> I have not tested how or if this affects the ability for gtest to handle >> bugs or crashes in the JVM, nor do I really have any idea about any such >> consequences. This PR is opened more to start a discussion than with the >> intention of just integrating this. > > I did take a brief look at the other Pull Request, but I still don't really > understand this fully. Doesn't the gtest framework itself use C++ exceptions > (As Thomas mentioned)? After all, this is likely why -fno-exceptions is not > used with gcc and clang when compiling gtest. It would be a bit odd if > exceptions were disabled for only Windows (More accurately VC) and not any > other platform. I feel uncomfortable about switching off this warning. I agree with @TheShermanTanker there. Seems to me that if the compiler warns me that I should enable exceptions, I should do that instead of disabling the warning? What is the motivation for this change? What do we gain by switching the feature off? This switch only applies to the gtest compilation units, right, not to the libjvm? Don't we link googletest and libjvm statically? Are exceptions thrown from header files that are compiled as part of the gtest libjvm? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3190668595
