Some day, I'd like to replace a lot of medialib functionality with something
like the proposed Vector API. But that is far enough away that medialib
needs
to be maintained, and unlike a previous discussion about a similar issue in
the JPEG library, we are on the hook for maintaining medialib.
Hi Andrew,
As noted in the issue comments, the fdlibm C code is obsolescent and eventually
to be superseded by equivalent Java implementations. As for the mediaLib code
being moribund I cannot speak but am copying 2d-dev which owns java.desktop.
Thanks,
Brian
On Aug 30, 2018, at 6:03 AM,
Hi
I read
It’d be much better and reliable to fix makefiles to always use
‘disable-warning-as-errors’ when ‘enable-native-coverage’ is used. It
should be pretty straightforward to do.
as you propose not to fix false positive warnings but fix make files instead.
Because
Hi,
my claim was based on the warnings which we were getting when we just
introduced code coverage builds in JDK 9, e.g. 8130790[1] (clobbered warning in
libt2k). these warnings haven't been seen w/o code coverage enabled, and
enabling coverage changes code path, so I don't think we should
Hi Magnus,
Sounds good. Will update the message.
Thanks!
Jiangli
On 8/30/18 3:56 AM, Magnus Ihse Bursie wrote:
On 2018-08-29 17:45, Erik Joelsson wrote:
Hello Magnus,
As the author of the build changes I will answer this.
On 2018-08-29 04:53, Magnus Ihse Bursie wrote:
On 2018-08-28
Looks good to me.
/Erik
On 2018-08-30 08:12, Maurizio Cimadamore wrote:
Hi,
this patch adds proper support for -o option to the idea.sh script,
which allows to place the .idea folder under any given output folder
(not necessarily the JDK root).
To be able to do this, I had to revampo the
Hi,
this patch adds proper support for -o option to the idea.sh script,
which allows to place the .idea folder under any given output folder
(not necessarily the JDK root).
To be able to do this, I had to revampo the logic for template
substitution in idea.sh, as it was growing too brittle.
Thanks Goetz,
I've created an hg export below..
I've not used jdk-submit, i've tested it locally on xLinux and zLinux.
Cheers
Andrew
# HG changeset patch
# User aleonard
# Date 1535641094 -3600
# Thu Aug 30 15:58:14 2018 +0100
# Node ID 592a8ad8d4c16287c316d018a0a402148720718b
# Parent
Hi Leonard,
the change looks good to me.
I'll test it tonight, to make sure it runs with our compilers.
Did you run it through jdk-submit?
If you supply a patch with all the changeset information (like
from hg export) that jchecks fine, I'll sponsor this for you.
Best regards,
Goetz.
>
Hi Matthias,
thanks for fixing the build. Looks good.
I think it can be treated as trivial and pushed, because it just renames
NUMBER_OF_FRAMES to avoid a conflict with AIX stuff.
Best regards,
Martin
From: Baesken, Matthias
Sent: Donnerstag, 30. August 2018 16:14
To: Lindenmaier, Goetz ;
Thanks , can I have a second review please ?
Best regards, Matthias
From: Lindenmaier, Goetz
Sent: Donnerstag, 30. August 2018 14:17
To: Baesken, Matthias ;
'hotspot-...@openjdk.java.net' ;
'build-dev@openjdk.java.net'
Cc: Doerr, Martin
Subject: RE: RFR : 8210205 : build fails on AIX in
On 8/30/18 8:36 AM, Magnus Ihse Bursie wrote:
Hi folks,
This bug report goes all the way back to 2008. :-) So instead of just
letting it go on to it's second decade of existence, I went about and
fixed it.
By now, not many references to sparcWorks exists anymore, so this is
almost trivial.
Hi there,
JDK-8209611 seems to cause many missing-field-initializer warning-errors
like below:
I am using gcc 4.8.5
Compiling libvmdeath001.cpp (for libvmdeath001.so)
In file included from
Looks good to me.
/Erik
On 2018-08-30 05:36, Magnus Ihse Bursie wrote:
Hi folks,
This bug report goes all the way back to 2008. :-) So instead of just
letting it go on to it's second decade of existence, I went about and
fixed it.
By now, not many references to sparcWorks exists anymore,
Hello,
On 2018-08-30 02:22, Magnus Ihse Bursie wrote:
On 2018-08-24 00:44, Igor Ignatev wrote:
Hi Leonid,
We have never supported native code coverage builds with warnings
enabled as errors. There are bugs in gcc which cause false positive
warnings, so it was decided to ignore all
Thanks Magnus,
Yes, these libraries are moribound it seems, hence their preference for
compile options..
Cheers
Andrew
Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com
From:
Andrew,
If you want to make changes to the build system (files in make/*),
please always include build-dev in the reviews.
From a build point, this fix looks okay. My general preference is to
fix shady code instead of disabling warnings, but in this case it's in
two libraries that are
Hi folks,
This bug report goes all the way back to 2008. :-) So instead of just
letting it go on to it's second decade of existence, I went about and
fixed it.
By now, not many references to sparcWorks exists anymore, so this is
almost trivial.
I've verified by grep that no more
Hi Matthias,
Aix is a nuisance. Thanks for fixing this.
Looks good.
As this is a build fix, and only changes tests, I think you don't need
to follow the 24h rule, i.e., you can push it sooner.
Best regards,
Goetz.
From: Baesken, Matthias
Sent: Donnerstag, 30. August 2018 13:21
To:
Hello, please review this small fix to repair our AIX build .
Recent changes to jdk/jdk broke the build .
We get clashes with defines from system headers in a few compilation units,
for example :
On 2018-08-29 17:45, Erik Joelsson wrote:
Hello Magnus,
As the author of the build changes I will answer this.
On 2018-08-29 04:53, Magnus Ihse Bursie wrote:
On 2018-08-28 18:25, Erik Joelsson wrote:
Build changes look good to me (but should probably get review from
someone else).
I'm (as
On 2018-08-24 00:44, Igor Ignatev wrote:
Hi Leonid,
We have never supported native code coverage builds with warnings enabled as
errors. There are bugs in gcc which cause false positive warnings, so it was
decided to ignore all warnings from instrumented builds. It’d be much better
and
Hi
Thanks for background. Assuming these or similar issues were already discussed
and it was decided to ignore warnings for code coverage builds I think it is
fine to fix build. Current warnings don't look as real issues for me also.
I moved components alias as bcc since now it is build-only
23 matches
Mail list logo
