Chris,
just a passing comment from me. I've been looking at the extension
directory changes. Looks like some code, locale resource files, man
pages and help menus still need updating to remove the ext dir
references. Is that tracked already ?
The rmic, javadoc and javac tools still have the
On 21/11/2014 13:58, Seán Coffey wrote:
Chris,
just a passing comment from me. I've been looking at the extension
directory changes. Looks like some code, locale resource files, man
pages and help menus still need updating to remove the ext dir
references. Is that tracked already ?
The
Hi Chris,
I had a look at the changes in java.logging and java.management modules
(+ corresponding tests) and they look reasonable to me.
I also had a cursory look at the jdeps changes. It's difficult for me
to review that without importing the changes and playing with the
tool as this is a
Hi all,
this patch removes the usage of the flag -fsanitize=undefined introduced
in GCC 4.9. The reason for not using this flag is that the implementation
in GCC still seem to have some bugs [0] (which I have encountered). The
flag is currently only enabled for slowdebug builds.
My suggestion is
On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote:
Almost there! :-)
1) Comment in config.sub identifies it as config.guess.
2) As as understand it, your first attempt is to just dispatch through
to autoconf-config.sub if there is no aarch64 arguments. Good! However,
the code could be
http://cr.openjdk.java.net/~ehelin/8065656/webrev.00/
make/solaris/makefiles/gcc.make
No comments.
make/solaris/makefiles/sparcWorks.make
No comments.
Thumbs up!
Dan
On 11/21/14 8:30 AM, Erik Helin wrote:
Hi all,
this patch changes the debug symbols format on Solaris from STABS
On 21 Nov 2014, at 16:51, Sean Mullan sean.mul...@oracle.com wrote:
The JDK security related changes look fine to me. The
test/java/net/URLPermission/policy.* files only have copyright changes for
some reason.
Thanks for reviewing the security related changes Sean.
The
On 2014-11-21 18:02, Andrew Haley wrote:
On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote:
1) Comment in config.sub identifies it as config.guess.
2) As as understand it, your first attempt is to just dispatch through
to autoconf-config.sub if there is no aarch64 arguments. Good! However,
the
Thank you, Magnus
I will push this into aarch64 staging repo after testing in JPRT.
Vladimir
On 11/21/14 10:03 AM, Magnus Ihse Bursie wrote:
On 2014-11-21 18:02, Andrew Haley wrote:
On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote:
1) Comment in config.sub identifies it as config.guess.
A recurring theme in the build-dev list is confusion on which platforms
it is possible to build OpenJDK. Unfortunately, information about this
has not been easy to gather. It has also not been clear what kind of
build issues the Build Team will respond to and with what kind of urgency.
To
One minor comment: do we want to preserve the history in the new
config.sub,
or check it in as a new file?
dl
On 11/21/2014 10:03 AM, Magnus Ihse Bursie wrote:
On 2014-11-21 18:02, Andrew Haley wrote:
On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote:
1) Comment in config.sub identifies it
The history is preserved since patch is applied above config.sub.
I did 'hg copy config.sub autoconf-config.sub' and then applied the patch.
And there are only 2 changesets in config.sub:
changeset: 574:b66c81dfa291
user:ohair
date:Mon Jan 14 16:38:25 2013 -0800
summary:
I was thinking 'hg mv config.sub autoconf-config.sub' and then
'hg add config.sub' so it doesn't look like we are modifying the
upstream version
of config.sub, but maybe it's not a big deal?
dl
On 11/21/2014 12:03 PM, Vladimir Kozlov wrote:
The history is preserved since patch is applied
Hi,
Thanks for creating this!
* Magnus Ihse Bursie magnus.ihse.bur...@oracle.com [2014-11-21 13:22]:
To help address this, I've created a publicly available wiki page:
https://wiki.openjdk.java.net/display/Build/Supported+build+platforms
Can you clarify what Works correctly means? Does it
On 11/21/2014 06:03 PM, Magnus Ihse Bursie wrote:
Thanks for working through all these iterations!
Oh, the thanks should be the other way around. I really
want this to be right.
Andrew.
On 2014-11-20 12:19, Erik Joelsson wrote:
Hello,
Please review this small fix, correcting the source generation from
properties when the properties files are in platform specific source
directories. The bug was introduced by me in JDK-8055191.
Bug:
A high-level followup ...
Running most text-based OS tools, including sed and sort, is risky
because the user's encoding may be different from the encoding of
source files in the JDK (of course, this is particularly problematic
with properties files, which must be ISO-8859-1). These tools will
What does Peter think? For those too young to remember, Peter invented stabs
way back when he was a young grad student at Berkeley :-)
It has given admirable service, like so much else he has touched!
-- Ramki
ysr1729
On Nov 21, 2014, at 08:30, charlie hunt charlie.h...@oracle.com wrote:
I don't think I invented the stab format. I think stab.h came with adb and sdb,
but might predate even those. Stab.h covers the basics of global symbols,
procedures, source files, line numbers, etc. (The earliest copy I can find is
On 2014-11-21 22:40, Martin Buchholz wrote:
A high-level followup ...
Running most text-based OS tools, including sed and sort, is risky
because the user's encoding may be different from the encoding of
source files in the JDK (of course, this is particularly problematic
with properties files,
Great!
On Fri, Nov 21, 2014 at 3:16 PM, Magnus Ihse Bursie
magnus.ihse.bur...@oracle.com wrote:
On 2014-11-21 22:40, Martin Buchholz wrote:
A high-level followup ...
Running most text-based OS tools, including sed and sort, is risky
because the user's encoding may be different from the
This may be a bug in webrev. If 'hg log -f' shows it as a new file,
that should be enough.
dl
On 11/21/2014 2:37 PM, Vladimir Kozlov wrote:
I did as you said:
hg mv common/autoconf/build-aux/config.sub
common/autoconf/build-aux/autoconf-config.sub
$ hg st
M
22 matches
Mail list logo
