RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v26]

Julian Waters jwaters at openjdk.org
Tue Jan 16 06:26:58 UTC 2024


On Thu, 16 Nov 2023 03:44:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> I happened to ask around on the build-dev mailing lists about whether we include msvcp.dll with the JDK, here is Erik's response:
>> 
>>> Back in JDK 8 when we used Visual Studio 2010, we used to not ship
>>> msvcp*.dll. This changed when I added support for building with Visual
>>> Studio 2013 [1] in JDK 9. In the patch for that bug I found this text:
>>> 
>>>+   # If building with Visual Studio 2010, we can still use
>>> _STATIC_CPPLIB to
>>>+   # avoid bundling msvcpNNN.dll. Doesn't work with newer versions of
>>> visual
>>>+   # studio.
>>> 
>>> So since we switched to Visual Studio 2013, we started to bundle
>>> msvcp*.dll. It was only ever possible to not bundle it if you built with
>>> Visual Studio 2010 (or older I suppose). It's pretty safe to say that
>>> the current mainline JDK build requires msvcp.dll to be bundled. Looking
>>> at the configure logic, configure will fail unless we find it and the
>>> copying in open/make/modules/java.base/Copy.gmk is unconditional.
>>> 
>>> /Erik
>>> 
>>> [1] https://bugs.openjdk.org/browse/JDK-8042707
>> 
>> This may be unrelated, but I really think we should kill the std::bad_alloc hack in awt.dll as such
>
>> I happened to ask around on the build-dev mailing lists about whether we include msvcp.dll with the JDK, here is Erik's response:
> 
> Yes, I saw that. It doesn't make any difference.
> Although BTW the comment points out we shouldn't be doing static linking anymore.
> 
> 
>> This may be unrelated, but I really think we should kill the std::bad_alloc hack in awt.dll as such
> 
> seems unrelated, yes, but I'd have to look at that, to see if there's a reason to touch it. Itchy fingers are  not a valid reason.

@prrace ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1893138028


More information about the client-libs-dev mailing list