<AWT Dev> Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless
erik.joelsson at oracle.com
Thu Apr 28 12:55:27 UTC 2016
Then I'm happy, thanks!
On 2016-04-28 14:44, Ajit Ghaisas wrote:
> 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.
> -----Original Message-----
> 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 build-dev