[OpenJDK 2D-Dev] <AWT Dev> Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless
ajit.ghaisas at oracle.com
Thu Apr 28 12:44:06 UTC 2016
I tried excluding files under directory : jdk/src/java.desktop/share/native/common/java2d/opengl from libawt_headless.
It resulted in compilation errors - as the headers in this directory (and under sub-directory J2D_GL) are used in other places.
To Phil's question on - why I mentioned only OGLBlitLoops.c file? - this is the file where warning is reported and build stopped.
Hence, I propose not to remove the suppression of warning E_EMPTY_TRANSLATION_UNIT in make file for Solaris.
There is no change in original webrev : http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/
Based on Erik's suggestion, I have built it for arm and arm64 with no errors.
From: Phil Race
Sent: Friday, April 22, 2016 1:43 AM
To: Ajit Ghaisas
Cc: Sergey Bylokhov; 2d-dev; build-dev at openjdk.java.net
Subject: Re: <AWT Dev> Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless
> Another solution is to exclude this file from HEADLESS compilation.
> I am not sure how to achieve it. Any suggestion?
I suppose that is possible and I expect we can do that See in the make file, where I think you just need to add entries to
LIBAWT_HEADLESS_EXCLUDES := medialib
although I have not tried it.
Hmm .. I wonder why medialib needs to be explicitly excluded from headless ? .. but that is for another day.
I have another question: why do you mention only OGLBlitLoops.c ?
I've flicked through a number of the C files in the same location and all look to have the same issue.
On 04/21/2016 06:33 AM, Ajit Ghaisas wrote:
>>> On 04/20/2016 12:27 PM, Sergey Bylokhov wrote:
>>> 2d-dev added.
>> In fact all these are 2D. No AWT warnings here.
>>> I am not sure but why "declaration in the code" is a bad thing and
>>> we should fix it?
>>> - DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE
>>> I cannot find the documentation in solaris studio for this warning.
>> I don't mind fixing it if it is still an issue but does the current compiler actually complain about it ?
>> The SS11 -> SS12 upgrade might have got a more modern C compiler ..
> [Ajit ] Yes. The Solaris compiler still complains about this declaration in code. Hence, I have fixed the reported warnings after removing the suppression from makefile.
>>> On 20.04.16 11:57, Ajit Ghaisas wrote:
>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8074829
>>>> This bug is to remove warning suppressions from makefile and
>>>> fix the warnings for libawt_headless library.
>>>> I have removed following warning suppressions & fixed the
>>>> warnings for libawt_headless library.
>>>> DISABLED_WARNINGS_gcc := maybe-uninitialized
>> What made that one go away ??
> [Ajit] : I fixed warnings reported for 'maybe-uninitialized' and 'E_DECLARATION_IN_CODE' warning types in two .c files in webrev.
> There was no warning after removal of 'int-to-pointer-cast' suppression from makefile. No code change was made for this type of warning.
>>>> DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE
>>>> Warning suppression that cannot be removed :
>>>> DISABLED_WARNINGS_solstudio := E_EMPTY_TRANSLATION_UNIT
>>>> This is due to the fact that -
>>>> .c file becomes empty file in case of HEADLESS mode compilation.
>> Sigh .. there ought to be "informational" warnings as well as "risky practice" warnings and this should be in the former category.
>> You could move something like the jni.h and jlong.h imports outside to see if that shuts it up.
>> Not saying that is what we want to do but it would be interesting to check.
> [Ajit] : Nope. Moving jni.h or jlong.h inclusions outside #ifndef HEADLESS did not help. We still get E_EMPTY_TRANSLATION_UNIT warning.
> To get rid of this warning, there are suggestions to make a typedef - and not use it anywhere - but, I would rather keep the suppression in makefile than defining a typedef without actual usage.
> Another solution is to exclude this file from HEADLESS compilation. I am not sure how to achieve it. Any suggestion?
>>>> Request you to review following webrev :
More information about the 2d-dev