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 common/autoconf/generated-confi
Great!
On Fri, Nov 21, 2014 at 3:16 PM, Magnus Ihse Bursie
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 encoding of
>> source
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,
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
http://svnweb.freebsd.org/csrg/include/stab.h?revision=12194
I did as you said:
hg mv common/autoconf/build-aux/config.sub
common/autoconf/build-aux/autoconf-config.sub
$ hg st
M common/autoconf/generated-configure.sh
M common/autoconf/jdk-options.m4
M common/autoconf/platform.m4
A common/autoconf/build-aux/autoconf-config.sub
R common/autoconf/build-au
Peter's email id corrected, this time...
ysr1729
> On Nov 21, 2014, at 13:42, Srinivas Ramakrishna wrote:
>
>
> 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 m
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 wrote:
>
> Looks good, though I
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
pr
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: https://bugs.openjdk.java.net/browse/JDK-8
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.
Hi,
Thanks for creating this!
* Magnus Ihse Bursie [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 mean just building
or does it
Hi Magnus,
> 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 o
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 abov
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: 80
Hi Chris,
The jaxp changes look good as well. Only a couple of debug info in
javax/xml/datatype/FactoryFinder.java and
javax/xml/parsers/FactoryFinder.java may be fixed. They were wrong
originally. You've fixed it in other FactoryFinders.
"found in $java.home/jaxp.properties,
"fou
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
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 help
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.
2)
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
On 21 Nov 2014, at 16:51, Sean Mullan 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 jdk/test/java/net/URLPermission/policy.
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 code could be made clearer: Th
The JDK security related changes look fine to me. The
test/java/net/URLPermission/policy.* files only have copyright changes
for some reason.
--Sean
On 11/20/2014 04:41 PM, Chris Hegarty wrote:
From: Chris Hegarty
Subject: RFR [JEP 220] Modular Run-Time Images
Date: 20 November 2014 21:39
Looks good, though I am not an official (R)eviewer.
Charlie
> On Nov 21, 2014, at 9:30 AM, Erik Helin wrote:
>
> Hi all,
>
> this patch changes the debug symbols format on Solaris from STABS
> [0] to DWARF [1] for libjvm.so. Since the supported compiler on Solaris
> has been updated to Oracle
> 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 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 co
On 2014-11-19 18:49, Andrew Haley wrote:
I think this covers everything that reviewers have mentioned:
http://cr.openjdk.java.net/~aph/aarch64-8064357-4/
Andrew.
Almost there! :-)
1) Comment in config.sub identifies it as config.guess.
2) As as understand it, your first attempt is to just
Hi all,
this patch changes the debug symbols format on Solaris from STABS
[0] to DWARF [1] for libjvm.so. Since the supported compiler on Solaris
has been updated to Oracle Solaris Studio 12.3 [2], the STABS debug format
is now deprecated in the supported compiler [3]:
-xdebugformat=stabs gener
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
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 part
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 rmic
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
31 matches
Mail list logo
