Re: RFR: 8276550: Use SHA256 hash in build.tools.depend.Depend

[Andrew John Hughes]

On Wed, 3 Nov 2021 11:54:39 GMT, Aleksey Shipilev  wrote:

> [JDK-8182285](https://bugs.openjdk.java.net/browse/JDK-8182285) added the 
> incremental build capabilities for modules, by hashing the APIs of each 
> module.
> 
> The original change uses MD5, which is quite weak, and 
> [JDK-8214483](https://bugs.openjdk.java.net/browse/JDK-8214483) allows 
> `MessageDigest` to have no MD5 implementation. This is the cause of some 
> build failures when using a FIPS-compliant boot JDK that has no MD5 
> implementation. I suggest we switch to the latest available hash instead.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug build completes
>  - [x] Linux x86_64 fastdebug build times do not regress

SHA-256 is the right choice here from the small list of required algorithms in 
the boot JDK. MD5 has already been removed from the list of required algorithms 
and SHA-1 deprecation for JARs is planned: 
https://java.com/en/jre-jdk-cryptoroadmap.html

-

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6231

Re: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with build.xml [v2]

[Andrew John Hughes]

On Tue, 26 Oct 2021 08:25:35 GMT, Jiří Vaněk  wrote:

>> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
>> lacking the dist directory. This patch is fixing it. Note, that
>> build.xml have correct paths
>
> Jiří Vaněk has refreshed the contents of this pull request, and previous 
> commits have been removed. The incremental views will show differences 
> compared to the previous content of the PR.

Marked as reviewed by andrew (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6068

Re: RFR: 8275872: Sync J2DBench run and analyze Makefile targets with build.xml

[Andrew John Hughes]

On Thu, 21 Oct 2021 17:04:08 GMT, Jiří Vaněk  wrote:

> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
> lacking the dist directory. This patch is fixing it. Note, that
> build.xml have correct paths

I've filed https://bugs.openjdk.java.net/browse/JDK-8275872 and am happy to 
sponsor this minor change.
@judovana, please update the summary with the bug ID. Thanks.

-

PR: https://git.openjdk.java.net/jdk/pull/6068

Re: RFR: 8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux [v3]

[Andrew John Hughes]

On Tue, 16 Mar 2021 16:56:22 GMT, Phil Race  wrote:

>> From a build perspective this partially reverts 
>> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
>> the harfbuzz sources separate and still supports building and running 
>> against a system harfbuzz which is only of interest or relevance on Linux.
>> 
>> I ended up having to go this way because its is the least unsatisfactory 
>> solution.
>> I did not want us to build a devkit to link against a system linux only to 
>> find we couldn't use it at runtime
>> because too many systems have to old a version of harfbuzz.
>> 
>> This solves the Manjaro Linux problem and I've manually verified building 
>> against a system hardbuxz on Ubuntu 20.10
>> 
>> There are couple of incidental fixes in here too
>> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building 
>> against a system version
>> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory 
>> needed to build the bundled copy
>> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502
>
> Phil Race has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

Yes, it would fail at runtime, perhaps in subtle ways if the issue is not a 
missing function but a difference in behaviour.

In the scenario I'm considering, the build and runtime environments are 
effectively the same, as we're building packages for Fedora or RHEL on a 
specific version of that OS, which is then provided for that OS alone. We tend 
to use system libraries where possible as we know the library is going to be 
the same or newer than what we built against, and we benefit from fixes to the 
system library without rebuilding OpenJDK.

Rather than relying on failures being found in an older environment at runtime, 
I'd like the build to check it is being built against is suitable. With that 
early build failure, we can then flip those builds to using the in-tree library.

You do, however, make a good point that this check can be overridden at runtime 
if the build is run on a different system. So, if possible, it would be good to 
also have a runtime check if there is some clear entry point to add one.

I'll try and look into a fix for both once the October security update cycle is 
out of the way. That's taking up most of my time right now.

-

PR: https://git.openjdk.java.net/jdk/pull/2982

Re: RFR: 8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux [v3]

[Andrew John Hughes]

On Tue, 16 Mar 2021 16:56:22 GMT, Phil Race  wrote:

>> From a build perspective this partially reverts 
>> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
>> the harfbuzz sources separate and still supports building and running 
>> against a system harfbuzz which is only of interest or relevance on Linux.
>> 
>> I ended up having to go this way because its is the least unsatisfactory 
>> solution.
>> I did not want us to build a devkit to link against a system linux only to 
>> find we couldn't use it at runtime
>> because too many systems have to old a version of harfbuzz.
>> 
>> This solves the Manjaro Linux problem and I've manually verified building 
>> against a system hardbuxz on Ubuntu 20.10
>> 
>> There are couple of incidental fixes in here too
>> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building 
>> against a system version
>> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory 
>> needed to build the bundled copy
>> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502
>
> Phil Race has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

You mention that "too many systems have to old a version of harfbuzz".
Is the required version defined somewhere? There's no check in configure for 
either a version or a required symbol:
https://github.com/openjdk/jdk/blob/cbffecc61e4a9ac1172926ef4f20d918d73adde9/make/autoconf/lib-bundled.m4#L291

With undefined symbols also being left to runtime (hence why JDK-8272332 
doesn't show up during build), it seems this could lead to sporadic runtime 
failures if OpenJDK is unknowingly built against a harfbuzz that is too old.

-

PR: https://git.openjdk.java.net/jdk/pull/2982

Re: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

[Andrew John Hughes]

On Thu, 9 Sep 2021 14:31:19 GMT, Magnus Ihse Bursie  wrote:

>> Currently, the build system defaults the libjvm.so location to "server".  
>> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We 
>> need to see if moving the libjvm.so to a proper location breaks anything. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 Zero build
>>  - [x] Linux x86_64 Zero bootcycle-images
>>  - [ ] Linux x86_64 Zero `tier1`
>
> And as for @dholmes-ora comment: I'm not sure who "own" zero at this point in 
> time. Aleksey has made a lot of the zero patches lately; does that not count? 
> Are you thinking about any specific person that needs to weight in on this?

> > @magicus every "port" in OpenJDK is supposed to have a clear owner and 
> > support system. Zero has been somewhat lacking in that area but there were 
> > enough people to keep it surviving. Now I'm not so sure. Does Zero have an 
> > active user community? Developer community? If so they are the ones who 
> > need to assess this change.
> 
> FWIW, Zero had fallen into Red Hat hands for support. The official lead (if 
> you look at Census) is Gary Benson, who is not active in this project 
> anymore. Since then, it was mostly supported by RH folks (like me) with 
> contributions from Debian, Tencent, Huawei, Alibaba -- mostly because all of 
> us have arch ports that do not have full-blown Server VMs yet.

For clarity, Gary was a part of the Red Hat Java team at the time, so it has 
always been a Red Hat project. At the time, the only JIT ports in OpenJDK were 
x86, x86-64 and SPARC, so the other architectures Red Hat supported (ppc, 
ppc64, s390, s390x) needed some way to at least build and run to allow OpenJDK 
packages to be shipped, even if end users desiring greater performance used 
some other JDK.

As OpenJDK has gained further JIT ports, the use of Zero has declined in 
response. For example, we can build OpenJDK 17 on every architecture we need 
without using Zero, so it's not going to receive that kind of "you broke our 
build" testing any more. It is still used for 8u & 11u, and is definitely worth 
keeping alive to help bootstrap any new ports.

So, in short, the owner has always been and remains Red Hat, even if the 
individual personnel have changed. The formal project represents a time when it 
was maintained outside the mainline OpenJDK, so there has been no need to 
update that for a long time, as any JDK project committer can make changes to 
the code in the main JDK project.

> 
> I have put things in motion to claim the leadership more formally. I do have 
> to note, though, that over the last few years of me whipping Zero into shape, 
> this is the first time anyone asked the formal governance question, which 
> must tell us something about how much we care about ownership formalities 
> here ;)

Most of the OpenJDK committers at Red Hat have pushed Zero fixes at some time, 
myself included, as need has arisen. This has the first time this has been 
raised to my knowledge.

Regarding this change itself, I think it's fine for trunk, where there's time 
to shake out any issues for OpenJDK 18, but I wouldn't want to backport it. 
These kind of changes tend to throw up things only when someone's application 
breaks, and, at least if that's a new JDK version, that's somewhat expected.

-

PR: https://git.openjdk.java.net/jdk/pull/5440

Re: RFR: 8271148: static-libs-image target --with-native-debug-symbols=external doesn't produce debug info

[Andrew John Hughes]

On Thu, 22 Jul 2021 16:43:26 GMT, Severin Gehwolf  wrote:

> Hi!
> 
> Please review this tiny patch which removes the special casing of 
> `--with-native-debug-symbols=external` for the static libs build. I don't see 
> why this is needed. If no debug symbols are wanted 
> `--with-native-debug-symbols=none` can be used to achieve the same effect. 
> Therefore, I propose to remove this hunk.
> 
> Testing: Inspecting of the log files and seeing that `-g` switch is there. 
> Run the reproducer test on the resulting static libraries.
> 
> Thoughts?

> Yes. Are you suggesting that somebody is relying on these exact semantics? 
> Configure **once** with `--with-native-debug-symbols=external` and expect 
> static libs to have _no_ debuginfo (neither inline nor in an external file) 
> while shared bits should have them in external files? That use case would 
> still be possible by using two configurations. One with 
> `--with-native-debug-symbols=external` and one with 
> `--with-native-debug-symbols=none` and building only the needed targets each.

Whereas, on the other hand, there is currently no option for someone who sets 
--with-native-debug-symbols=external and, rightly, expects the static libraries 
to have external debuginfo files.

-

PR: https://git.openjdk.java.net/jdk/pull/4876

Integrated: JDK-8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags

[Andrew John Hughes]

On Wed, 20 Jan 2021 04:29:52 GMT, Andrew John Hughes  wrote:

> The latest GCC fails if -fcf-protection is used with an x86 (32-bit) target 
> that doesn't support CMOV:
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/config/i386/i386-options.c;h=a70f6edf7b0bfa6994db372c2507dbacb5526646;hp=6819a04238965f0ad63b10323823caa2fb8b147c;hb=77d372abec0fbf2cfe922e3140ee3410248f979e;hpb=5ebdd53534db25401473db5f6a0ad30f41410241
> 
> At least back to OpenJDK 11, the JDK build forces -march=i586 and the build 
> fails with '-fcf-protection is not compatible with this target'
> 
> This patch uses -march=i686 instead if -fcf-protection is detected in the 
> compiler flags. It also makes it clear which is being set in the configure 
> output, rather than silently setting the flag.

This pull request has now been integrated.

Changeset: 07851474
Author:Andrew John Hughes 
URL:   https://git.openjdk.java.net/jdk/commit/07851474
Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod

8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler 
flags

Use -march=i686 instead of -march=i586 if -fcf-protection is passed to the 
build as CMOV is required

Reviewed-by: erikj

-

PR: https://git.openjdk.java.net/jdk/pull/2153

RFR: JDK-8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags

[Andrew John Hughes]

The latest GCC fails if -fcf-protection is used with an x86 (32-bit) target 
that doesn't support CMOV:

https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/config/i386/i386-options.c;h=a70f6edf7b0bfa6994db372c2507dbacb5526646;hp=6819a04238965f0ad63b10323823caa2fb8b147c;hb=77d372abec0fbf2cfe922e3140ee3410248f979e;hpb=5ebdd53534db25401473db5f6a0ad30f41410241

At least back to OpenJDK 11, the JDK build forces -march=i586 and the build 
fails with '-fcf-protection is not compatible with this target'

This patch uses -march=i686 instead if -fcf-protection is detected in the 
compiler flags. It also makes it clear which is being set in the configure 
output, rather than silently setting the flag.

-

Commit messages:
 - JDK-8259949: x86 32-bit build fails when -fcf-protection is passed in the 
compiler flags

Changes: https://git.openjdk.java.net/jdk/pull/2153/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2153&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259949
  Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2153.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2153/head:pull/2153

PR: https://git.openjdk.java.net/jdk/pull/2153

Re: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b

[Andrew John Hughes]

On Tue, 13 Oct 2020 11:32:54 GMT, Kiran Sidhartha Ravikumar 
 wrote:

>> Looks good. I think we should release-note the removal of the 
>> "US/Pacific-New" Link on the off chance that some
>> production/testing system is looking for such a zone.
>
> Thanks for the review everyone, I have added a release note to the bug. I 
> will integrate the changes

Looks like we both reached the same patch for this one independently :)
systemv was removed from tzdata some time ago and wasn't even being read by the 
JDK as far as I could see. Its contents
are duplicated in jdk11_backward anyway. Good to see both it and pacificnew 
being removed. In the unlikely event the
removal of Pacific_New is problematic, it could be added to jdk11_backward as 
well, but it seems very unlikely.

-

PR: https://git.openjdk.java.net/jdk/pull/602

Re: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to remove unused code

[Andrew John Hughes]

On 13/02/2020 11:48, Baesken, Matthias wrote:
> Ping - any reviews ?
> 
> Thanks, Matthias
> 
> From: Baesken, Matthias
> Sent: Dienstag, 11. Februar 2020 10:24
> To: jdk-updates-...@openjdk.java.net; 'build-dev@openjdk.java.net' 
> 
> Subject: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to 
> remove unused code
> 
> Hello , please review  the downport of   "8234525: enable link-time 
> section-gc for linux s390x to remove unused code"   to jdk11 .
> 
> My change from jdk/jdk  did not apply directly and I had to adjust it 
> slightly .
> 
> 
> 
> 
> Bug  and  jdk/jdk change :
> 
> https://bugs.openjdk.java.net/browse/JDK-8234525
> https://hg.openjdk.java.net/jdk/jdk/rev/c04fa10636fd
> 
> 
> Adjusted change for jdk11u-dev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.0_jdk11/
> 
> 
> Original review thread :
> 
> https://mail.openjdk.java.net/pipermail/build-dev/2019-November/026326.html
> 
> 
> Thanks, Matthias
> 

In the original patch, the lines are added after
TOOLCHAIN_CFLAGS_JDK_CONLY. In the 11u version, they seem to have
needlessly moved above it.

Otherwise, looks good.

Regarding the patch itself, are these flags only useful when the s390x
port is present or would they be advantageous on older versions where
s390x is still using the Zero assembler port?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [8u] RFR: 8227397: Add --with-extra-asflags configure option

[Andrew John Hughes]

On 27/09/2019 16:48, Severin Gehwolf wrote:
> Hi,
> 
> Could I please get a review of this 8u build change backport which adds
> --with-extra-asflags to OpenJDK 8u. At Red Hat, we need to pass certain
> assembler only flags for some builds. For example "-Wa,--generate-
> missing-build-notes=yes", to assembly files only. As the build system
> is different in 8u over 11u I've re-done the patch.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8227397
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227397/jdk8/01/
> 
> Testing: Built with --with-extra-asflags=-Wa,--generate-missing-build-
> notes=yes on Linux x86_64, confirmed linux_x86_64.s gets assembled with
> the flag and only that file.
> 
> I've omitted the windows portion of passing as flags to the hotspot
> build as I've no idea how. Contributions welcome if that should get
> included.
> 
> Thoughts?
> 
> Thanks,
> Severin
> 

Looks ok to me.

As to the Windows side, it seems there are no ASFLAGS rules at all nor
any assembly files:

$ grep -r 'ASFLAGS' hotspot/make/
hotspot/make/aix/makefiles/xlc.make:ASFLAGS+= $(ARCHFLAG)
hotspot/make/aix/makefiles/rules.make:AS.S= $(AS) $(ASFLAGS)
hotspot/make/solaris/makefiles/sparcWorks.make:ASFLAGS += $(AS_ARCHFLAG)
hotspot/make/solaris/makefiles/sparcv9.make:ASFLAGS += $(AS_ARCHFLAG)
hotspot/make/solaris/makefiles/sparc.make:ASFLAGS += $(AS_ARCHFLAG)
hotspot/make/solaris/makefiles/gcc.make:ASFLAGS+= $(ARCHFLAG)
hotspot/make/solaris/makefiles/gcc.make:ASFLAGS += -march=k8  -march=amd64
hotspot/make/solaris/makefiles/rules.make:AS.S= $(AS) $(ASFLAGS)
hotspot/make/bsd/makefiles/sparcWorks.make:ASFLAGS+= $(ARCHFLAG)
hotspot/make/bsd/makefiles/gcc.make:ASFLAGS+= $(ARCHFLAG)
hotspot/make/bsd/makefiles/gcc.make:ASFLAGS += -x assembler-with-cpp
hotspot/make/bsd/makefiles/rules.make:AS.S= $(AS) $(ASFLAGS)
hotspot/make/linux/makefiles/sparcWorks.make:ASFLAGS+= $(ARCHFLAG)
hotspot/make/linux/makefiles/gcc.make:ASFLAGS+= $(ARCHFLAG)
hotspot/make/linux/makefiles/gcc.make:  ASFLAGS+=
$(ASFLAGS_DEBUG_SYMBOLS)
hotspot/make/linux/makefiles/rules.make:AS.S= $(AS) $(ASFLAGS)

$ find hotspot/src/ -name '*.s'
hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s
hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_32.s
hotspot/src/os_cpu/solaris_sparc/vm/solaris_sparc.s
hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_32.s
hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s
hotspot/src/os_cpu/linux_x86/vm/linux_x86_64.s
hotspot/src/os_cpu/linux_x86/vm/linux_x86_32.s
hotspot/src/os_cpu/linux_sparc/vm/linux_sparc.s

so it looks like assembly support would need to be there first before
making this change on top.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

RFR: [8u] 8141570: Fix Zero interpreter build for --disable-precompiled-headers

[Andrew John Hughes]

This is the first of a series of four changes to support -Wreturn-type
in OpenJDK 8u. The -Wreturn-type warning catches instances where control
flow exits a non-void function without returning a value. This can
combine with compiler optimisations in some cases to cause runtime
crashes. The warning is turned on by default in GCC 8 [0], causing the
build to fail if it is not explicitly disabled.

The subsequent changes are JDK-8062808 to apply the warning and fix
issues in the default build, JDK-8143245 to fix issues in the Zero build
and JDK-8197981 to fix one remaining Zero issue on 32-bit platforms only.

This change ensures the Zero build is not broken by 8062808 by disabling
-Wreturn-type in the Zero makefile.

Changes in the backport process:

* The G1 changes are dropped as 8u does not contain JDK-8073013, which
introduces g1EvacStats.*
* I've changed the ifeq ($(USE_CLANG), true) to ifeq
($(JVM_VARIANT_ZEROSHARK), true). There seems to have been a mistake in
the original patch which equated LLVM with clang. What is actually
referred to by "some version of llvm do not like -Wundef" is the LLVM
headers that Shark is built against, not the clang compiler which also
uses LLVM. This made its way through to the new HotSpot build in OpenJDK
9 & 10, but is gone as of JDK-8198724 in OpenJDK 11 and later.

This backport has been in IcedTea since 3.8.0 (2018-05-29) [1] and our
RHEL RPMs since 2018-06-16 without issue. Builds of current 8u-dev on
x86_64 with Zero release and Zero slowdebug succeeded.

[0] https://gcc.gnu.org/gcc-8/changes.html
[1] https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3548
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u

[Andrew John Hughes]

On 30/07/2019 09:48, Andrew Dinn wrote:
> On 29/07/2019 19:30, Aleksey Shipilev wrote:
>> On 7/29/19 7:37 PM, Severin Gehwolf wrote:
>>> So, in light of the changed build system in JDK 9+, and the rather
>>> small changes in this patch (on the grand scheme of things), it seems
>>> reasonable to implement this feature in the way proposed. It's a JDK 8u
>>> *enhancement* after all.
>>
>> I am with Severin here. The lack of acceptance test profile in 8u is 
>> severely impeding 8u
>> backporting work. I personally keep Severin's patches applied at all times 
>> in my local patch queue,
>> because that is the only way I can have 8u coverage more or less similar to 
>> what I do for 11u backports.
>>
>> Langtools build changes do not look bad, and they are pretty isolated from 
>> the rest of build system,
>> which means we are not risking regressing important stuff.
> I agree that this is needed. I also understand why Andrew is loath to
> see changes that are not upstream. However, in this case I don't think
> we can avoid adding changes that cause a difference from upstream.
> 

I wouldn't say it's as extreme as loathing, but, if a big chunk of code
is being added, I just would like to know its origins, and, if they are
indeed new in this patch, give them the more through examination needed.

If I appear overly critical, put it down to a decade of doing such
backports and having had to work out where such forks in the codebase
come from, often on very tight deadlines. I'm trying to minimise
potential later angst at the expense of a little more perspiration now.

> The upstream test make system is implemented very differently, as
> Severin explained. He actually omitted mention of one important detail.
> From jdk9 onwards it is organised in one tree rather than separate
> subtrees. IN consequence the code Severin is replicating in the jdk8u
> langtools/test make file does actually exist in upstream jdk11u but it
> is in a /shared/ file (test/make/TestCommon.gmk). For what loosk liek a
> very weird reason this shared file is not directly included in the
> langtools/test make file (langtools seems to expect the test process to
> pirate on the jdk test make process using a different path to the test
> files). Anyway, it is clear that this sharing (or, indeed, pirating on
> the jdk make process) is not an option in jdk8u because the make
> processes run in separate trees. So, replicating the shared code seems
> to be the only option.

And, thanks, this is the answer I've been searching for. The langtools
additions do seem to have been copied from the other versions, which, in
turn, were moved to a shared location in 9 by JDK-8170629 [0] [1] [2]
[3] [4]. That makes sense and I'm fine with that.

For future reference, a lot of this back-and-forth could probably have
been avoided if the process to arrive at such changes had been explained
from the start.

> 
> regards,
> 
> 
> Andrew Dinn
> ---
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 

[0] https://hg.openjdk.java.net/jdk/jdk/rev/26156e756dfa
[1] https://hg.openjdk.java.net/jdk/jdk/rev/8dcc83c2d40e
[2] https://hg.openjdk.java.net/jdk/jdk/rev/ccef74161219
[3] https://hg.openjdk.java.net/jdk/jdk/rev/2435ff181f94
[4] https://hg.openjdk.java.net/jdk/jdk/rev/2ac2a6ef14a6
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u

[Andrew John Hughes]

On 29/07/2019 11:10, Severin Gehwolf wrote:
> On Mon, 2019-07-29 at 10:19 +0100, Andrew Dinn wrote:
>> On 26/07/2019 18:32, Andrew John Hughes wrote:
>>> On 26/07/2019 16:53, Severin Gehwolf wrote:
> [...]
>>>>
>>>>> What exactly is being pushed
>>>>> here?
>>>>
>>>> The following 4 patches:
>>>>
>>>> jdk:   
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/
>>>> hotspot:   
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/
>>>> langtools: 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/
>>>> top:   
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/
>>>>
>>>> Each of them has a reference to a plain patch file if you prefer to
>>>> review that.
>>>>
>>>> Thanks,
>>>> Severin
>>>>
>>>
>>> Ok. HotSpot, JDK & top look fine, but there seem to be a lot of changes
>>> in langtools. Are these original changes to this patch or are they
>>> backports? Is there a reason langtools needs so much more work than the
>>> others?
>> The langtools Makefile changes appear to be larger because they required
>> adding a load of definitions/macros that are already present in the
>> Makefiles in the other trees (i.e. AWK, CAT etc, ZIP_UP_RESULTS,
>> BUNDLE_UP_AND_EXIT etc). These changes look ok to me.
> 
> Yes, exactly. The langools Makefile looks *very* different from
> jdk/hotspot. In order to get some unified status of test results across
> all three, these changes were needed. I've opted to make the langools
> Makefile look more like the ones from jdk and hotspot.
> 
> Old "make test" from top-level continues to work with these changes
> (modulo -verbose:nopass=> summary change).
> 
> Anyway, I had another look at this and made 8075546[1] another pre-
> requisite which makes the langtools changes slightly smaller. Updated
> webrevs set, thus, is:
> 
> jdk:   
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/
> hotspot:   
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/
> langtools: 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/05/langtools/webrev/
> top:   
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/
> 
> Thanks,
> Severin
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8075546
> 

Right. That doesn't answer the question as to the origin of the changes.
If I look at the langtools Makefile in OpenJDK 11, it doesn't have these
changes. Should they not go there first if they are needed?

Update releases are primarily for backports, so I'm dubious of anything
that brings in a bunch of apparently new changes without making it clear
why there are needed and why a backport is not appropriate.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u

[Andrew John Hughes]

On 26/07/2019 16:53, Severin Gehwolf wrote:
> Hi Andrew,
> 
> On Fri, 2019-07-26 at 14:46 +0100, Andrew John Hughes wrote:
>> On 25/07/2019 16:02, Severin Gehwolf wrote:
>>
>> snip...
>>
>>>> Done now. I've added fix-request comments/labels to the above bugs and
>>>> rebased on top of them. New jdk changeset:
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/
>>>>
>>>> Test groups definition is the JDK 9 set plus :jdk_jdi test set (part of
>>>> JDK-8198551 in later JDKs). This seems a reasonable test set. Modulo
>>>> added intrinsics testing only relevant for 9+, see JDK-8132855 and JDK-
>>>> 8132854.
>>>>
>>>> OK to push?
>>>
>>> Any more thoughts?
>>>
>>> Thanks,
>>> Severin
>>>
>>
>> This webrev lists three different bug IDs.
> 
> It beats me why webrev lists other bugs. The other two, 8075573 and
> 8075544, were clean backports and were pushed after jdk8u-fix-yes got
> added.
> 
>> What exactly is being pushed
>> here?
> 
> The following 4 patches:
> 
> jdk:   
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/
> hotspot:   
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/
> langtools: 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/
> top:   
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/
> 
> Each of them has a reference to a plain patch file if you prefer to
> review that.
> 
> Thanks,
> Severin
> 

Ok. HotSpot, JDK & top look fine, but there seem to be a lot of changes
in langtools. Are these original changes to this patch or are they
backports? Is there a reason langtools needs so much more work than the
others?
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u

[Andrew John Hughes]

On 25/07/2019 16:02, Severin Gehwolf wrote:

snip...

>>
>> Done now. I've added fix-request comments/labels to the above bugs and
>> rebased on top of them. New jdk changeset:
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/
>>
>> Test groups definition is the JDK 9 set plus :jdk_jdi test set (part of
>> JDK-8198551 in later JDKs). This seems a reasonable test set. Modulo
>> added intrinsics testing only relevant for 9+, see JDK-8132855 and JDK-
>> 8132854.
>>
>> OK to push?
> 
> Any more thoughts?
> 
> Thanks,
> Severin
> 

This webrev lists three different bug IDs. What exactly is being pushed
here?
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [8u] RFR: 8210761: libjsig is being compiled without optimization

[Andrew John Hughes]

On 10/07/2019 10:24, Severin Gehwolf wrote:
> Hi Christoph,
> 
> On Wed, 2019-07-10 at 09:08 +, Langer, Christoph wrote:
>> Hi Severin,
>>
>> You made a little mistake. It must be "-xO4" instead of "-x04" in the
>> Solaris build file (It's the letter O instead of the number 0) 😉
> 
> Sigh. Take 5:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/05/webrev/
> 
> Thanks again for your help!
> 
> Cheers,
> Severin
> 

Looks good to me. I had a look to see if there was a cleaner way of
getting the right flags for Solaris, but it seems this is part of the
whole misuse of CFLAGS as C++ flags that is all over the old HotSpot
build. So this is fine.

Incidentally, make/solaris/makefiles/sparcWorks.make is full of
conditionals to switch between -xO4 and -xO3 for different architectures
and compiler versions, even down to the single file. I don't know how
valid most of this still is, but best to leave it alone at this stage.

Probably my favourite bit of bit rot is:

# Pick which compiler is validated

ifeq ($(JRE_RELEASE_VER),1.6.0)
  # Validated compiler for JDK6 is SS11 (5.8)

  VALIDATED_COMPILER_REVS   := 5.8
  VALIDATED_CC_COMPILER_REVS := 5.8
else
  # Validated compiler for JDK7 is SS12 update 1 + patches (5.10)

  VALIDATED_COMPILER_REVS   := 5.10
  VALIDATED_CC_COMPILER_REVS := 5.10
endif

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u

[Andrew John Hughes]

On 28/06/2019 10:52, Severin Gehwolf wrote:
> Hi Andrew,
> 
> On Thu, 2019-06-27 at 17:36 +0100, Andrew John Hughes wrote:
>>
>> On 22/05/2019 17:34, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> Could I please get reviews for this minimal implementation of a tier1-
>>> like test set for JDK 8u? The implementation is rather barebones as I
>>> don't think it's worth rewriting the build system just for a command
>>> that runs a certain set of tests across a select set of repositories.
>>> I've re-used existing work in Makefiles as much as possible. After this
>>> patch one can do:
>>>
>>> $ make test TEST="tier1"
>>>
>>> Inspiration came from JDK 11u's tier1. As for prior art to this, I've
>>> only found "make test" to be working for JDK 8u from the top level.
>>> Yet, it doesn't run any hotspot tests, exits with a zero code on test
>>> failures and doesn't present a summary at the end. Overall not a nice
>>> developer experience.
>>>
>>> This patch makes it easier for a developers tests. It presents a
>>> summary at the end, returns non-zero on test failures so this can get
>>> used in CI and runs hotspot tests.
>>>
>>> As a follow-on we can work on fixing/excluding tests so that we always
>>> have a passing set of tests for developers to run before a checkin.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222737
>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/
>>> (includes changes to top/hotspot/jdk/langtools repos)
>>>
>>> Example excerpt from a run:
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Severin
>>>
>>
>> Is there a reason for creating new tier definitions here rather than
>> backporting the existing ones?
> 
> Yes. The tests in JDK 8 are significantly different from JDK 11. Most
> notably the number of tests available and defined test groups.
> Backporting the JDK 11 changes seems like fitting a square peg into a
> round hole.
> 
> The JDK 8u "tier1" could only be a rough approximation of the JDK 11
> "tier1" at best. There is also no intention to make the test output
> 100% identical to JDK 11 as bringing back those changes would be too
> invasive.
> 
> I believe the proposed patch is a reasonable minimal patch which aids
> 8u developer's testing.
> 
>> https://bugs.openjdk.java.net/browse/JDK-8075543
>>
>> The subtasks also cover nashorn & jaxp which are missed here. jaxp would
>> need JDK-8065673, JDK-8051540 and friends to convert its tests to jtreg.
> 
> Sure. We can consider adding later tiers in upcoming work. That's not
> the priority, though. Note that tier1 tests in JDK 11 only run
> jdk/lantools/hotspot tests. The intention of this initial patch would
> be to have some testing "baseline" covering a reasonable set of repos
> and tests.
> 
> Thanks,
> Severin
> 

I'm not talking about JDK 11 changes. These are changes in JDK 9.

For example,

https://hg.openjdk.java.net/jdk9/dev/jdk/rev/cd4aea326e89

adds groups to two tiers, all of which exist in 8u as well. It's not
clear where the list in your patch comes from and it appears to add a
bunch of arbitrary other tests beyond the tier 1 defined in the JDK 9
change.

It would make more sense to me to backport JDK-8075544 & JDK-8075573 as
pre-requisites rather than creating completely new definitions.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u

[Andrew John Hughes]

On 22/05/2019 17:34, Severin Gehwolf wrote:
> Hi,
> 
> Could I please get reviews for this minimal implementation of a tier1-
> like test set for JDK 8u? The implementation is rather barebones as I
> don't think it's worth rewriting the build system just for a command
> that runs a certain set of tests across a select set of repositories.
> I've re-used existing work in Makefiles as much as possible. After this
> patch one can do:
> 
> $ make test TEST="tier1"
> 
> Inspiration came from JDK 11u's tier1. As for prior art to this, I've
> only found "make test" to be working for JDK 8u from the top level.
> Yet, it doesn't run any hotspot tests, exits with a zero code on test
> failures and doesn't present a summary at the end. Overall not a nice
> developer experience.
> 
> This patch makes it easier for a developers tests. It presents a
> summary at the end, returns non-zero on test failures so this can get
> used in CI and runs hotspot tests.
> 
> As a follow-on we can work on fixing/excluding tests so that we always
> have a passing set of tests for developers to run before a checkin.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8222737
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/
> (includes changes to top/hotspot/jdk/langtools repos)
> 
> Example excerpt from a run:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt
> 
> Thoughts?
> 
> Thanks,
> Severin
> 

Is there a reason for creating new tier definitions here rather than
backporting the existing ones?

https://bugs.openjdk.java.net/browse/JDK-8075543

The subtasks also cover nashorn & jaxp which are missed here. jaxp would
need JDK-8065673, JDK-8051540 and friends to convert its tests to jtreg.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [8u] RFR: 8210761: libjsig is being compiled without optimization

[Andrew John Hughes]

On 26/06/2019 14:02, Severin Gehwolf wrote:
> On Wed, 2019-06-26 at 13:04 +0100, Andrew John Hughes wrote:
>>
>> On 25/06/2019 10:04, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> Could somebody please review this 8u backport? The build system in 8 is
>>> different, especially hotspot makefiles. Note, libjsig.so is part of
>>> the hotspot build. The patch is different in 8 (over 11) due to this
>>> reason. This is a Linux-only change and should be low risk. Thoughts?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210761
>>> webrev: 
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/01/webrev/
>>>
>>> Change in JDK 11: 
>>> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/e7aa96dc0b1e
>>>
>>> Testing: Manual build of slowdebug/fastdebug/release on x86_64.
>>> Fastdebug/release builds receive the -O3 flag, slowdebug not. As
>>> expected.
>>>
>>> Thanks,
>>> Severin
>>>
>>
>> The 11u fix applies to all 'unix' platforms, as far as I can see. Should
>> the 8u equivalent not also be applied to the solaris, bsd and aix
>> subdirectories as well for consistency?
> 
> Here you go:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/02/webrev/
> 

This looks good. Thanks.

> I cannot really test on bsd, solaris or aix, though :( Appreciate any
> testers for those platforms.

Yeah, I expected this. I think we have two choices with these kind of
patches; either we apply changes only for GNU/Linux & let it diverge
from other platforms, or, when the fix is identical, as in this case, we
apply the fix across them all.

I think the latter is the better solution, especially when it is applied
to all platforms on the original JDK version, as it leaves anyone
working on that platform at a later date with just fixing any problems
raised by the changes, rather than being faced with having to go through
a backlog of changes.

As it stands, it sounds like only *BSD will be in this situation anyway,
thanks to Christoph's testing. Assuming that goes fine, I'm happy for
this to be pushed.

> 
> Thanks,
> Severin
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [8u] RFR: 8210761: libjsig is being compiled without optimization

[Andrew John Hughes]

On 25/06/2019 10:04, Severin Gehwolf wrote:
> Hi,
> 
> Could somebody please review this 8u backport? The build system in 8 is
> different, especially hotspot makefiles. Note, libjsig.so is part of
> the hotspot build. The patch is different in 8 (over 11) due to this
> reason. This is a Linux-only change and should be low risk. Thoughts?
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210761
> webrev: 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/01/webrev/
> 
> Change in JDK 11: 
> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/e7aa96dc0b1e
> 
> Testing: Manual build of slowdebug/fastdebug/release on x86_64.
> Fastdebug/release builds receive the -O3 flag, slowdebug not. As
> expected.
> 
> Thanks,
> Severin
> 

The 11u fix applies to all 'unix' platforms, as far as I can see. Should
the 8u equivalent not also be applied to the solaris, bsd and aix
subdirectories as well for consistency?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [8u] 8226392: Launcher should not enable legacy stdio streams on GNU/Linux (glibc)

[Andrew John Hughes]

On 24/06/2019 15:52, Florian Weimer wrote:
> * Andrew John Hughes:
> 
>> On 24/06/2019 14:54, Florian Weimer wrote:
>>> * Severin Gehwolf:
>>>
>>>> Could I please get reviews for this 8u only change? The JDK 8u build
>>>> logic for launcher files includes linker version script files (a.k.a
>>>> mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
>>>> as local. When the symbol is not visible to the dynamic loader, glibc
>>>> will use a legacy stdio implementation instead. This is a historic, x86
>>>> (32bit) only glibc issue, I've been told.
>>>
>>> It may impact other historic GNU/Linux targets, but I don't think they
>>> have OpenJDK ports.  POWER and Z are 64-bit only, I assume.
>>>
>>> Thanks,
>>> Florian
>>>
>>
>> OpenJDK is built on s390 (31-bit) and ppc (32-bit) for RHEL 7.
> 
> Oh.  I did not know this.
> 
> I looked at a recent internal s390 build, and found this:
> 
> Symbol table [ 6] '.dynsym' contains 8 entries:
>  1 local symbol  String table: [ 7] '.dynstr'
>   Num:Value   Size TypeBind   Vis  Ndx Name
> 0:   0 NOTYPE  LOCAL  DEFAULTUNDEF 
> 1:   0 NOTYPE  WEAK   DEFAULTUNDEF 
> _ITM_deregisterTMCloneTable
> 2:   0 NOTYPE  WEAK   DEFAULTUNDEF __gmon_start__
> 3:   0 NOTYPE  WEAK   DEFAULTUNDEF _Jv_RegisterClasses
> 4:   0 NOTYPE  WEAK   DEFAULTUNDEF 
> _ITM_registerTMCloneTable
> 5: 00400474  0 FUNCGLOBAL DEFAULTUNDEF 
> __libc_start_main@GLIBC_2.0 (2)
> 6: 00400494  0 FUNCGLOBAL DEFAULTUNDEF 
> JLI_Launch@SUNWprivate_1.1 (3)
> 7: 004007b8  4 OBJECT  GLOBAL DEFAULT   16 _IO_stdin_used
> 
> Same for a ppc build:
> 
> Symbol table [ 6] '.dynsym' contains 8 entries:
>  1 local symbol  String table: [ 7] '.dynstr'
>   Num:Value   Size TypeBind   Vis  Ndx Name
> 0:   0 NOTYPE  LOCAL  DEFAULTUNDEF 
> 1:   0 NOTYPE  WEAK   DEFAULTUNDEF 
> _ITM_deregisterTMCloneTable
> 2:   0 NOTYPE  WEAK   DEFAULTUNDEF __gmon_start__
> 3:   0 FUNCGLOBAL DEFAULTUNDEF 
> __libc_start_main@GLIBC_2.0 (2)
> 4:   0 FUNCGLOBAL DEFAULTUNDEF 
> JLI_Launch@SUNWprivate_1.1 (3)
> 5:   0 NOTYPE  WEAK   DEFAULTUNDEF _Jv_RegisterClasses
> 6:   0 NOTYPE  WEAK   DEFAULTUNDEF 
> _ITM_registerTMCloneTable
> 7: 17ac  4 OBJECT  GLOBAL DEFAULT   15 _IO_stdin_used
> 
> Any binary which references __libc_start_main@GLIBC_2.0 and which does
> not export _IO_stdin_used in .dynsym (.symtab does not count) has this
> issue, irrespective of the architecture.  The key point is support for
> the glibc 2.0 ABI level (as indicated by the GLIBC_2.0 symbol version).
> Architectures which joined in glibc 2.1 or later do not have this
> fallback code (although the _IO_stdin_used marker symbol is sometimes
> still there, quite unnecessarily).
> 
> So these two builds one does not have the issue.  The build is from May,
> so it can't have Severin's fix yet
> (java-1.8.0-openjdk-1.8.0.222.b04-1.el7, in case you wonder), and the
> i686 build does show the issue.
> 
> Thanks,
> Florian
> 

Ah good, sounds like it is just an x86-32 issue then.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [8u] 8226392: Launcher should not enable legacy stdio streams on GNU/Linux (glibc)

[Andrew John Hughes]

On 24/06/2019 14:48, Severin Gehwolf wrote:
> Hi,
> 
> Could I please get reviews for this 8u only change? The JDK 8u build
> logic for launcher files includes linker version script files (a.k.a
> mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
> as local. When the symbol is not visible to the dynamic loader, glibc
> will use a legacy stdio implementation instead. This is a historic, x86
> (32bit) only glibc issue, I've been told.
> 
> The suggested fix is to mark _IO_stdin_used as global in the linker
> version script on x86 (32bit) so that the non-legacy implementation of
> stdio will be used for launcher files of OpenJDK 8u.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8226392
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226392/01/webrev/
> 
> Testing: "eu-readelf --symbols=.dynsym /path/to/java | grep _IO". I.e. manual
>  on a x86 build.
> 
> Note that JDK 11+ have _IO_stin_used visible already.
> 
> I can add the same to other arches map files if that's preferred (it
> should be harmless). For now, I've opted to add it to x86 only where we
> know this is a problem.
> 
> Thanks,
> Severin
> 

Looks good.

Please flag the bug with jdk8u-fix-request to request approval.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [8u] 8226392: Launcher should not enable legacy stdio streams on GNU/Linux (glibc)

[Andrew John Hughes]

On 24/06/2019 14:54, Florian Weimer wrote:
> * Severin Gehwolf:
> 
>> Could I please get reviews for this 8u only change? The JDK 8u build
>> logic for launcher files includes linker version script files (a.k.a
>> mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
>> as local. When the symbol is not visible to the dynamic loader, glibc
>> will use a legacy stdio implementation instead. This is a historic, x86
>> (32bit) only glibc issue, I've been told.
> 
> It may impact other historic GNU/Linux targets, but I don't think they
> have OpenJDK ports.  POWER and Z are 64-bit only, I assume.
> 
> Thanks,
> Florian
> 

OpenJDK is built on s390 (31-bit) and ppc (32-bit) for RHEL 7.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: RFR: [8u] JDK-8223219: Backport of JDK-8199552 to OpenJDK 8 leads to duplicate -fstack-protector flags, overriding --with-extra-cflags

[Andrew John Hughes]

On 12/06/2019 20:34, Andrew John Hughes wrote:
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8223219/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223219
> 
> There's quite a long story to this one, more detail of which is in the
> bug report. In short, JDK-8199552 was backported as part of a CPU with
> no review and so little explanation for the changes contained therein,
> which differ from the same change in OpenJDK 11.
> 
> The end result is that -fstack-protector is added for only two
> architectures - x86 and x86_64 - and it ends up appearing twice for the
> JDK part of the build, the second appearance overriding any options
> specified using --with-extra-cflags. This is a problem for distros which
> may want to use -fstack-protector-strong instead. This patch simplifies
> it down to one addition for all architectures.
> 
> We've been using this patch (or a variant of it) since the January CPU
> on all architectures we build on (AArch64, s390, s390x, ppc, ppc64,
> ppc64le, x86 & x86_64) without known issues.
> 
> Before patch:
> 
>  [7] CFLAGS := -Wall -Wno-parentheses -Wextra -Wno-unused
> -Wno-unused-parameter -Wformat=2 -pipe -D_GNU_SOURCE -D_REENTRANT
> -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -fstack-protector
> -D_LP64=1 -D_LITTLE_ENDIAN -DLINUX -DARCH='"amd64"' -Damd64 -DNDEBUG
> -DRELEASE='"1.8.0-internal"' -I/home/andrew/builder/8u-dev/jdk/include
> -I/home/andrew/builder/8u-dev/jdk/include/linux
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/javavm/export
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/javavm/export
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/common
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/native/common
> -O2 -pipe -march=core2 -mno-tls-direct-seg-refs -Wno-error=return-type
> -Wno-error=deprecated-declarations -fno-strict-aliasing
> -fstack-protector -fno-delete-null-pointer-checks -fno-lifetime-dse
> -fPIC -I/home/andrew/builder/8u-dev/jdk/gensrc_headers
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/nativ\
> e/java/lang/fdlibm/include
> 
> After patch (the -fstack-protector duplicate after -fno-strict-aliasing
> is gone):
> 
>  [7] CFLAGS := -Wall -Wno-parentheses -Wextra -Wno-unused
> -Wno-unused-parameter -Wformat=2 -pipe -fstack-protector -D_GNU_SOURCE
> -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LP64=1
> -D_LITTLE_ENDIAN -DLINUX -DARCH='"amd64"' -Damd64 -DNDEBUG
> -DRELEASE='"1.8.0-internal"' -I/home/andrew/builder/8u-dev/jdk/include
> -I/home/andrew/builder/8u-dev/jdk/include/linux
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/javavm/export
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/javavm/export
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/common
> -I/home/andrew/proje\
> cts/openjdk/upstream/jdk8u-dev/jdk/src/solaris/native/common -O2 -pipe
> -march=core2 -ggdb -mno-tls-direct-seg-refs -Wno-error=return-type
> -Wno-error=deprecated-declarations -fno-strict-aliasing
> -fno-delete-null-pointer-checks -fno-lifetime-dse -fPIC
> -I/home/andrew/builder/8u-dev/jdk/gensrc_headers
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/java/lang/fdlibm/include
> 
> Ok to push?
> 
> Thanks,
> 

Ping? Still needs an 8u reviewer.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

RFR: [8u] JDK-8223219: Backport of JDK-8199552 to OpenJDK 8 leads to duplicate -fstack-protector flags, overriding --with-extra-cflags

[Andrew John Hughes]

Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8223219/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8223219

There's quite a long story to this one, more detail of which is in the
bug report. In short, JDK-8199552 was backported as part of a CPU with
no review and so little explanation for the changes contained therein,
which differ from the same change in OpenJDK 11.

The end result is that -fstack-protector is added for only two
architectures - x86 and x86_64 - and it ends up appearing twice for the
JDK part of the build, the second appearance overriding any options
specified using --with-extra-cflags. This is a problem for distros which
may want to use -fstack-protector-strong instead. This patch simplifies
it down to one addition for all architectures.

We've been using this patch (or a variant of it) since the January CPU
on all architectures we build on (AArch64, s390, s390x, ppc, ppc64,
ppc64le, x86 & x86_64) without known issues.

Before patch:

 [7] CFLAGS := -Wall -Wno-parentheses -Wextra -Wno-unused
-Wno-unused-parameter -Wformat=2 -pipe -D_GNU_SOURCE -D_REENTRANT
-D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -fstack-protector
-D_LP64=1 -D_LITTLE_ENDIAN -DLINUX -DARCH='"amd64"' -Damd64 -DNDEBUG
-DRELEASE='"1.8.0-internal"' -I/home/andrew/builder/8u-dev/jdk/include
-I/home/andrew/builder/8u-dev/jdk/include/linux
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/javavm/export
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/javavm/export
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/common
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/native/common
-O2 -pipe -march=core2 -mno-tls-direct-seg-refs -Wno-error=return-type
-Wno-error=deprecated-declarations -fno-strict-aliasing
-fstack-protector -fno-delete-null-pointer-checks -fno-lifetime-dse
-fPIC -I/home/andrew/builder/8u-dev/jdk/gensrc_headers
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/nativ\
e/java/lang/fdlibm/include

After patch (the -fstack-protector duplicate after -fno-strict-aliasing
is gone):

 [7] CFLAGS := -Wall -Wno-parentheses -Wextra -Wno-unused
-Wno-unused-parameter -Wformat=2 -pipe -fstack-protector -D_GNU_SOURCE
-D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LP64=1
-D_LITTLE_ENDIAN -DLINUX -DARCH='"amd64"' -Damd64 -DNDEBUG
-DRELEASE='"1.8.0-internal"' -I/home/andrew/builder/8u-dev/jdk/include
-I/home/andrew/builder/8u-dev/jdk/include/linux
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/javavm/export
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/javavm/export
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/common
-I/home/andrew/proje\
cts/openjdk/upstream/jdk8u-dev/jdk/src/solaris/native/common -O2 -pipe
-march=core2 -ggdb -mno-tls-direct-seg-refs -Wno-error=return-type
-Wno-error=deprecated-declarations -fno-strict-aliasing
-fno-delete-null-pointer-checks -fno-lifetime-dse -fPIC
-I/home/andrew/builder/8u-dev/jdk/gensrc_headers
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/java/lang/fdlibm/include

Ok to push?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

[Andrew John Hughes]

On 29/03/2019 10:51, Langer, Christoph wrote:
> Looks good to me now 😊
> 
>> -Original Message-----
>> From: Andrew John Hughes 
>> Sent: Freitag, 29. März 2019 07:18
>> To: Langer, Christoph ; Severin Gehwolf
>> ; 'jdk8u-...@openjdk.java.net' > d...@openjdk.java.net>; build-dev@openjdk.java.net
>> Subject: Re: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR,
>> BUNDLE_VENDOR, VENDOR, but no configure flag
>>
>>
>>
>> On 28/03/2019 09:30, Langer, Christoph wrote:
>>> Hi,
>>>
>>>>> Revised HotSpot webrev:
>>>>>
>>>>> https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot.02
>>>>
>>>> +++ new/src/share/vm/runtime/vm_version.cpp2019-03-28
>>>> 03:52:51.384737947 +
>>>> @@ -140,7 +140,7 @@
>>>>
>>>>  const char* Abstract_VM_Version::vm_vendor() {
>>>>  #ifdef VENDOR
>>>> -  return XSTR(VENDOR);
>>>> +  return VENDOR;
>>>>
>>>> This looks like the change from JDK-8200115. Have you considered
>>>> backporting this separately? Failing that, we should mention JDK-
>>>> 8200115 in the backport commit message as well.
>>>
>>> I suggest inlining the backport of 8200115 to this commit by adding
>> "8200115: System property java.vm.vendor value includes quotation marks"
>> to the commit message. It will resolve/backport 8200115 as well. Process
>> wise we should probably tag 8200115 with jdk8u-critcal-request and get it
>> approved, though?
>>>
>>> Please also update the copyright years accordingly when pushing.
>>>
>>> Thanks & Best regards
>>> Christoph
>>>
>>
>> Revised version without 8200115 & with copyright updates:
>>
>> https://cr.openjdk.java.net/~andrew/openjdk8/8189761/webrev.02/
>>
>> I bumped the existing copyright where the change was from the original
>> patch. I added our copyright where the changes were unique to this
>> backport (HotSpot only).
>> --
>> Andrew :)
>>
>> Senior Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>> https://keybase.io/gnu_andrew
> 

Thanks. I've now pushed both changes.

I committed the HotSpot change under my own name as there was little
from the original changeset. Hopefully, my changeset addition for
formally recognising backports [0] will be accepted to avoid this issue
in future.

[0] https://bugs.openjdk.java.net/browse/JDK-8221692
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

[Andrew John Hughes]

On 28/03/2019 09:30, Langer, Christoph wrote:
> Hi,
> 
>>> Revised HotSpot webrev:
>>>
>>> https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot.02
>>
>> +++ new/src/share/vm/runtime/vm_version.cpp  2019-03-28
>> 03:52:51.384737947 +
>> @@ -140,7 +140,7 @@
>>
>>  const char* Abstract_VM_Version::vm_vendor() {
>>  #ifdef VENDOR
>> -  return XSTR(VENDOR);
>> +  return VENDOR;
>>
>> This looks like the change from JDK-8200115. Have you considered
>> backporting this separately? Failing that, we should mention JDK-
>> 8200115 in the backport commit message as well.
> 
> I suggest inlining the backport of 8200115 to this commit by adding "8200115: 
> System property java.vm.vendor value includes quotation marks" to the commit 
> message. It will resolve/backport 8200115 as well. Process wise we should 
> probably tag 8200115 with jdk8u-critcal-request and get it approved, though?
> 
> Please also update the copyright years accordingly when pushing.
> 
> Thanks & Best regards
> Christoph
> 

Revised version without 8200115 & with copyright updates:

https://cr.openjdk.java.net/~andrew/openjdk8/8189761/webrev.02/

I bumped the existing copyright where the change was from the original
patch. I added our copyright where the changes were unique to this
backport (HotSpot only).
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

[Andrew John Hughes]

On 28/03/2019 08:51, Severin Gehwolf wrote:
> On Thu, 2019-03-28 at 03:56 +0000, Andrew John Hughes wrote:
>> On 26/03/2019 21:57, Langer, Christoph wrote:
>>> Hi Andrew,
>>>
>>> thanks for doing this backport. I agree, Severin's finding needs to be 
>>> added to hotspot's Unix/Posix vm.make files.
>>
>> Yes, it was missed because it's already there prior to this patch in the
>> 9 and up HotSpot build which is quite different. It also seems to
>> require a change to vm_version.cpp so the value isn't double-quoted.
> 
> Nice catch! This is JDK-8200115, right? Perhaps we should keep
> "XSTR(VENDOR)" in this backport and then also backport JDK-8200115
> separately?
> 

I wasn't aware of that bug until you mentioned it. I came up with the
same fix independently. I was looking at the 10 sources - where 8189761
was first applied - which still has XSTR(VENDOR) and I guess still has
this bug.

I've flagged it with jdk8u-fix-request and jdk8u-critical-request.

https://bugs.openjdk.java.net/browse/JDK-8200115

and will move it to a separate webrev.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: [RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

[Andrew John Hughes]

On 26/03/2019 21:57, Langer, Christoph wrote:
> Hi Andrew,
> 
> thanks for doing this backport. I agree, Severin's finding needs to be added 
> to hotspot's Unix/Posix vm.make files.

Yes, it was missed because it's already there prior to this patch in the
9 and up HotSpot build which is quite different. It also seems to
require a change to vm_version.cpp so the value isn't double-quoted.

> 
> Also, the additional printing of those variables in the Unixish 
> buildtree.make files should be added to windows' make/windows/build.make in 
> target $(variantDir)\local.make.

Ah, I was looking for the equivalent but it's odd that it's not in
make/windows, and so didn't show up with grep.

Revised HotSpot webrev:

https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot.02
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

[RFR] [8u] 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

[Andrew John Hughes]

Bug: https://bugs.openjdk.java.net/browse/JDK-8189761
Webrev(s):
https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot/
https://cr.openjdk.java.net/~andrew/openjdk8/8189761/jdk/
https://cr.openjdk.java.net/~andrew/openjdk8/8189761/root/

This backport is largely clean, bar fuzzing, for the JDK and root
repositories, but needs changes in the HotSpot repository to account for
the older build used in OpenJDK 8 and below. In 8, the HotSpot build is
largely independent of the main configure-based build and so
occasionally duplicates top-level logic.

I've tested this works on GNU/Linux. Due to the different platforms
affected, ideally someone should test this on other platforms,
particularly Windows, to avoid breakage there.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: Build OpenJDK 8 on MacOS Mojave (10.14.3)

[Andrew John Hughes]

On 21/03/2019 15:49, Erik Joelsson wrote:
> I don't think anyone has tried. Just removing the check in configure
> should be simple enough, but I suspect there will be lots of follow-on
> issues.
> 
> /Erik
> 
> On 2019-03-21 03:05, Langer, Christoph wrote:
>> Hi,
>>
>> the Mac experts will probably find my question to be silly and start
>> laughing… but nevertheless, I’m asking it here 😊
>>
>> I was looking into building OpenJDK 8 today on my developer Mac, which
>> runs Mojave (10.14.3). configure immediately tells me, I need Xcode 4.
>> So I was trying to install xcode 4.6.3 – but seems this wouldn’t run
>> on Mojave. What can I do?
>>
>> Ok, on the build requirements page [0], the requirements are
>> documented to be MacOS 10.7 (Lion). However, I’m thinking, since
>> OpenJDK 8 is not completely legacy yet, at least a developer build
>> should be possible on a current operating system. I would accept
>> having to install the oldest running Xcode compiler for sure, but not
>> at all being able to build on a recent MacOS is not good.
>>
>> So, question to the experts: Will it be impossible to bump the build
>> environment because changes would be too complex? Or is there a
>> solution to this which I’m just not aware of?
>>
>> Thank you and Best regards
>> Christoph
>>
>> [0] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>>

Yes, I generally think such version checks are a bad idea, as they only
serve to hide the real errors.

What are the versions of LLVM & clang on Mojave? We may be able to look
at some issues on Linux with the same compiler.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: RFR: [8u] Build failed on Ubuntu 18.04 due to deprecated-declarations warnings

[Andrew John Hughes]

On 19/03/2019 15:09, Martin Buchholz wrote:
> Probably it's because glibc deprecated readdir, and we don't have
> --disable-warnings-as-errors by default?
> 
> (I think warnings should not be errors except as opt-in by openjdk
> developers/maintainers)

I agree, and we've implemented it that way downstream in IcedTea.
At present, 8u doesn't even have the option to toggle this in the
HotSpot build. I can certainly look at providing such an option and that
would be a better, more general fix than turning off one specific warning.

Note that warnings as errors is still the default in jdk/jdk unless xlc
is used:

https://hg.openjdk.java.net/jdk/jdk/file/83cace4142c8/make/autoconf/flags-cflags.m4#l142
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: RFR: [8u] Build failed on Ubuntu 18.04 due to deprecated-declarations warnings

[Andrew John Hughes]

On 19/03/2019 15:09, Martin Buchholz wrote:
> Probably it's because glibc deprecated readdir, and we don't have
> --disable-warnings-as-errors by default?
> 
> (I think warnings should not be errors except as opt-in by openjdk
> developers/maintainers)
> 
> On Tue, Mar 19, 2019 at 7:47 AM Andrew Haley  wrote:
> 
>> On 3/19/19 12:25 PM, Jie Fu wrote:
>>> To fix build failures caused by deprecated-declarations warnings, can we
>>> make this change to jdk8u?
>>
>> This is very GCC-version dependent. We really should probe at configure
>> time for
>> these options.
>>
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. 
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>

If this is because of readdir_r, then that's on my radar to backport
once we've branched for 8u212 (it needs time to soak, so I'm aiming for
8u222). I've prefer we fixed this rather than disabling warnings
unnecessarily.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

RFR: [8u] 8193764: Cannot set COMPANY_NAME when configuring a build

[Andrew John Hughes]

Bug: https://bugs.openjdk.java.net/browse/JDK-8193764
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8193764/webrev.01/

This one applies pretty much as-is, when adjustments are made to use the
jdk-options.m4 file rather than jdk-version.m4, which doesn't exist in
8u. generated-configure.sh is regenerated rather than patched.

I've confirmed that a build using --with-vendor-name=$VENDOR sees
$VENDOR appear in the generated spec.gmk.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: Fwd: [RFR] [8u] 8217753: Enable HotSpot builds on 5.x Linux kernels

[Andrew John Hughes]

On 14/03/2019 15:31, Erik Joelsson wrote:
> Looks good to me.
> 
> /Erik
> 
> On 2019-03-13 17:27, Andrew John Hughes wrote:
>> Forwarding to build-dev for wider review.
>>
>>  Forwarded Message 
>> Subject: [RFR] 8217753: Enable HotSpot builds on 5.x Linux kernels
>> Date: Mon, 11 Mar 2019 07:24:48 +
>> From: Andrew John Hughes 
>> To: 'jdk8u-...@openjdk.java.net' 
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217753
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8217753/webrev.01/
>>
>> This is 8u and below only as it's part of the old HotSpot build replaced
>> in 9+.
>>
>> There's a check in make/linux/Makefile to ensure that a 2.4 or later
>> kernel is being used. This has been extended by JDK-7072341 to
>> accommodate Linux 3.x and JDK-8074312 for 4.x. 5.x is now imminent [0]
>> and the build is broken again [1].
>>
>> Given that 2.4 was released over 18 years ago [2], I think now is the
>> time to just get rid of this check rather than bumping it yet again. If
>> anyone is really trying to build OpenJDK 8 on a 2.2 kernel, I suspect
>> they will encounter other issues than a Makefile check, and it seems far
>> more likely that, if we just add a '5%' check, someone is going to build
>> with Linux 6.x in a few years and hit this same bug again.
>>
>> [0] https://lwn.net/Articles/776034/
>> [1] https://bugs.gentoo.org/675920
>> [2] http://lkml.iu.edu/hypermail/linux/kernel/0101.0/0776.html

Thanks Erik. Pushed:

https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/5af8ec63c21c
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: Fwd: [RFR] [8u] 8220397: JDK-8036003 backport regresses no_strip builds

[Andrew John Hughes]

On 14/03/2019 15:32, Erik Joelsson wrote:
> Looks good.
> 
> /Erik
> 
> On 2019-03-13 17:27, Andrew John Hughes wrote:
>> Forwarding to build-dev for wider review.
>>
>>  Forwarded Message 
>> Subject: [RFR] 8220397: JDK-8036003 backport regresses no_strip builds
>> Date: Mon, 11 Mar 2019 07:33:16 +
>> From: Andrew John Hughes 
>> To: 'jdk8u-...@openjdk.java.net' 
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220397
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220397/webrev.01/
>>
>> When JDK-8036003 was backported, it added a bunch of conditionals in
>> make/common/NativeCompilation.gmk which cause debuginfo to not be
>> generated if no_strip is set. However, the cases for ZIP_DEBUGINFO_FILES
>> were missed, causing the build to fail, because there's no dependency
>> for the .diz target.
>>
>> I suspect this doesn't show up when the new configure option is
>> specified, because ZIP_DEBUGINFO_FILES is toggled appropriately, but it
>> does regress my existing builds which don't specify that option.
>>
>> Simple fix and 8u only.

Thanks Erik. Pushed:

https://hg.openjdk.java.net/jdk8u/jdk8u-dev/rev/5af73acc6b6c
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Fwd: [RFR] [8u] 8220397: JDK-8036003 backport regresses no_strip builds

[Andrew John Hughes]

Forwarding to build-dev for wider review.

 Forwarded Message 
Subject: [RFR] 8220397: JDK-8036003 backport regresses no_strip builds
Date: Mon, 11 Mar 2019 07:33:16 +
From: Andrew John Hughes 
To: 'jdk8u-...@openjdk.java.net' 

Bug: https://bugs.openjdk.java.net/browse/JDK-8220397
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220397/webrev.01/

When JDK-8036003 was backported, it added a bunch of conditionals in
make/common/NativeCompilation.gmk which cause debuginfo to not be
generated if no_strip is set. However, the cases for ZIP_DEBUGINFO_FILES
were missed, causing the build to fail, because there's no dependency
for the .diz target.

I suspect this doesn't show up when the new configure option is
specified, because ZIP_DEBUGINFO_FILES is toggled appropriately, but it
does regress my existing builds which don't specify that option.

Simple fix and 8u only.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Fwd: [RFR] [8u] 8217753: Enable HotSpot builds on 5.x Linux kernels

[Andrew John Hughes]

Forwarding to build-dev for wider review.

 Forwarded Message 
Subject: [RFR] 8217753: Enable HotSpot builds on 5.x Linux kernels
Date: Mon, 11 Mar 2019 07:24:48 +
From: Andrew John Hughes 
To: 'jdk8u-...@openjdk.java.net' 

Bug: https://bugs.openjdk.java.net/browse/JDK-8217753
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8217753/webrev.01/

This is 8u and below only as it's part of the old HotSpot build replaced
in 9+.

There's a check in make/linux/Makefile to ensure that a 2.4 or later
kernel is being used. This has been extended by JDK-7072341 to
accommodate Linux 3.x and JDK-8074312 for 4.x. 5.x is now imminent [0]
and the build is broken again [1].

Given that 2.4 was released over 18 years ago [2], I think now is the
time to just get rid of this check rather than bumping it yet again. If
anyone is really trying to build OpenJDK 8 on a 2.2 kernel, I suspect
they will encounter other issues than a Makefile check, and it seems far
more likely that, if we just add a '5%' check, someone is going to build
with Linux 6.x in a few years and hit this same bug again.

[0] https://lwn.net/Articles/776034/
[1] https://bugs.gentoo.org/675920
[2] http://lkml.iu.edu/hypermail/linux/kernel/0101.0/0776.html
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

Re: Does OpenJDK statically link the C++ runtime?

[Dr Andrew John Hughes]

On 20:43 Wed 04 Jan , John Von Seggern wrote:
> Kelly,
> Thanks for taking the time to answer my question.  This information is
> very helpful.
> 
> > So in general, doing static linking is a bad idea and should not be done 
> > lightly, if ever.
> 

The most obvious issue for me is security.  If a security flaw appears in 
libstdc++
(or whatever library is linked statically), you have to rebuild to fix it.  So 
the JDK
has to have a security update due to one of its dependencies.

> As I've been looking into these issues, I've encountered developers
> who advise against dynamically loading any C++ code.  For example, a
> coworker referred me to this article:
> 
> http://www.trilithium.com/johan/2005/06/static-libstdc/
> 
> If you don't want to do all that reading, the key quotes are:
> 
> 1. "C++ ABI changes have been introduced with every major release of GCC"
> 2. "code compiled against different ABIs is simply not binary compatible."
> 3. "a fairly workable compromise is to link all C++ code into an
> executable while using dynamically loaded C libraries only."
> 4. "for this to work reliably you must not use dynamically loaded C++ code"
> 
> As I understand it, Sun took a similar approach for JDK4.
> 

A lot of this depends on development model.

In a FOSS model, the source is available so anyone can perform a rebuild.  
Hence,
if they upgrade their compiler, they can simply rebuild its dependencies.  
GNU/Linux
is provided in distributions which means that each part of the stack is under 
the control
of the same entity.  So they know if a gcc upgrade is performed and to do a mass
rebuild of all packages (usually for a new release).  This also shakes out 
build problems
with that new compiler.  A lot of the work IcedTea 
(http://icedtea.classpath.org/) has
done with OpenJDK relates to making it work well in this kind of environment.

In a proprietary model, which OpenJDK's build system is designed around, the 
user is
provided with a blob and has to cross their fingers that it runs.  If it 
doesn't, all
they can do is go back to the provider and complain.  Hence, it is in the 
provider's
interest to make that blob compatible with as many systems as possible.  This 
is done
by statically linking libraries and is also the reason you'll find copies of 
system
libraries (libpng, libjpeg, zlib, lcms) in the OpenJDK tree as well as 
libraries like
Gtk+ (for the look and feel) being opened dynamically.  The aim of all that is 
to
minimise dependencies and make the binary self-contained, but it means that if 
any
part of the stack has a security issue, a rebuild is necessary.  Such a blob is 
always
going to be safer in terms of compatibility as all the parts are in the same 
box.
This is the model followed by applications on Windows and Mac OS platforms, and
leads to issues such as "DLL hell" with dynamically linked bundled libraries, 
as several
applications all bring their own copies of the same library but different 
versions.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


signature.asc
Description: Digital signature

Re: Does OpenJDK statically link the C++ runtime?

[Dr Andrew John Hughes]

On 10:41 Wed 04 Jan , Andrew Haley wrote:
> On 01/04/2012 06:16 AM, John Von Seggern wrote:
> > Way back in a bug report for Java 1.4, I found this note:
> > 
> > "We statically link the C++ runtime in JDK and enabled linker script
> > to hide symbols from libstdc++ and other internal symbols."
> > --http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4694590
> > 
> > Does OpenJDK continue to take this approach?
> 
> Yes it does, but if you're using Linux be aware that most Linux
> distros patch this out, AFAIK.
> 

I'm not sure it even needs patching (though we do in IcedTea6).  Setting
STATIC_CXX=false should be enough (it defaults to true).

> Andrew.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


signature.asc
Description: Digital signature

Re: Xm/Motif for OpenJDK build?

[Dr Andrew John Hughes]

On 09:11 Wed 09 Nov , Florian Weimer wrote:
> * Srinivas Ramakrishna:
> 
> > Sorry for a rather naive question. I am building openjdk (6) from
> > scratch for the first time and am running into an issue when building
> > the AWT classes because of not finding the relevant Motif header files
> > at the expected locations on my system (ubuntu/x64).
> 
> I think these headers are plain Xt, not Motif.  Here's the minimal list
> of build dependencies I ended up with:
> 
>  ant,
>  ant-optional,
>  cpio,
>  file,
>  gawk,
>  libasound2-dev,
>  libcups2-dev,
>  libfreetype6-dev,
>  libx11-dev,
>  libxext-dev,
>  libxi-dev,
>  libxrender-dev,
>  libxt-dev,
>  libxtst-dev,
>  m4,
>  openjdk-6-jdk,
>  openjdk-drops,
>  procps,
>  unzip,
>  x11proto-input-dev,
>  zip,
> 
> This list is for building OpenJDK 7 on a derivative of Debian squeeze,
> but Ubuntu is probably similar.
> 

But he asked about 6, not 7.  And 6 does require the Motif headers still.
Works with OpenMotif.

> -- 
> Florian Weimer
> BFK edv-consulting GmbH   http://www.bfk.de/
> Kriegsstraße 100  tel: +49-721-96201-1
> D-76133 Karlsruhe fax: +49-721-96201-99

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


signature.asc
Description: Digital signature

Re: Building OpenJDK on Ubuntu 11.10

[Dr Andrew John Hughes]

On 15:42 Fri 21 Oct , Tim Ellison wrote:
> Is anyone else building OpenJDK 7 on Ubuntu 10.11?  I found I need a
> couple of extra definitions to work around problems not seen on 10.4.
> 

CCing build-dev instead as these are build issues, not porting issues.

> 1) "This OS is not supported"
> 
> The Hotspot build checks that the Linux kernel version number is in a
> known list.  As Ubuntu 10.11 has kernel 3.0.0 you either need to
> bypass the version check (DISABLE_HOTSPOT_OS_VERSION_CHECK=ok), or add
> 3.0 to the supported versions, i.e.
> 
> diff -r 9b0ca45cd756 make/linux/Makefile
> --- a/make/linux/Makefile Tue Jun 28 10:57:38 2011 -0700
> +++ b/make/linux/Makefile Fri Oct 21 15:15:20 2011 +0100
> @@ -230,7 +230,7 @@
>  # Solaris 2.5.1, 2.6).
>  # Disable this check by setting DISABLE_HOTSPOT_OS_VERSION_CHECK=ok.
> 
> -SUPPORTED_OS_VERSION = 2.4% 2.5% 2.6% 2.7%
> +SUPPORTED_OS_VERSION = 2.4% 2.5% 2.6% 2.7% 3.0%
>  OS_VERSION := $(shell uname -r)
>  EMPTY_IF_NOT_SUPPORTED = $(filter $(SUPPORTED_OS_VERSION),$(OS_VERSION))
> 

I've already fixed this and submitted it upstream months ago, but as
external contributors apparently aren't allowed to commit to the HotSpot
repositories (still!), I've no idea exactly where it ended up.

It at least seems to be in the jdk7u tree:

changeset:   2647:ca1f1753c866
user:andrew
date:Thu Jul 28 14:10:21 2011 -0400
summary: 7072341: enable hotspot builds on Linux 3.0

I suggest you just need to update.

> 
> 2) Can't find asound lib
> 
> To get jsoundalsa to link successfully I found I need to specify
> "EXTRA_LIBS=/usr/lib/i386-linux-gnu/libasound.so"  to pick up
> libasound.so (from pkg libasound2-dev) as it is no longer in /usr/lib.
> 

I've never seen this before, but it seems like an Ubuntu issue, not an
OpenJDK one.  Surely /usr/lib/i386-linux-gnu should be on the system
library path if this library is being stored there?

> 
> Anyone else come across these?  Any interest to have OpenJDK build on
> Ubuntu 10.11 straight out of the box?
> 
> Thoughts?
> Tim

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


signature.asc
Description: Digital signature

Re: hg: build-infra/jdk7: Jaxws actually depends on jaxp, this becomes obvious when compiling

[Dr Andrew John Hughes]

On 14:28 Fri 14 Oct , fredrik.ohrst...@oracle.com wrote:
> Changeset: 984f119f2ea7
> Author:ohrstrom
> Date:  2011-10-14 16:36 +0200
> URL:   http://hg.openjdk.java.net/build-infra/jdk7/rev/984f119f2ea7
> 
> Jaxws actually depends on jaxp, this becomes obvious when compiling
> with a boot jdk that does not have jaxp in its boot class path.
> 
> ! Makefile
> 

Yeah, I found this with IcedTea bootstrapping; see 
patches/boot/jaxp-dependency.patch
in IcedTea7.  There are a lot of implicit assumptions throughout the build
that a complete Oracle JDK will be available (i.e one with com.sun.* and sun.* 
classes).
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


signature.asc
Description: Digital signature

Re: Improving source drops documentation

[Dr Andrew John Hughes]

On 13:52 Wed 12 Oct , Fredrik Öhrström wrote:
> 2011/10/12 Dr Andrew John Hughes :
> > FWIW, I recently did exactly that in IcedTea because I'm sick of all the 
> > problems this drop solution causes.
> > This has cut things down from needing five tarballs (jaxp + jaxws 
> > repositories + three drop zips) to two with
> > everything in. Should someone really want to build from the tarballs, they 
> > can just delete the sources.
> 
> The sources must be added to the jaxp/jaxws repositores. In fact I
> have done that already in the build-infra forest.
> 

Yes, same in the IcedTea forest e.g. 
http://hg.openjdk.java.net/icedtea/jdk7/jaxws/rev/c608b38af726

> > I don't see why touching the files is a problem; surely all changesets have 
> > to pass review and any that attempt to
> > alter this files would just not do so? What am I missing?
> 
> It suppose it is a matter of educating sustaining engineering that
> fixes to jaxp and jaxws has to go through the upstream repositories.
> A bit of software to prevent messing this up would help, but is not
> immediately needed.
> 

I still fail to see why such changes would be approved in the first place.  It 
sounds like a software
solution is being used to paper over a social one.

> //Fredrik

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: Improving source drops documentation

[Dr Andrew John Hughes]

On 10:52 Tue 11 Oct , Kelly O'Hair wrote:
> My plan of record has been to just unzip these bundles right into the 
> repositories and get rid of this painful
> situation, that I have to confess, I created. :^(
> But I was thinking I could come up with some kind of way to paint these 
> sources RED or something so
> that people do not patch these files, but instead feed changes to the 
> upstream jaxp and jaxws open source projects.
> These files are like generated files, re-packaged and different legal notices 
> from the originals, by the
> jaxp and jaxws teams.
> 
> I could just declare 'do not edit these files unless you have approved' and 
> hope that people obey that rule.
> 
> I just haven't had the cycles to deal with this of late.
> 
> This is a sore point in building that we really need to fix.
> 

FWIW, I recently did exactly that in IcedTea because I'm sick of all the 
problems this drop solution causes.
This has cut things down from needing five tarballs (jaxp + jaxws repositories 
+ three drop zips) to two with
everything in.  Should someone really want to build from the tarballs, they can 
just delete the sources.

I don't see why touching the files is a problem; surely all changesets have to 
pass review and any that attempt to
alter this files would just not do so?  What am I missing?

> -kto
> 
> On Oct 11, 2011, at 2:14 AM, Dan Smith wrote:
> 
> > I build infrequently, but when I do, I often get errors due to out-of-date 
> > jaxp and jax-ws source bundles.  My typical process is something like this:
> > 
> > 1) Start to build
> > 2) Observe a failure complaining about an improper $ALT_DROPS_DIR
> > 3) Track down my note where I wrote down the URL where I can get to a Web 
> > view of /java/devtools/...
> > 4) Navigate to the right folder and look for file timestamps that are more 
> > recent than the last time I did this
> > 5) Download & save the appropriate files to my source drops dir
> > 6) Try again
> > 
> > I think this is more or less the "best practice," but correct me if I'm 
> > wrong.  In particular, I'm not relying on mounted access to the /java 
> > filesystem, as I think most veteran Sun employees do, and I'm not using 
> > ALLOW_DOWNLOADS, which is discouraged in the build documentation.
> > 
> > Short of getting rid of the source drops entirely, it seems like there's a 
> > lot that could be done to streamline this process.
> > 
> > - It would be nice if the sanity check caught the missing files, rather 
> > than waiting to complain in the middle of the build.  (Fortunately, at 
> > least these get built early.)
> > 
> > - The error message would be a lot more useful if it told me the name(s) of 
> > the missing file(s) (which includes the version number) rather than 
> > assuming that my ALT_DROPS_DIR setting is wrong.
> > 
> > - Even better, the error message could spit out the URL(s) where I could 
> > download the file(s)!  (This should be the same URL as used by 
> > ALLOW_DOWNLOADS.)
> > 
> > - The docs ("Creation of New Source Drop Bundles") say the OpenJDK team 
> > puts new bundles in "/java/devtools/...", which is difficult to access.  
> > (Can non-Oracle folks get to it? I rely on the javaweb internal server, 
> > which happened to be down today...)  Is/could this directory be made 
> > available somewhere public, too?
> > 
> > Thanks,
> > Dan
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: Build Infrastructure changes

[Dr Andrew John Hughes]

On 18:25 Wed 03 Aug , Kelly O'Hair wrote:
> FYI...
> 
> If you are interested in the jdk8 build infrastructure changes coming down 
> the pipe, I invite you
> to join the build-infra-dev alias:
> 
> http://mail.openjdk.java.net/pipermail/build-infra-dev/2011-August/29.html
> 
> I expect this work to get started and moving soon with Fredrik as the primary 
> contributor,
> the only catch is that I will be on vacation Aug 9-21 and the openjdk mail 
> system seems to be
> refusing to send email to Fredrik. Hopefully I'll resolve Fredrik's email 
> issue very soon.
> 
> The autoconf setup may borrow ideas/patterns from the IcedTea project, and I 
> want to give
> credit to that team for that work.

Thanks.  I'd hope we could actually use some of the IcedTea work in OpenJDK.
I don't think doing that will be so much a technical issue; I doubt you're going
to test for libraries any differently and could probably start using more system
ones.  However, there is a legal issue with OpenJDK contributions requiring the 
OCA.

> 
> Please send questions to the build-infra-dev alias.
> 
> -kto

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Different javac options for explicitly and automatically compiled files

[Dr Andrew John Hughes]

On 16:02 Mon 01 Aug , Jonathan Gibbons wrote:
> On 08/01/2011 02:55 PM, Dr Andrew John Hughes wrote:
> > On 11:07 Mon 01 Aug , Alexandre Boulgakov wrote:
> >> Hello Kelly,
> >>
> >> Do you know the answer to this one?
> >>
> >> Thanks,
> >> Sasha
> >>
> >> On 7/29/2011 11:37 AM, Alexandre Boulgakov wrote:
> >>> Hello,
> >>>
> >>> I am working on removing the javac -Xlint warnings from java.net.*.
> >>> After removing these warnings, I would like to turn on javac's -Werror
> >>> flag in make/java/net/Makefile. However, it seems that the javac task
> >>> in make/java/net/Makefile has to automatically compile some
> >>> dependencies (not listed in the makefile, presumably inferred by the
> >>> compiler from the sourcepath) which have not had warnings fixed yet
> >>> (sun.net.idn.*, com.sun.security.ntlm.*).
> >>>
> >>> Is there some way to have the -Werror flag only apply to explicitly
> >>> specified source files, but not to the ones that javac pulls in
> >>> automatically?
> > It sounds to me like there's a bug there; those files should be being
> > dealt with earlier in the build or as part of java/net/Makefile.
> 
> Regrettably, there are circularities in JDK :-(
> 
> > If they aren't implictly compiled from the source tree, then presumably
> > classes from the bootstrap runtime library will be used if present, which
> > could cause all sorts of issues.
> 
> No. The Makefiles should be set so that the "bootstrap runtime library" 
> is overridden
> with -bootclasspath, meaning that the compilation will fail if the 
> classes are not
> available to javac in source or compiled form.
> 

Then where is it going to get these classes if -implicit:none is used to
stop them being compiled from source?

> >>> Thanks,
> >>> Sasha
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Different javac options for explicitly and automatically compiled files

[Dr Andrew John Hughes]

On 11:07 Mon 01 Aug , Alexandre Boulgakov wrote:
> Hello Kelly,
> 
> Do you know the answer to this one?
> 
> Thanks,
> Sasha
> 
> On 7/29/2011 11:37 AM, Alexandre Boulgakov wrote:
> > Hello,
> >
> > I am working on removing the javac -Xlint warnings from java.net.*. 
> > After removing these warnings, I would like to turn on javac's -Werror 
> > flag in make/java/net/Makefile. However, it seems that the javac task 
> > in make/java/net/Makefile has to automatically compile some 
> > dependencies (not listed in the makefile, presumably inferred by the 
> > compiler from the sourcepath) which have not had warnings fixed yet 
> > (sun.net.idn.*, com.sun.security.ntlm.*).
> >
> > Is there some way to have the -Werror flag only apply to explicitly 
> > specified source files, but not to the ones that javac pulls in 
> > automatically?

It sounds to me like there's a bug there; those files should be being
dealt with earlier in the build or as part of java/net/Makefile.

If they aren't implictly compiled from the source tree, then presumably
classes from the bootstrap runtime library will be used if present, which
could cause all sorts of issues.

> >
> > Thanks,
> > Sasha

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Allow HotSpot to build on Linux 3.0+

[Dr Andrew John Hughes]

On 09:17 Thu 28 Jul , Keith McGuigan wrote:
> 
> Ok, thanks.  Code looks good to me then.
> 

Ok, can I push this or do you still need to do this via JPRT?

Either way, I need a bug ID please.

> --
> - Keith
> 
> On Jul 28, 2011, at 9:02 AM, Mark Wielaard wrote:
> 
> > On Thu, 2011-07-28 at 08:32 -0400, Keith McGuigan wrote:
> >> This appears to remove support for version 2.7.  Is that intentional?
> >
> > There has never been a 2.7 kernel.
> > 2.6.39.3 is the last before the 3.0 series.
> > https://secure.wikimedia.org/wikipedia/en/wiki/ 
> > Linux_kernel#Version_numbering
> >
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Allow HotSpot to build on Linux 3.0+

[Dr Andrew John Hughes]

On 15:02 Thu 28 Jul , Mark Wielaard wrote:
> On Thu, 2011-07-28 at 08:32 -0400, Keith McGuigan wrote:
> > This appears to remove support for version 2.7.  Is that intentional?
> 
> There has never been a 2.7 kernel.
> 2.6.39.3 is the last before the 3.0 series.
> https://secure.wikimedia.org/wikipedia/en/wiki/Linux_kernel#Version_numbering
> 

Yes, it was intentional.  As Mark says, it never existed and I guess never will 
now.
I assume it was added as future proofing, but Linus went and messed that up
by going to 3.0... ;-)
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Regression in OpenJDK8 Makefiles

[Dr Andrew John Hughes]

On 17:12 Wed 27 Jul , Kelly O'Hair wrote:
> 
> On Jul 27, 2011, at 4:28 PM, Dr Andrew John Hughes wrote:
> 
> > On 11:58 Wed 27 Jul , Kelly O'Hair wrote:
> >> 
> >> On Jul 27, 2011, at 11:04 AM, Dr Andrew John Hughes wrote:
> >> 
> >>> Hi,
> >>> 
> >>> Can someone please tell me why:
> >>> 
> >>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119
> >>> 
> >>> reverted my earlier fix:
> >>> 
> >>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80368890a2a0
> >>> 
> >>> without any discussion?
> >> 
> >> My apologies, the webrev should have been made public.
> >> 
> >>> 
> >>> The correct fix would have been to bump the boot source language/target 
> >>> class
> >>> versions to 7, not erase the lines altogether.
> >> 
> >> Unfortunately, that did not work with jdk7 as a boot
> > 
> > Why was this?  I don't understand why anything would fail with javac 
> > -source 7 -target 7 over
> > just javac.
> 
> Basically, we never really know what the BOOT javac will accept.

I was referring more to the actual build failure when you tried this.

If we're requiring 7 support as a minimum for bootstrapping, surely we know it 
will support this.

> I assume that if we use the default for javac, that the BOOT java can run 
> them.

This is the assumption that has not always held in my experience.

Being explicit means that a newer javac can be used with an older VM.

snip...

> 
> If the BOOT jdk was jdk8, I would want these sources built for jdk8 and run 
> with a jdk8,
> it should just work.
> 

This seems to contradict what you're saying about the files ending up in the 
image.  Why
does it matter if they use the minimum supported version?  Presumably an 
OpenJDK8 VM will
be able to run 1.7 class files.  But an OpenJDK7 VM wouldn't be able to run 1.8 
class files
if these are the default produced by the bootstrap javac.

> -kto
> 
> 
> > 
> >> -kto
> >> 
> >>> -- 
> >>> Andrew :)
> >>> 
> >>> Free Java Software Engineer
> >>> Red Hat, Inc. (http://www.redhat.com)
> >>> 
> >>> Support Free Java!
> >>> Contribute to GNU Classpath and IcedTea
> >>> http://www.gnu.org/software/classpath
> >>> http://icedtea.classpath.org
> >>> PGP Key: F5862A37 (https://keys.indymedia.org/)
> >>> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37
> >> 
> > 
> > -- 
> > Andrew :)
> > 
> > Free Java Software Engineer
> > Red Hat, Inc. (http://www.redhat.com)
> > 
> > Support Free Java!
> > Contribute to GNU Classpath and IcedTea
> > http://www.gnu.org/software/classpath
> > http://icedtea.classpath.org
> > PGP Key: F5862A37 (https://keys.indymedia.org/)
> > Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Allow HotSpot to build on Linux 3.0+

[Dr Andrew John Hughes]

Linux 3.0 was released last week:

https://lwn.net/Articles/452531/

This webrev:

http://cr.openjdk.java.net/~andrew/pr748/

fixes the check in the HotSpot build to allow Linux 3.0 and on
through the version check.

This is against hotspot-comp/OpenJDK8 but our testing in IcedTea6
shows that the same patch applies all the way back to hs14 just
fine.

Ok to push?

You might also want to consider getting this into OpenJDK7 if
it's going to remain buildable... :-)
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Regression in OpenJDK8 Makefiles

[Dr Andrew John Hughes]

On 11:58 Wed 27 Jul , Kelly O'Hair wrote:
> 
> On Jul 27, 2011, at 11:04 AM, Dr Andrew John Hughes wrote:
> 
> > Hi,
> > 
> > Can someone please tell me why:
> > 
> > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119
> > 
> > reverted my earlier fix:
> > 
> > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80368890a2a0
> > 
> > without any discussion?
> 
> My apologies, the webrev should have been made public.
> 
> > 
> > The correct fix would have been to bump the boot source language/target 
> > class
> > versions to 7, not erase the lines altogether.
> 
> Unfortunately, that did not work with jdk7 as a boot

Why was this?  I don't understand why anything would fail with javac -source 7 
-target 7 over
just javac.

, and jdk6 won't work as a boot jdk
> soon anyway.

Well, yes I assumed this patch was related to moving to OpenJDK7 as the minimum 
bootstrap JDK.

> Since we will be requiring a jdk7 as the boot jdk, I did not feel it was 
> needed
> to even specify this. Anything compiled with the boot javac technically 
> doesn't care what
> the source/target is, or should, and the class files created just need to 
> work with the boot jdk,
> and should not be shipped as part of the jdk8 being built.
> 
> When I looked at the Makefiles, there was no comment as to why we even had to 
> set the -source
> or -target options when using the boot javac at all.
> My conclusion was that it was unnecessary, and deleting these lines made 
> 'jdk7 as boot' work.
> 
> If that was wrong I apologize, why does this matter?
> 

It means that we are depending on whatever defaults the bootstrap
javac uses rather than being explicit.  In most cases, that might not
cause a problem but I know I've run into problems with this and I
think it better to be safe than sorry, as you don't know what the
bootstrap javac is or what its default is.  If we expect the
bootstrap javac to produce java 7 class files, it should be set
explicitly:

http://blogs.oracle.com/darcy/entry/build_advice_set_source_target

I think I've hit it mostly with using ecj as the bootstrap javac, but
it couldcause an issue during development if the bootstrap javac
started producing 1.8 code by default but the VM used wasn't capable of
handling it.  Unlikely maybe, but I think it's better to have this set
explicitly and just avoid such issues altogether.

> -kto
> 
> > -- 
> > Andrew :)
> > 
> > Free Java Software Engineer
> > Red Hat, Inc. (http://www.redhat.com)
> > 
> > Support Free Java!
> > Contribute to GNU Classpath and IcedTea
> > http://www.gnu.org/software/classpath
> > http://icedtea.classpath.org
> > PGP Key: F5862A37 (https://keys.indymedia.org/)
> > Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Regression in OpenJDK8 Makefiles

[Dr Andrew John Hughes]

Hi,

Can someone please tell me why:

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119

reverted my earlier fix:

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80368890a2a0

without any discussion?

The correct fix would have been to bump the boot source language/target class
versions to 7, not erase the lines altogether.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Help me to build openjdk on my machine

[Dr Andrew John Hughes]

On 11:24 Sun 10 Jul , Erik Trimble wrote:
> Folks,
> 
> PPC isn't a currently supported architecture for OpenJDK - that is, no 
> one has contributed any code to support it.  I do know of several 
> proprietary ports, but that doesn't help. :-)  I don't even remember the 
> last time it was potentially supported (I'm pretty sure that PPC never 
> was supported in the OpenJDK project).
> 
> To put in more bluntly, no one has built OpenJDK on PPC here at Oracle 
> for a *very* long time, and I don't know of any Open port anywhere else.
> 
> It certainly would be nice for someone to come forward with a port of 
> Hotspot to the PPC/Power architecture, as the Freescale stuff (in 
> particular) is becoming very popular for embedded work.  Now that IBM is 
> part of OpenJDK, maybe they'll be interested?  (who knows)
> 
> FYI - "Zero" the architecture, is for a zero-assembly version of Hotspot 
> (that is, a Hotspot version with as little architecture-specific 
> customizations as possible). If I were porting Hotspot, I'd start with 
> the Zero codebase, and work from there. But that's just me.
> 
> -Erik
> 
> 

Debian provides PPC GNU/Linux builds, presumably using Zero:

http://packages.debian.org/squeeze/openjdk-6-jdk
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: prebuild Oracle VM appliance

[Dr Andrew John Hughes]

On 16:15 Wed 15 Jun , Andrew Haley wrote:
> On 06/15/2011 04:11 PM, Dr Andrew John Hughes wrote:
> > On 09:59 Wed 15 Jun , Andrew Haley wrote:
> >> On 14/06/11 22:22, Sebastian Sickelmann wrote:
> >>>
> >>> i had done a contribution to openjdk7 and remembered it was very
> >>> hard to setup all the build thinks. Now a want to make some new
> >>> contributions and i struggle again with the build setup. How about a
> >>> prebuild Oracle VM appliance for openjdk development (at least for
> >>> the linux-setup). I will get it working without such a appliance but
> >>> i think it can be a solution to lower the "entry-hurdle" in openjdk
> >>> contribution.
> >>
> >> Perhaps so.  I used to find OpenJDK hard to build, but now only the
> >> pesky bundles that you have to download present any problems.  I'll be
> >> interested to find out what other problems a prebuilt VM needs to
> >> solve.
> > 
> > Which 'pesky bundles' are you referring to?  I'm not aware of any being
> > required for OpenJDK at present.
> 
> Sure, but they were.  I don't know what Sebastian is trying to solve,
> since OpenJDK builds cleanly out of the box on the systems I use.
> 

Same here.  They haven't been any bundles for a couple of years.
The build could be a lot simpler though, and I believe Kelly is working
on that.

> Andrew.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: prebuild Oracle VM appliance

[Dr Andrew John Hughes]

On 09:59 Wed 15 Jun , Andrew Haley wrote:
> On 14/06/11 22:22, Sebastian Sickelmann wrote:
> > 
> > i had done a contribution to openjdk7 and remembered it was very
> > hard to setup all the build thinks. Now a want to make some new
> > contributions and i struggle again with the build setup. How about a
> > prebuild Oracle VM appliance for openjdk development (at least for
> > the linux-setup). I will get it working without such a appliance but
> > i think it can be a solution to lower the "entry-hurdle" in openjdk
> > contribution.
> 
> Perhaps so.  I used to find OpenJDK hard to build, but now only the
> pesky bundles that you have to download present any problems.  I'll be
> interested to find out what other problems a prebuilt VM needs to
> solve.
> 
> Andrew.

Which 'pesky bundles' are you referring to?  I'm not aware of any being
required for OpenJDK at present.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Boot JDK used with jdk7 builds

[Dr Andrew John Hughes]

On 08:57 Fri 03 Jun , Kelly O'Hair wrote:
> 
> The documented Boot JDK to be used when building JDK7 repositories is JDK6 
> Update 18, as listed here
>   http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#MBE
> 
> However, as many people know, JDK releases newer than JDK6u18 should always 
> work, and some older ones can work too.
> Variations in build dependencies can sometimes create unwanted differences 
> between builds by different developers
> or build systems, so our tendency is to minimize these variations, but by 
> doing so, we run a risk that we don't
> see what does not work. 
> 
> If you have any incidents where particular JDKs can or cannot be used as the 
> Boot JDK for JDK7, please let us know.
> 
> -kto
> 

And OpenJDK6 works.  Is there any reason this is not recommended rather than a 
proprietary product?
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Build Infrastructure Project

[Dr Andrew John Hughes]

On 16:12 Fri 20 May , Kelly O'Hair wrote:
> 
> On May 20, 2011, at 3:36 PM, Dr Andrew John Hughes wrote:
> 
> > On 13:11 Fri 20 May , Kelly O'Hair wrote:
> >> 
> >> We now have a Build Infrastructure project!
> >> 
> >> Register for email at:
> >>  http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev
> >> 
> >> The repos will be at:
> >>   http://hg.openjdk.java.net/build-infra/jdk7
> >> 
> >> But I haven't been able to populate them just yet, having access issues.
> >> 
> >> Once the repos are primed, I hope this can get moving quickly because I 
> >> want to expose
> >> what can be done to the builds in terms of turnaround improvements etc.
> >> 
> >> -kto
> >> 
> > 
> > Hi Kelly,
> > 
> > Sorry if I missed this already, but what is the purpose of this new project?
> 
> Once I can get the build-infra repos primed, hopefully you will see what we 
> are doing.
> I don't expect this project to last past the final jdk8 efforts, it's a 
> sandbox for us to experiment
> and stabilize build changes.
> 
> The big goal is to make builds faster, orders of magnitude faster, with some 
> major
> makefile re-writing and organization.
> An additional goal is to try and make building easier, but that part of it is 
> mostly directed
> at the Solaris and Windows builds, Linux isn't that hard (in my opinion :).
> 
> The reason for the project is that this will be major build changes, and we 
> will need
> to experiment and share our work as quickly as possible, and openly as 
> possible.
> Once the changes prove to be stable and acceptable, then we will deal with 
> the transition to
> jdk8, and leave the jdk7 changes for potentially being included into jdk7u2, 
> but jdk8 is
> our primary target.
> 
> One sub-project will be "BuildDeps" which will try and address how the build 
> dependencies are
> identified and how local installs are automated. Haven't much detail on that 
> yet.
> 
> The major sub-project will be a re-write of the Makefiles to remove the 
> deeply nested Makefiles,
> correct the target dependencies, allow for "make -j N" to work reliably, 
> share common make logic,
> paralyze the javac compilations, etc. Pretty drastic stuff, but if we can 
> indeed make the builds
> orders of magnitude faster, we hope people will welcome the changes.
> 
> Hopefully Fredrik and Erik will chime in for clarification when I mis-state 
> things.
> 
> We are looking to turn around some of this work very quickly, so it's an E 
> ticket ride if
> you want to watch or join in (http://en.wikipedia.org/wiki/E_ticket).  ;^)
> 
> -kto
> 

This sounds great and long overdue.  I'd be happy to be involved if possible.

IcedTea currently has to force make -j1 on the OpenJDK build... :-(
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Build portability: enable or disable warnings

[Dr Andrew John Hughes]

On 07:20 Fri 20 May , David Holmes wrote:
> Dr Andrew John Hughes said the following on 05/20/11 06:24:
> > On 09:47 Thu 19 May , David Holmes wrote:
> >> Dr Andrew John Hughes said the following on 05/19/11 05:29:
> >>> On 08:35 Mon 16 May , Kelly O'Hair wrote:
> >> 
> >>>> The -Werror option is a blessing and a curse. I find it highly 
> >>>> commendable that teams (like 
> >>>> hotspot) have taken a 'no warnings allowed' approach to their code base, 
> >>>> more teams should do this.
> >>>> Given the critical nature of a VM in the JDK, it only makes sense to 
> >>>> take all precautions in verifying the code is correct.
> >>>>
> >>> I find it quite interesting that the one situation where -Werror is used 
> >>> is where it's likely to hit
> >>> the most difficulties. The HotSpot code is compiled by three different 
> >>> compilers (gcc and whatever
> >>> is used on Solaris and Windows) and the version of these used can vary 
> >>> considerably, as the system C++ compiler
> >>> is unrelated to the JDK.  
> >> Hotspot only uses -Werror with gcc. And its use predates the sudden 
> >> plethora of compiler versions now used to build OpenJDK. In prior times 
> >> the build compiler for a given release was set in stone so we knew what 
> >> warnings (and bugs!) to expect. 
> > 
> > Welcome to OpenJDK.  You can't expect everyone compiling a FOSS project to
> > use one true compiler and no other.  Sorry.  That's just the reality, and
> > it's why we now have to reassess/amend these earlier choices.
> 
> I was simply stating the history.
> 

Ah, ok.  It read to me as if you expected this to still be possible.

> 
> > It does.  I'm unclear how anything you say here is different to the 
> > situation
> > with C/C++ compilers producing new warnings in new versions.
> 
> I'm unclear what point you are trying to make about javac.
> 
> javac produces new warnings because new language features cause new 
> potential issues. There are no new features in C/C++ (compiler-specific 
> extensions ignored), the compilers just get more pedantic about what 
> they complain about.
> 

My point was just that it's interesting that it's HotSpot, which is
subject to the most variance in compilers (and thus the warnings
produced) that opts to have -Werror on by default.  The Java code
doesn't, yet the compiler for it is actually developed as part of the
OpenJDK code base.  It's not going to see the same kind of problem
where someone installs the new version of the system compiler and gets
new warnings, so -Werror behaviour with Java code would be much more
stable.

I don't think all javac warnings are down to new language features
and, having most warnings turned off and not causing errors, means
that more warnings build up as new code is written.

> >  If anything, OpenJDK
> > is leading the way with support for these new language features, so you'd 
> > expect
> > it to adopt them in its own codebase.  As is, we're still getting warnings 
> > resulting
> > from features introduced in 2004.
> 
> Practical realities - there were no resources, for example, to go and 
> change every single class that used a collection type in 1.4.2 and so 
> generated a "raw type" warning once generics were added in 5. These 
> things sometimes get cleaned up when other work is occurring in an area.
> 
> Also note that in many cases javac warnings are disappearing because 
> @SuppressWarnings is being applied to the code.
> 

I understand that.  It actually makes for some pretty good low hanging
fruit for external contributors to OpenJDK IMHO.  It's akin to the
janitoral work done on Linux if you're familiar with that.

I did find it worrying that there was an active desire to use new
OpenJDK7 language features throughout the codebase (despite the
bootstrapping problems this can cause), yet these 1.5 issues remain.

> David
> -
> 
> > 
> >> I think comparing C/C++ compiler warnings with javac compiler warnings 
> >> is like comparing apples and elephants.
> >>
> >> David
> >> -
> >>
> > 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Build Infrastructure Project

[Dr Andrew John Hughes]

On 13:11 Fri 20 May , Kelly O'Hair wrote:
> 
> We now have a Build Infrastructure project!
> 
> Register for email at:
>   http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev
> 
> The repos will be at:
>http://hg.openjdk.java.net/build-infra/jdk7
> 
> But I haven't been able to populate them just yet, having access issues.
> 
> Once the repos are primed, I hope this can get moving quickly because I want 
> to expose
> what can be done to the builds in terms of turnaround improvements etc.
> 
> -kto
> 

Hi Kelly,

Sorry if I missed this already, but what is the purpose of this new project?
I thought we already had build-dev...
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Build portability: enable or disable warnings

[Dr Andrew John Hughes]

On 17:00 Thu 19 May , Kelly O'Hair wrote:
> 

snip...

> 
> But yes, a great project would be to see if we could get to 'javac -Xlint:all 
> -Werror' someday.
> We really should...  in fact it should be a requirement moving forward that 
> all java code be warning free, and stay that way.
> 

Slowly working on it... ;-)

> Not sure about the hotspot java code.
> 

I got HotSpot's SA to at least compile without needing -source/-target 1.4.  
Baby steps...

> -kto
> 
> > 
> > -Alan.
> > 
> > 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Build portability: enable or disable warnings

[Dr Andrew John Hughes]

On 10:32 Thu 19 May , Alan Bateman wrote:
> David Holmes wrote:
> > :
> >
> >> In contrast, there are basically two Java compilers in general use 
> >> (javac and ecj)
> >> and one is part of OpenJDK.  Yet, the Java code does not have -Werror 
> >> enabled by default and there
> >> are a mass of warnings there as a result.
> >
> > I don't understand the point you are making here. Does javac even have 
> > a -Werror? The bulk of javac warnings stem from legacy code being 
> > compiled under newer compilers with new language features - the 
> > resulting code is not erroneous hence only a warning is issued.
> >
> > I think comparing C/C++ compiler warnings with javac compiler warnings 
> > is like comparing apples and elephants.
> Yes, javac has -Werror and the build has JAVAC_WARNINGS_FATAL to turn it 
> on. I just checked my recent build of the jdk7/jdk7 forest and javac 
> emits a total of 9 warnings (7 are unsafe usages of varargs methods and 
> the other two are unreachable catch clauses). That isn't a lot but javac 
> doesn't have many warnings enabled by default. A nice project for 
> someone would be to change the build to -Werror by default and gradually 
> crank up the warnings listed by -Xlint.
> 

javac is generally a good citizen.  I was thinking of jdk code.

I have built with JAVAC_MAX_WARNINGS=true on a number of occasions and
it's only recently (thanks to a few fixes from myself) that it's
actually been able to complete the build, due to some Makefiles
turning on Werror separately.  I expect with JAVAC_WARNINGS_FATAL as
well we wouldn't get past CORBA.

I do think having a switch to turn on everything but serial and deprecated 
warnings would be a more achievable goal, and would help get rid of
the remaining 1.5 stuff.

> -Alan.
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Build portability: enable or disable warnings

[Dr Andrew John Hughes]

On 09:47 Thu 19 May , David Holmes wrote:
> Dr Andrew John Hughes said the following on 05/19/11 05:29:
> > On 08:35 Mon 16 May , Kelly O'Hair wrote:
> 
> >> The -Werror option is a blessing and a curse. I find it highly commendable 
> >> that teams (like 
> >> hotspot) have taken a 'no warnings allowed' approach to their code base, 
> >> more teams should do this.
> >> Given the critical nature of a VM in the JDK, it only makes sense to take 
> >> all precautions in verifying the code is correct.
> >>
> > 
> > I find it quite interesting that the one situation where -Werror is used is 
> > where it's likely to hit
> > the most difficulties. The HotSpot code is compiled by three different 
> > compilers (gcc and whatever
> > is used on Solaris and Windows) and the version of these used can vary 
> > considerably, as the system C++ compiler
> > is unrelated to the JDK.  
> 
> Hotspot only uses -Werror with gcc. And its use predates the sudden 
> plethora of compiler versions now used to build OpenJDK. In prior times 
> the build compiler for a given release was set in stone so we knew what 
> warnings (and bugs!) to expect. 

Welcome to OpenJDK.  You can't expect everyone compiling a FOSS project to
use one true compiler and no other.  Sorry.  That's just the reality, and
it's why we now have to reassess/amend these earlier choices.

> I believe we also disable problematic 
> warnings when necessary. By using -Werror when we did update compiler 
> versions we quickly discovered where the compiler was tightening the 
> rules and issuing new warnings - then we could determine whether to fix 
> the code (if practical) or disable the warning.
> 

Indeed.  All that's happening here is others are using these newer
compilers before the HotSpot developers at Oracle.

> > In contrast, there are basically two Java compilers in general use (javac 
> > and ecj)
> > and one is part of OpenJDK.  Yet, the Java code does not have -Werror 
> > enabled by default and there
> > are a mass of warnings there as a result.
> 
> I don't understand the point you are making here. Does javac even have a 
> -Werror? The bulk of javac warnings stem from legacy code being compiled 
> under newer compilers with new language features - the resulting code is 
> not erroneous hence only a warning is issued.
> 

It does.  I'm unclear how anything you say here is different to the situation
with C/C++ compilers producing new warnings in new versions.  If anything, 
OpenJDK
is leading the way with support for these new language features, so you'd expect
it to adopt them in its own codebase.  As is, we're still getting warnings 
resulting
from features introduced in 2004.

> I think comparing C/C++ compiler warnings with javac compiler warnings 
> is like comparing apples and elephants.
> 
> David
> -
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Build portability: enable or disable warnings

[Dr Andrew John Hughes]

On 08:35 Mon 16 May , Kelly O'Hair wrote:
> 
> On May 16, 2011, at 7:23 AM, Dr Andrew John Hughes wrote:
> 
> > I think the issue is actually having -Werror enabled for all builds, not
> > just debug builds.  Without that, these additional warnings would just be
> > noise.  Having -Werror on also causes problems just upgrading the version
> > of gcc, regardless of distro-specific patching, as new warnings are
> > introduced or old ones reclassified.
> > 
> >> Andrew.
> 
> 
> The code being compiled is different with debug vs. product builds due to 
> assert logic, so I consider it
> important that all builds use -Werror if they use it at all.
> 
> The -Werror option is a blessing and a curse. I find it highly commendable 
> that teams (like 
> hotspot) have taken a 'no warnings allowed' approach to their code base, more 
> teams should do this.
> Given the critical nature of a VM in the JDK, it only makes sense to take all 
> precautions in verifying the code is correct.
> 

I find it quite interesting that the one situation where -Werror is used is 
where it's likely to hit
the most difficulties. The HotSpot code is compiled by three different 
compilers (gcc and whatever
is used on Solaris and Windows) and the version of these used can vary 
considerably, as the system C++ compiler
is unrelated to the JDK.  In contrast, there are basically two Java compilers 
in general use (javac and ecj)
and one is part of OpenJDK.  Yet, the Java code does not have -Werror enabled 
by default and there
are a mass of warnings there as a result.

> But it only makes 100% sense when using the same compiler, same compiler 
> version, and on the same system.

Which is extremely rare with HotSpot and the C++ compiler, but the first two 
are very likely for the Java
code as the build uses its own javac in most cases.

> For hotspot, you should be able to get rid of -Werror  by setting 
> WARNINGS_ARE_ERRORS to empty.
> 

Thanks for this, I wasn't aware of it.  Are these flags documented somewhere?  
I keep seeming to find
out about new ones randomly in e-mails.

> I've wondered if we need to put a little more smarts in determining what 
> situations (compiler&os) warrant
> adding the -Werror, but at the same time if it is a valid warning, maybe the 
> behavior we have is right.
> So my attitude up to this time has been that new ports should use 
> WARNINGS_ARE_ERRORS=
> to start, but eventually they should fix these warnings before a port is 
> finished.
> (And I use the term 'port' very loosely here, a new version of gcc is a port 
> to me).
> 

I'd go for using the version checking that's already in the build system, and 
only turning on Werror if
gcc/g++ matches the version that's been tested against.  Even then, there may 
be platform-dependent differences.

snip...
> 
> -kto
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Build portability: enable or disable warnings

[Dr Andrew John Hughes]

On 07:25 Mon 16 May , Erik Trimble wrote:
> On 5/16/2011 6:03 AM, Andrew Haley wrote:
> > On 05/16/2011 12:08 PM, Dalibor Topic wrote:
> >
> >> The reason I'm asking is that I'm wondering if this is something we
> >> should expect to crop up in different parts of the code base, or
> >> whether it's a one off due to some specific thing some distros chose
> >> to do different from each other.
> > That's hard to say.  It certainly could crop in other parts of the
> > code base, and I'm surprised it doesn't happen regularly.  I'm rather
> > appalled that distros do this kind of thing, TBH.
> >
> > Andrew.
> 
> 
> Just so I understand this - you're saying that by running *just* the 
> 'gcc' command on different linux systems, that actually implies that gcc 
> gets invoked with some set of flags already set? And, that there's no 
> way to just invoke "vanilla" gcc ?
> 
> If so, that's, ah, mindboggling (not in a good way)...
> 

Maybe I'm misreading what you said, but I don't find it mindboggling that
an application would have default settings for certain options.  That's
basically what we're talking about here.  If a warning can be either on
or off, then one of these two has to be a default for that exact situation
when the user does just say "gcc" and doesn't specify whether they want
the warning or not.

A number of distros change the defaults of gcc in order to produce more
warnings, as some can point to real security issues.  This runs afoul of
HotSpot's use of -Werror which presumably assumes the default set of
warnings used by a certain version of gcc.  I think the appropriate solution
to this is, as Andrew suggests, to make explicit our preference for that
warning rather than relying on the implicit defaults.

> -- 
> Erik Trimble
> Java System Support
> Mailstop:  usca22-123
> Phone:  x17195
> Santa Clara, CA
> Timezone: US/Pacific (GMT-0800)
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Build portability: enable or disable warnings

[Dr Andrew John Hughes]

On 14:03 Mon 16 May , Andrew Haley wrote:
> On 05/16/2011 12:08 PM, Dalibor Topic wrote:
> > On 5/16/11 12:48 PM, Andrew Haley wrote:
> >> On 16/05/11 11:22, Dalibor Topic wrote:
> >>> Any idea why, for example Fedora's &  Debian's, default warning sets 
> >>> differ?
> >>
> >> Because the distros patch their versions of gcc.
> > 
> > I don't see how the implication follows just yet - do you have an example?
> 
> Yes.  Debian and Gentoo turn on the -Wformat option by default.
> 

We've seen the patches, at least in Gentoo's case:

http://mirror.bytemark.co.uk/gentoo/distfiles/gcc-4.6.0-patches-1.2.tar.bz2

> > The reason I'm asking is that I'm wondering if this is something we
> > should expect to crop up in different parts of the code base, or
> > whether it's a one off due to some specific thing some distros chose
> > to do different from each other.
> 
> That's hard to say.  It certainly could crop in other parts of the
> code base, and I'm surprised it doesn't happen regularly.  I'm rather
> appalled that distros do this kind of thing, TBH.
> 

I think the issue is actually having -Werror enabled for all builds, not
just debug builds.  Without that, these additional warnings would just be
noise.  Having -Werror on also causes problems just upgrading the version
of gcc, regardless of distro-specific patching, as new warnings are
introduced or old ones reclassified.

> Andrew.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Request for review: always generate java-rmi.cgi

[Dr Andrew John Hughes]

On 21:09 Wed 11 May , Dmitry Samersoff wrote:
> Omair,
> 
> CR 7043921 . It need someone from jdk team to integrate it.
> 

Omair has commit rights so he can just push it now.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: hg: jdk7/build/jdk: 7043684: Update man pages for JDK 7 tools

[Dr Andrew John Hughes]

On 15:31 Wed 11 May , bhavesh.pa...@sun.com wrote:
> Changeset: 42c22d5a2cd0
> Author:bpatel
> Date:  2011-05-11 08:30 -0700
> URL:   http://hg.openjdk.java.net/jdk7/build/jdk/rev/42c22d5a2cd0
> 
> 7043684: Update man pages for JDK 7 tools
> Reviewed-by: skannan
> 
> ! src/linux/doc/man/appletviewer.1
> ! src/linux/doc/man/apt.1
> ! src/linux/doc/man/extcheck.1
> ! src/linux/doc/man/idlj.1
> ! src/linux/doc/man/jar.1
> ! src/linux/doc/man/jarsigner.1
> ! src/linux/doc/man/java.1
> ! src/linux/doc/man/javac.1
> ! src/linux/doc/man/javadoc.1
> ! src/linux/doc/man/javah.1
> ! src/linux/doc/man/javap.1
> ! src/linux/doc/man/javaws.1
> ! src/linux/doc/man/jconsole.1
> ! src/linux/doc/man/jdb.1
> ! src/linux/doc/man/jhat.1
> ! src/linux/doc/man/jinfo.1
> ! src/linux/doc/man/jmap.1
> ! src/linux/doc/man/jps.1
> ! src/linux/doc/man/jrunscript.1
> ! src/linux/doc/man/jsadebugd.1
> ! src/linux/doc/man/jstack.1
> ! src/linux/doc/man/jstat.1
> ! src/linux/doc/man/jstatd.1
> + src/linux/doc/man/jvisualvm.1
> ! src/linux/doc/man/keytool.1
> ! src/linux/doc/man/native2ascii.1
> ! src/linux/doc/man/orbd.1
> ! src/linux/doc/man/pack200.1
> ! src/linux/doc/man/policytool.1
> ! src/linux/doc/man/rmic.1
> ! src/linux/doc/man/rmid.1
> ! src/linux/doc/man/rmiregistry.1
> ! src/linux/doc/man/schemagen.1
> ! src/linux/doc/man/serialver.1
> ! src/linux/doc/man/servertool.1
> ! src/linux/doc/man/tnameserv.1
> ! src/linux/doc/man/unpack200.1
> ! src/linux/doc/man/wsgen.1
> ! src/linux/doc/man/wsimport.1
> ! src/linux/doc/man/xjc.1
> ! src/solaris/doc/sun/man/man1/appletviewer.1
> ! src/solaris/doc/sun/man/man1/apt.1
> ! src/solaris/doc/sun/man/man1/extcheck.1
> ! src/solaris/doc/sun/man/man1/idlj.1
> ! src/solaris/doc/sun/man/man1/jar.1
> ! src/solaris/doc/sun/man/man1/jarsigner.1
> ! src/solaris/doc/sun/man/man1/java.1
> ! src/solaris/doc/sun/man/man1/javac.1
> ! src/solaris/doc/sun/man/man1/javadoc.1
> ! src/solaris/doc/sun/man/man1/javah.1
> ! src/solaris/doc/sun/man/man1/javap.1
> ! src/solaris/doc/sun/man/man1/javaws.1
> ! src/solaris/doc/sun/man/man1/jconsole.1
> ! src/solaris/doc/sun/man/man1/jdb.1
> ! src/solaris/doc/sun/man/man1/jhat.1
> ! src/solaris/doc/sun/man/man1/jinfo.1
> ! src/solaris/doc/sun/man/man1/jmap.1
> ! src/solaris/doc/sun/man/man1/jps.1
> ! src/solaris/doc/sun/man/man1/jrunscript.1
> ! src/solaris/doc/sun/man/man1/jsadebugd.1
> ! src/solaris/doc/sun/man/man1/jstack.1
> ! src/solaris/doc/sun/man/man1/jstat.1
> ! src/solaris/doc/sun/man/man1/jstatd.1
> + src/solaris/doc/sun/man/man1/jvisualvm.1
> ! src/solaris/doc/sun/man/man1/keytool.1
> ! src/solaris/doc/sun/man/man1/native2ascii.1
> ! src/solaris/doc/sun/man/man1/orbd.1
> ! src/solaris/doc/sun/man/man1/pack200.1
> ! src/solaris/doc/sun/man/man1/policytool.1
> ! src/solaris/doc/sun/man/man1/rmic.1
> ! src/solaris/doc/sun/man/man1/rmid.1
> ! src/solaris/doc/sun/man/man1/rmiregistry.1
> ! src/solaris/doc/sun/man/man1/schemagen.1
> ! src/solaris/doc/sun/man/man1/serialver.1
> ! src/solaris/doc/sun/man/man1/servertool.1
> ! src/solaris/doc/sun/man/man1/tnameserv.1
> ! src/solaris/doc/sun/man/man1/unpack200.1
> ! src/solaris/doc/sun/man/man1/wsgen.1
> ! src/solaris/doc/sun/man/man1/wsimport.1
> ! src/solaris/doc/sun/man/man1/xjc.1
> 

Where was this reviewed?

Are there no sources for these files?

AFAIK, 'jvisualvm' is not part of OpenJDK.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Request for review: always generate java-rmi.cgi

[Dr Andrew John Hughes]

On 17:32 Tue 10 May , Kelly O'Hair wrote:
> 
> I'm a little reluctant to accept this, I'm not sure what the full 
> ramifications are.
> But I think we want it.
> 
> Is this in OpenJDK6 now?
> 

OpenJDK6 changes have to go through 7 first, so no.  But it's been in IcedTea6 
since
before there were even OpenJDK Mercurial repositories and thus in all the 
OpenJDK6
builds actually deployed to users.

> -kto
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Request for review: do not use --sync with df during sanity check

[Dr Andrew John Hughes]

On 18:14 Wed 04 May , Kelly O'Hair wrote:
> 
> On May 4, 2011, at 5:42 PM, Dr Andrew John Hughes wrote:
> 
> >> 
> >> 7042040: Remove disk space sanity check
> >> 
> > 
> > Ok, if
> > 
> > http://cr.openjdk.java.net/~andrew/sync/webrev.02/
> > 
> > looks ok, I'll push it to the build tree.
> 
> Files:
>   jdk/make/common/shared/Defs-versions.gmk
>   jdk/make/common/shared/Sanity-Settings.gmk
> Define and refer to REQUIRED_FREE_SPACE
> Those lines should be deleted too.
> 
> Otherwise looks fine.
> 

Try http://cr.openjdk.java.net/~andrew/sync/webrev.03/

> I'm not sure how much longer we can accept non-critical changes for jdk7.
> 
> The approval process is getting stricter, and my tendency is to avoid all 
> changes to jdk7
> from now on, unless it is really critical or urgent. Mostly because I hate 
> red-tape. ;^)
> 

Me too.  As OpenJDK8 repositories still aren't available [1], doesn't this mean 
OpenJDK
is effectively closed for business for at least the next three months?

> -kto
> 

1. http://mail.openjdk.java.net/pipermail/gb-discuss/2011-April/000110.html
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Request for review: do not use --sync with df during sanity check

[Dr Andrew John Hughes]

On 16:27 Wed 04 May , Kelly O'Hair wrote:
> 
> 
> I agree we should toss the check.
> 
> > 
> > I'll need a bug ID for this.
> 
> 7042040: Remove disk space sanity check
> 

Ok, if

http://cr.openjdk.java.net/~andrew/sync/webrev.02/

looks ok, I'll push it to the build tree.

> 
> -kto
> 
> > 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Request for review: do not use --sync with df during sanity check

[Dr Andrew John Hughes]

On 15:37 Wed 04 May , David Katleman wrote:
> Would be interesting to know the original objection to Andrew's change 
> last year.
> 

If there was one, it never reached me either publicly or otherwise.
The archives show no responses.

> Absent that, I see no reason this could not be removed and the change 
> looks fine.
> 
> When originally implemented 10+ years ago, disk space was considerably 
> smaller, as were buffers, so an accurate count was more relevant.
> 
> Today multiple builds on the same disk are fairly common, making the 
> check itself even less useful.
> 
> Add to that, the information being gathered is just for a WARNING, the 
> build will continue, regardless.  Hardly the need for exacting accuracy, 
> especially since the df information is then compared to static estimates 
> of how much space a build will consume.
> 
>  Dave
>  (katleman)
> 

This is my thinking too.  I'm happy to extend the fix to just get rid of the
check altogether if that seems appropriate.

I'll need a bug ID for this.

> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Request for review: do not use --sync with df during sanity check

[Dr Andrew John Hughes]

On 17:35 Wed 04 May , Omair Majid wrote:
> Hi,
> 
> Can someone please review the following webrev?
> 
> http://cr.openjdk.java.net/~omajid/webrevs/no-sync/01/
> 
> It modifies the sanity check (under linux) to use df without --sync when 
> it computes the free space. This is what is done in the solaris case. 
> The accuracy gained by using --sync is probably not worth the 
> performance loss caused by flushing disk buffers.
> 
> The patch was originally written by Andrew John Hughes 
> (ahug...@redhat.com) and we have had this in icedtea6 for almost a year now.
> 
> Thanks,
> Omair

Let's see if you do better than I did...

http://mail.openjdk.java.net/pipermail/build-dev/2010-June/003056.html
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Heads up, new jaxp source drop

[Dr Andrew John Hughes]

On 08:40 Mon 02 May , Kelly O'Hair wrote:
> 
> There has been a request for essentially that, more transparency on these 
> sources.
> The downloads are also painful, I know.
> 
> The issue with these sources is that they are effectively 'generated 
> sources', transformed
> from master sources maintained elsewhere. Having them in the repository is 
> too tempting
> for many developers, changing them either purposely or by accident.
> I need a mechanism that keeps these sources protected from any change except 
> when being
> updated by a new delivery from the jaxp team (or jaxws).
> 

There already is a mechanism... it's called "don't approve such commits".

It's especially a problem when it comes to security fixes and the 'fix' is to 
change one
URL to another.

> -kto
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Fwd: Heads up, new jaxp source drop

[Dr Andrew John Hughes]

On 09:23 Mon 02 May , Fredrik Öhrström wrote:
> Thanks!
> 
> But I am of the strong opinion that the jaxp and jaxws source code should be
> committed into the jaxp/jaxws repositories when drops are made.
> 
> //Fredrik
> 

+1
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: After the last update

[Dr Andrew John Hughes]

On 14:27 Wed 27 Apr , Frédéric Le Mouël wrote:
> cd linux_i486_compiler1/product && ./test_gamma
> java full version "1.6.0_24-b07"
> Using java runtime at: /opt/sun-jdk-1.6.0.24/jre
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)

^^^ This bit isn't OpenJDK.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: hg: jdk7/deploy/langtools: 19 new changesets

[Dr Andrew John Hughes]

Is it necessary to have all these posted to build-dev?  There doesn't
seem to be any work going on, just merging as far as I can see.  Shouldn't
this be on its own deploy-dev list?  As far as I'm aware, the deploy team
don't do any OpenJDK work anyway.

On 01:30 Wed 09 Mar , igor.nekrestya...@oracle.com wrote:
> Changeset: c6cb387190ee
> Author:jjg
> Date:  2011-02-09 14:04 -0800
> URL:   http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/c6cb387190ee
> 
> 7016750: tools/javac/nio/CompileTest failing in nightly test
> Reviewed-by: mcimadamore
> 
> ! test/tools/javac/nio/compileTest/CompileTest.java
> 
> Changeset: 3ce4e1a07e92
> Author:jjg
> Date:  2011-02-09 14:10 -0800
> URL:   http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/3ce4e1a07e92
> 
> 7010792: remove bad debugging method from javac
> Reviewed-by: mcimadamore
> 
> ! src/share/classes/com/sun/tools/javac/parser/Scanner.java
> 
> Changeset: bfa59f3e84bd
> Author:jjg
> Date:  2011-02-09 18:26 -0800
> URL:   http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/bfa59f3e84bd
> 
> 7018447: langtools launcher template fails if tools run from their own 
> directory
> Reviewed-by: jjg
> Contributed-by: daniel.sm...@oracle.com
> 
> ! src/share/bin/launcher.sh-template
> 
> Changeset: a19b1f4f23c9
> Author:jjg
> Date:  2011-02-10 14:24 -0800
> URL:   http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/a19b1f4f23c9
> 
> 7018098: CacheFSInfo persists too long
> Reviewed-by: mcimadamore
> 
> ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java
> ! 
> src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> + test/tools/javac/file/T7018098.java
> 
> Changeset: 747a7601b6d6
> Author:jjg
> Date:  2011-02-10 14:27 -0800
> URL:   http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/747a7601b6d6
> 
> 7018452: langtools not buildable on Mac
> Reviewed-by: ohair
> 
> ! make/build.xml
> 
> Changeset: e0c16199b2e0
> Author:jjg
> Date:  2011-02-10 15:05 -0800
> URL:   http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/e0c16199b2e0
> 
> 6485027: javac incorrectly handles relative paths in manifest classpath
> Reviewed-by: mcimadamore
> 
> ! src/share/classes/com/sun/tools/javac/file/Paths.java
> ! test/tools/javac/Paths/Class-Path.sh
> + test/tools/javac/Paths/Class-Path2.sh
> ! test/tools/javac/Paths/Diagnostics.sh
> 
> Changeset: bfeed79c70aa
> Author:jjg
> Date:  2011-02-11 17:10 -0800
> URL:   http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/bfeed79c70aa
> 
> 6505047: javax.lang.model.element.Element.getEnclosingElement() doesn't 
> return null for type parameter
> Reviewed-by: darcy
> 
> + test/tools/javac/processing/model/element/TestTypeParameter.java
> 
> Changeset: ef6c66215a93
> Author:jjg
> Date:  2011-02-14 14:27 -0800
> URL:   http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/ef6c66215a93
> 
> 7008433: Minor copyright changes
> Reviewed-by: jjg
> Contributed-by: kelly.oh...@oracle.com
> 
> ! test/tools/javac/4917091/Test255.java
> ! test/tools/javac/4917091/Test256a.java
> ! test/tools/javac/4917091/Test256b.java
> 
> Changeset: 351027202f60
> Author:mcimadamore
> Date:  2011-02-15 11:49 +
> URL:   http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/351027202f60
> 
> 7017664: Add listeners infrastracture to javac scopes
> Summary: Add listeners to javac scopes, added CompoundScope and correct 
> invalidation logic for ImplementationCache
> Reviewed-by: jjg
> 
> ! src/share/classes/com/sun/tools/javac/code/Scope.java
> ! src/share/classes/com/sun/tools/javac/code/Symbol.java
> ! src/share/classes/com/sun/tools/javac/code/Types.java
> ! src/share/classes/com/sun/tools/javac/comp/Check.java
> + test/tools/javac/scope/7017664/CompoundScopeTest.java
> + test/tools/javac/scope/7017664/ImplementationCacheTest.java
> 
> Changeset: fa0e4e1916f4
> Author:mcimadamore
> Date:  2011-02-15 11:51 +
> URL:   http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/fa0e4e1916f4
> 
> 7017104: improve error reporting for uncaught/undeclared exceptions from 
> try-with-resources
> Summary: twr should generate better error message when uncaught exceptions 
> are thrown by implicit call of close() method
> Reviewed-by: jjg
> 
> ! src/share/classes/com/sun/tools/javac/comp/Flow.java
> ! src/share/classes/com/sun/tools/javac/resources/compiler.properties
> ! test/tools/javac/TryWithResources/ResourceInterface.out
> ! test/tools/javac/TryWithResources/TwrFlow.out
> + test/tools/javac/diags/examples/UnreportedExceptionImplicitClose.java
> 
> Changeset: 846d6644bb70
> Author:lana
> Date:  2011-02-15 08:35 -0800
> URL:   http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/846d6644bb70
> 
> Merge
> 
> 
> Changeset: 0c24826853b2
> Author:dlsmith
> Date:  2011-02-16 10:27 -0800
> URL:   http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/0c24826853b2
> 
> 6990136: Cleanup use of Type.clon

Re: Need reviewer: CC_VER checks on compiler options

[Dr Andrew John Hughes]

On 14:33 Thu 21 Apr , Kelly O'Hair wrote:
> 
> This started out as an annoyance around the use of -Wno-clobber on Linux when 
> the gcc might
> not support it. Turned into fixing several CC_VER checks in the makefiles:
> 
> 7038711: Fix CC_VER checks for compiler options, fix use of -Wno-clobber
> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-ccver/webrev/
> 
> -kto
> 

Is there a reason for keeping this static linking at all?

-ifeq ("$(CC_VER_MAJOR)", "3")
-OTHER_LDFLAGS  += -static-libgcc
+ifeq ($(CC_MAJORVER),3)
+  OTHER_LDFLAGS  += -static-libgcc

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Need reviewer: Exceptions to mapfile rule on shared libraries

[Dr Andrew John Hughes]

On 15:14 Fri 15 Apr , Phil Race wrote:
> For jpeg its something we could consider for JDK 8 although I think its been
> called libjpeg since JDK 1.0 without apparent problems.

But you use an in-tree libjpeg (at least at present).

Having the option of linking against a system libjpeg at compile time would
mean -o libjpeg.so -l jpeg, with two different libjpegs.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Building open-jdk7 en gentoo

[Dr Andrew John Hughes]

On 11:41 Tue 19 Apr , Kelly O'Hair wrote:
> 
> I imagine there are probably hundreds of variable names that if set in the 
> environment,
> could impact the build, on purpose or by accident :^(.
> We do check for JAVA_HOME and LD_LIBRARY_PATH.
> 
> Is JAVAC some kind of typical or standard environment variable that people 
> set?
> I've never seen any use of the name JAVAC in the environment.
> If it's a common use, then yes, maybe a sanity check is in order.
> 

I hit this problem a lot with Gentoo and OpenJDK in the early days.  IcedTea 
unsets
JAVAC for this reason.  I have no idea why Gentoo sets the variable.  It is 
pretty 
much alone among GNU/Linux distros in doing so and I have no idea why it does.  
Then
again, daily Gentoo usage involves a lot more Java building than on regular 
distros
as Java packages are built from source.

The actual issue is completely broken use of JAVAC from the environment by the 
OpenJDK
build (lovely old CORBA in particular).  Instead of replacing:

javac ${OPTS} @files

with

${JAVAC} ${OPTS} @files

it uses

${JAVAC} @files

which is clearly going to break the build as things like the classpath are 
being lost.

A sanity check is probably a good first start, but maybe fixing the build to 
use it properly
might be useful long term.  I have no idea why the build is trying to use it to 
begin with,
except maybe a genuine namespace collision.

Sorry for not reporting this way back.  I was hitting it before I was working 
on IcedTea/OpenJDK
full time and before there was anything like the community there is now around 
this project.

> -kto
> 
> On Apr 19, 2011, at 4:53 AM, Frédéric Le Mouël wrote:
> 
> > Hi all,
> > 
> > I just succeed in compiling open-jdk7 on a Linux gentoo.
> > FYI, after fighting a bit, I had to unset JAVAC environment variable
> > to let it compile. I think that this checking should be done
> > in the sanity makefile target.
> > 
> > My two cents,
> > FLM.
> > -- 
> > Frédéric Le Mouël, Associate Professor | Phone: (+33|0)4 72 43 64 22
> > INRIA Amazones Team / CITI Laboratory  | Fax  : (+33|0)4 72 43 62 27
> > INSA Lyon - Claude Chappe Building | Room : 235
> > 6 avenue des Arts  | frederic.le-mo...@insa-lyon.fr
> > F-69621 Villeurbanne Cedex, France | http://citi.insa-lyon.fr/~flemouel
> > 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: openJDK7 build fails on 64bit cblfs linux

[Dr Andrew John Hughes]

On 18:03 Sat 16 Apr , luxInteg wrote:

snip...

> > What kind of Linux is this?
> 
> This is blfs linux built by compiling sources from scratch.

BLFS has instructions on building IcedTea6 which uses OpenJDK6 here:

http://www.linuxfromscratch.org/blfs/view/cvs/general/icedtea6.html
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: openJDK7 build fails on 64bit cblfs linux

[Dr Andrew John Hughes]

On 14:48 Fri 15 Apr , luxInteg wrote:
> Greetings,
> 
> I am attempting to compile openJDK-7  on a computer whth these:-
> --cpu amd64 2cores
> --OS cblfs 64-bit linux gcc-4.5.2 kernel-2.6.35.7 jdk-6u24, ant-1.8.1, 
> make-3.82,unzip-5.55,zip-3.0
> 
> 
> here are the environmental  veriables I have set:-
> 
> 
> export PATH=/usr/bin:/opt/jdk/bin:/opt/ant/bin:${PATH}
> export ALT_BOOTDIR=/opt/jdk
> #export ALT_CACERTS_FILE
> export ALT_DEVTOOLS_PATH=/usr/bin
> export BUILD_NUMBER=b29{ or 38}
> export ARCH_DATA_MODEL=64
> 
> ###  the build ends like this
> 
> 
> WARNING: LC_ALL has been set to POSIX, this can cause build failures. 
>  Try setting LC_ALL to 'C'. 
>  
> WARNING: LANG has been set to en_GB.utf8@iso, this can cause build failures. 
>  Try setting LANG to 'C'. 
>  
> WARNING: The version of unzip being used is older than 
>the required version of '5.12'. 
>The version of unzip found was ''. 
>  
> WARNING: The version of zip being used is older than 
>the required version of '2.2'. 
>The version of zip found was ''. 
>  
> ERROR: The version of make being used is older than 
>the required version of '3.81'. 
>The version of make found was ''. 
>  
> ERROR: Your BOOTDIR environment variable does not point 
>to a valid JDK for bootstrapping this build. 
>A JDK 7  build must be bootstrapped using  
>JDK 1.6.0 fcs (or later). 
>Apparently, your bootstrap JDK is version  
>Please update your ALT_BOOTDIR setting and start your build again. 
> 
> ##
> 
> 
> I have tried the following  all with the same results:-
> --versions: openjdk-7-ea-src-b138-14_apr_2011  AND  openjdk-7-ea-src-
> b129-10_feb_2011
> --with the environmental varialbe LC_ALL="C"
> --with environmental variables CC, CXX,  CFLAGS,CXXFLAGS,LDFLAGS and CPPFLAGS 
> set
> --withOUT environmental variables CC, CXX,  CFLAGS,CXXFLAGS,LDFLAGS and 
> CPPFLAGS set
> 
> advice would be appreciated
> 
> yours sincerely
> luxinteg


Look at the errors.

What is in /opt/jdk?  Where is make?
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Need reviewer: Exceptions to mapfile rule on shared libraries

[Dr Andrew John Hughes]

On 16:18 Tue 12 Apr , Kelly O'Hair wrote:
> 
> On Apr 12, 2011, at 3:58 PM, Dr Andrew John Hughes wrote:
> 
> > On 13:46 Tue 12 Apr , Kelly O'Hair wrote:
> >> 
> >> Some shared libraries do not have and will not have mapfiles, at least for 
> >> now, we
> >> give these an exception to the mapfile check (which just issues a warning).
> >> 
> >> 7033957: Library built without a mapfile: libxinerama.so
> >> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-mapfile-warning-sparc/webrev/
> >> 
> >> -kto
> >> 
> > 
> > On a related note, is it wise to have these libraries using the same names 
> > as system
> > libraries?  libxinerama is the same as libXinerama with the exception of 
> > case.  I
> > believe the JDK also has a libjpeg which is identically named to the system 
> > install.
> > Could it not be libjxinerama.so, libjavajpeg.so or some such?
> 
> I'll CC Phil.
> 
> Given the age of these libraries, I'm very hesitant to change the names.
> 
> As far as library naming in general, I can see your point, but I'm not sure 
> we could
> change them now. Maybe in JDK8?  But not after some discussions on what the 
> impact
> might be. :^(
> 

Yes, I wasn't expecting anything immediate, but I thought the topic
needed raising.  It's something I've been musing on.

My particular concern is things like libjpeg where we'd like to have
the option to link against the system install instead.  IcedTea
currently has a mass of dlopen/sym call additions to support a system
libjpeg that I don't really fancy trying to upstream.  I think having
the library calling libjpeg.so might be a barrier to just linking at
compile-time, but I have yet to try it.

> -kto
> 

Thanks,
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Need reviewer: Exceptions to mapfile rule on shared libraries

[Dr Andrew John Hughes]

On 13:46 Tue 12 Apr , Kelly O'Hair wrote:
> 
> Some shared libraries do not have and will not have mapfiles, at least for 
> now, we
> give these an exception to the mapfile check (which just issues a warning).
> 
> 7033957: Library built without a mapfile: libxinerama.so
> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-mapfile-warning-sparc/webrev/
> 
> -kto
> 

On a related note, is it wise to have these libraries using the same names as 
system
libraries?  libxinerama is the same as libXinerama with the exception of case.  
I
believe the JDK also has a libjpeg which is identically named to the system 
install.
Could it not be libjxinerama.so, libjavajpeg.so or some such?
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Fwd: Heads up, new jaxws source drop bundle

[Dr Andrew John Hughes]

On 14:15 Tue 12 Apr , Kelly O'Hair wrote:
> 
> FYI...
> 
> -kto
> 
> Begin forwarded message:
> 
> > From: "Kelly O'Hair" 
> > Date: April 12, 2011 14:07:11 PM PDT
> > To: core-libs-dev 
> > Cc: Rama Pulavarthi 
> > Subject: Heads up, new jaxws source drop bundle
> > 
> > 
> > 7034918: Integrate JAX-WS 2.2.4-b01 in to JDK 7
> > http://cr.openjdk.java.net/~ohair/openjdk7/jaxws-7034918/webrev/
> > 
> > More details on the changes here:
> >  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7034918
> > 
> > The new jaxws source drop bundle is called:
> >  jdk7-jaxws2_2_4-b01-2011_04_08.zip
> > 
> > So if you have your own ALT_DROPS_DIR cache, you need to add this file:
> >   
> > http://download.java.net/glassfish/components/jax-ws/openjdk/jdk7/jdk7-jaxws2_2_4-b01-2011_04_08.zip
> > 
> > -kto
> > 
> 

Thanks for including the URL.  It made things quicker.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Avoid certain functions in C/C++

[Dr Andrew John Hughes]

On 08:50 Wed 06 Apr , Kelly O'Hair wrote:
> 
> Just an FYI...
> 
> Anyone working with C/C++ should be well aware of the functions we should be 
> avoiding:
>   http://hub.opensolaris.org/bin/view/Community+Group+security/funclist
> 
> Microsoft has used the term "banned" and has a much more extensive list:
>   http://msdn.microsoft.com/en-us/library/bb288454.aspx
> 
> Unfortunately, we often cannot use the recommended replacements unless we 
> know that the
> replacement is available on all platforms, however, some are fairly obvious, 
> like using snprintf
> instead of sprintf.
> 
> Functions like sprintf, vsprintf, strcat, strcpy, access, chmod, chown, 
> lchown, chdir, ...
> all have know issues or have caused too many common mistakes over the years, 
> we need to
> avoid the use of these functions.
> 

Thanks for the list.  That'll surely prove a useful reference.

Have you considered using autoconf in OpenJDK?  It was pretty much designed for 
just this
scenario (checking the availability of functions).

> -kto

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: [PATCH REVIEW]: Include Shark code in the build again

[Dr Andrew John Hughes]

On 20:15 Thu 31 Mar , David Holmes wrote:
> Dr Andrew John Hughes said the following on 03/31/11 06:31:
> > On 09:42 Wed 30 Mar , Kelly O'Hair wrote:
> >> On Mar 30, 2011, at 9:26 AM, Dr Andrew John Hughes wrote:
> >>
> >>> This change (arrived at by both myself and Gary Benson separately):
> >>>
> >>> http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-1/
> >>>
> >>> fixes the issue by adding Shark back into the mix.
> >>>
> >>> Kelly, can you approve these build changes?
> >> Looks fine to me.
> >>
> > 
> > Thanks, so now I just need a HotSpot dev to give it a bug ID and push it 
> > through
> > their JPRT thing...
> 
> 7032775 filed ... working on the push
> 

Thanks David.

> David
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: [PATCH REVIEW]: Include Shark code in the build again

[Dr Andrew John Hughes]

On 09:42 Wed 30 Mar , Kelly O'Hair wrote:
> 
> On Mar 30, 2011, at 9:26 AM, Dr Andrew John Hughes wrote:
> 
> > This change (arrived at by both myself and Gary Benson separately):
> > 
> > http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-1/
> > 
> > fixes the issue by adding Shark back into the mix.
> > 
> > Kelly, can you approve these build changes?
> 
> Looks fine to me.
> 

Thanks, so now I just need a HotSpot dev to give it a bug ID and push it through
their JPRT thing...

> ---
> Although overall, I don't understand why someone used so many := assignments.
> I usually reserve := for special assignments that require a shell or complex 
> evaluation.
> The := forces an expansion of the right side on the spot, so any later 
> changes to the
> variables used on the right will have no impact on your variable. In 
> Makefiles, that's
> usually what you don't want, but I suppose there are cases where that is 
> expected.
> By using := all the time, you have created a specific order dependency on the 
> variables, but
> whatever, ...
> 

I've never really used := either, and I see your point, but that's not really 
something to change
in this changeset :-)

> -kto
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

[PATCH REVIEW]: Include Shark code in the build again

[Dr Andrew John Hughes]

In this HotSpot change:

changeset:   1932:f95d63e2154a
user:stefank
date:Tue Nov 23 13:22:55 2010 -0800
summary: 6989984: Use standard include model for Hospot

changes are made to how the files to compile are collated in the Makefiles.
Namely, this line is added:

+CORE_PATHS := $(shell find $(GAMMADIR)/src/share/vm/* -type d \! \(
-name adlc -o -name c1 -o -name gc_implementation -o -name opto -o
-name shark -o -name libadt \))

which filters various configuration-specific files out, when compiling
the list of core files to compile.

Sadly, the Shark files are then never added back in, so it never gets
built.  Shark builds succeed but you don't get a Shark VM.

This change (arrived at by both myself and Gary Benson separately):

http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-1/

fixes the issue by adding Shark back into the mix.

Kelly, can you approve these build changes?

Thanks,
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Request for review: Build changes in preparation for SE-Embedded support

[Dr Andrew John Hughes]

On 07:59 Wed 16 Mar , David Holmes wrote:
> Hi Andrew,
> 
> See inline ...
> 
> Dr Andrew John Hughes said the following on 03/16/11 07:43:
> > On 18:05 Tue 15 Mar , David Holmes wrote:
> >> BUILD_CLIENT_ONLY:
> >>
> >> http://cr.openjdk.java.net/~dholmes/jdk-bco/webrev/
> >>
> >> Provides support for building a JDK for which only the client VM is 
> >> required and/or available. Essentially avoids copying any "server" 
> >> components and creates a jvm.cfg file that aliases -server to -client. 
> >> If BUILD_CLIENT_ONLY is selected on a 64-bit build then a sanity warning 
> >> is issued. (This is only a warning because you can actually build 64-bit 
> >> client Hotspot, it just isn't supported and you can't directly build it 
> >> in a full JDK build without hacking a couple of Makefiles).
> >>
> > 
> > There still seem to be some odd whitespace changes in this one.  Otherwise,
> > looks sensible.
> 
> emacs reported odd whitespace (space+Tab) in one of the makefiles so I 
> fixed it.
> 

Ok.  I'd suggest keeping such changes separate, but you probably don't want to 
file
a CR just for this...

> >> ---
> >>
> >> Cross-compilation support:
> >>
> >> http://cr.openjdk.java.net/~dholmes/jdk-crosscomp/webrev/
> >>
> >> Basic support for cross-compilation, plus flags/settings etc for basic 
> >> ARM and PPC support in the shared open code. Cross-compilation works as 
> >> follows:
> >> - you must set the ALT_COMPILER_PATH and ALT_OPENWIN_HOME to point to 
> >> your cross-compiler (you'll also need freetype configured correctly)
> > 
> > What is ALT_OPENWIN_HOME?  And why should using the cross-compilation build
> > mean that 'X11 headers are not under /usr/include'?  Why 'OPENWIN' and not
> > 'X11'?
> 
> OPENWIN_HOME/ALT_OPENWIN_HOME are the variables used to control where to 
> find the graphics includes and libraries. These are pre-existing build 
> variables (though part of the AWT update forward ports some changes from 
> JDK6 that replaces hard-wired paths with use of these variables). When 
> cross-compiling you need to use the graphics headers that are part of 
> your cross-compilation toolset, not those on your build system (some 
> compilers will even warn you if you do use the system ones).
> 
> OPENWIN is a legacy name from the old Solaris/SunOS graphics stack:
> 
> http://en.wikipedia.org/wiki/OpenWindows
> 

Ok, so it's a legacy name for X11 that means something to Solaris users :-)

> 
> >> - CROSS_COMPILE_ARCH should be set to the architecture you are building 
> >> for eg ARM, PPC
> >> - EXTRA_CFLAGS can be used to pass cross-compilation specific compile 
> >> options
> >> - HOST_CC is a compiler that can produces binaries that can run on the 
> >> build host (used in a few parts of the JDK build). This defaults to gcc 
> >> on Linux but must be explicitly set elsewhere
> >> - Some build features such as freetype-check and 
> >> binary-file-verification are disabled as they don't apply when 
> >> cross-compiling
> >>
> > 
> > Rest seems ok.
> 
> Thanks!
> 
> Once I have Kelly's ok I'll create the CRs and get this pushed ASAP.
> 
> David
> -
> 
> >> The above will form the basis of the documentation for these changes, 
> >> but as it seems the docs live in a different repository (???) I'll need 
> >> to file a separate CR etc for that.
> >>
> >> Thanks for the reviews.
> >>
> >> Kelly: I will need to push these via TL not BUILD due to various 
> >> dependencies. However I also need the module changes to propagate from 
> >> BUILD to TL before doing so. :(
> >>
> >> David Holmes
> >> Java SE Embedded Group
> > 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: How to check out the openjdk source code from the mercurial repositories

[Dr Andrew John Hughes]

On 08:43 Tue 15 Mar , Kelly O'Hair wrote:
> 
> On Mar 15, 2011, at 2:05 AM, Steve Poole wrote:
> 
> >> 
> >> A singular process that everyone uses?  Good Luck with that. I think that 
> >> is called "herding cats". :^)
> >> Sorry, I've been doing this too long, if there is a variation on doing 
> >> development and one person finds
> >> it productive for them, they will use it.
> >> 
> > Sorry  - I was not being clear.I meant that you must have one singular 
> > process that is the agreed "official" process.   If someone decides to do 
> > something different that's ok -  provided they understand that they have to 
> > take their lumps when and if they cause a break in the main build or cause 
> > testcases to fail. The important point I was trying to make is that the 
> > process used by contributors must always work.  In my opinion the best way 
> > to achieve that is to ensure it's in use day by day.
> 
> Ah, yes we have the "official" Release Engineering build system and tool 
> requirements.
> But it's more in the form of a list of versions and fairly controlled build 
> systems used by Release Engineering
> to perform the nightly, weekly promoted, and final product builds.
> 
> The makefiles have sanity checks to try and police these versions and will 
> issue warning messages when what
> you are using differs, and fatal sanity errors there is a high risk of a bad 
> build or build failures given the version
> of some component.
> 

I think he means not so much your RE processes, but the method documented in 
the build documentation.

> These sanity rules were relaxed quite a bit when we open sourced due to the 
> larger variety of build systems
> and compiler versions being used out there.
> There is no ./configure mechanism and no 'download and install' scripts that 
> install all the specific tools needed
> to do a build, partially because solving this problem for all the Windows, 
> Solaris, and Linux systems was not
> easy. Linux is easy in this regard, Solaris a bit harder, Windows is well...  
> tricky. :^(
> 

We did that already.  It's called IcedTea.

> -kto
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: JDK8 Preliminary Repository Layout

[Dr Andrew John Hughes]

On 09:14 Thu 10 Mar , Kelly O'Hair wrote:
> 
> On Mar 9, 2011, at 4:48 PM, Dr Andrew John Hughes wrote:
> 
> >> 
> >> Other ideas were considered:
> >>  * Folding jaxp/jaxws into the root or jdk8/jdk repo
> > 
> > Sounds good.  jdk8/jdk would make more sense as jaxws depends on some 
> > classes that are in the jdk
> > tree (com.sun.net.httpserver) and we could then get rid of the Ant junk.  
> > It would be good to have
> > the code there too so we can once again track changes.  The recent security 
> > issue was a nightmare
> > due to the unavailability of the source code.
> 
> Humm "Ant junk" ok...  I'm not in love with it either, but it does provide a 
> very fast build of simple pure java code.

I haven't seen much noticeable difference and one would have thought that 
loading just javac would be quicker than
loading javac+ant classes+xml file parsing.

If you're comparing with the JDK build, then it's a bad comparison as it's 
designed so that javac is invoked
many times, sometimes on just a couple of files.  As a result, HotSpot never 
really gets to kick in.  To compare
like-with-like, you'd need to build all the JDK java files with one javac 
invocation, which would also avoid
some classes being built against bootstrap classes.

> But having separated out jaxp/jaxws/corba from the rest of the jdk, we are 
> not considering folding it all
> back in. The consideration was moving the use of the drop bundle, not forking 
> the source again.
> The separation of these sources from the basic jdk has been a major benefit 
> to the developers and was also meant
> to ease the fork issues of this code, that is and has been maintained as 
> separate open source projects and
> delivered into multiple projects, licensed differently, and re-packaged in 
> different ways.
> The jdk is downstream on these sources.
> There will be a separate discussion on this but it will focus on improving 
> the source drop complications.
> 

So where are the upstreams?  What is in these tarballs?

The problem is that you can't track down bugs because we just move from one 
random snapshot to another
with no history.  We need more transparency in this area.

> > 
> >>  * Separating out the jdk demos from the jdk repo to a separate "demos" 
> >> repository
> > 
> > Makes sense.  Having an option to disable them would be a good first step.
> 
> A 'do not build demos' option would be a fine RFE. Maybe do some preliminary 
> surgery to at least
> isolate the sources that are strictly 'demo or sample' material.  IF someone 
> has the time. ;^)
> 
> > 
> >>  * Separating out the client (awt/swing/etc) code from the jdk repo into a 
> >> separate repo
> > 
> > Why would we want to do this?  IME, there are lots of interdependencies 
> > with the other code and
> > this would make the build a nightmare.
> 
> It was suggested and talked about a little, nobody stepped forward to 
> champion it.
> I assume it would be done to categorize the sources and make the developers 
> lives easier
> when focusing on their own area.
> 

While making the build harder.

> > 
> >>  * Updating the corba sources changing it to an ant build
> > 
> > Please, no!  These Ant builds are already a nightmare and an order of 
> > magniture harder to debug than
> > the Makefiles.  Why you want to require a build system that requires an 
> > entire JDK setup (possibly
> > bringing another into the mix beyond the bootstrap JDK) is beyond me.
> > 
> 
> Ok. I had no idea is was that bad. Well, yes, ant script logging and 
> debugging is a bit bad, and the syntax
> is a little ...ah... bizarre... don't want to insult any xml people... :^(  
> The pains with ant scripts seemed worth
> it with regards to the speed it can compile/zip/jar all in one VM process. 
> And of course the potential NetBeans
> IDE usage benefits, just ask the langtools development team.
> The current corba makefile build can take 10-15 minutes on some systems, and 
> I would estimate that an ant build could
> cut that in half or maybe a quarter of that time. Especially on Windows 
> systems which aren't exactly exec demons.
> 

I don't know what the Oracle setup is but I would guess (especially from the 
'/java' stuff and other defaults)
that there is one well-defined setup.  I also guess there's only ever Oracle 
JDKs in the mix.

Out in the real world, there are all manner of possible Ant setups and they 
could be using any JDK to run on.
At one point, I think Kaffe got pulled into an OpenJDK build I was doing due to 
Ant.  In short, 

Re: Request for review: Build changes in preparation for SE-Embedded support

[Dr Andrew John Hughes]

On 18:05 Tue 15 Mar , David Holmes wrote:
> Further to my earlier review request for 7025066 I've now broken this 
> down into four parts:
> 
> - support for BUILD_CLIENT_ONLY
> - support for cross-compilation incl basic ARM/PPC support
> - AWT related changes for cross-compile/arm/pp/ plus SE-Embedded 
> specific items
> - SE-Embedded specific items
> 
> I'm addressing the first two of these here at this time. (AWT is being 
> handled by AWT folk). The SE-Embedded specific changes will come last 
> together with any necessary clean-up if things don't quite go to plan.
> 
> I haven't created CRs for these yet but will if there are no issues.
> 
> BUILD_CLIENT_ONLY:
> 
> http://cr.openjdk.java.net/~dholmes/jdk-bco/webrev/
> 
> Provides support for building a JDK for which only the client VM is 
> required and/or available. Essentially avoids copying any "server" 
> components and creates a jvm.cfg file that aliases -server to -client. 
> If BUILD_CLIENT_ONLY is selected on a 64-bit build then a sanity warning 
> is issued. (This is only a warning because you can actually build 64-bit 
> client Hotspot, it just isn't supported and you can't directly build it 
> in a full JDK build without hacking a couple of Makefiles).
> 

There still seem to be some odd whitespace changes in this one.  Otherwise,
looks sensible.

> ---
> 
> Cross-compilation support:
> 
> http://cr.openjdk.java.net/~dholmes/jdk-crosscomp/webrev/
> 
> Basic support for cross-compilation, plus flags/settings etc for basic 
> ARM and PPC support in the shared open code. Cross-compilation works as 
> follows:
> - you must set the ALT_COMPILER_PATH and ALT_OPENWIN_HOME to point to 
> your cross-compiler (you'll also need freetype configured correctly)

What is ALT_OPENWIN_HOME?  And why should using the cross-compilation build
mean that 'X11 headers are not under /usr/include'?  Why 'OPENWIN' and not
'X11'?

> - CROSS_COMPILE_ARCH should be set to the architecture you are building 
> for eg ARM, PPC
> - EXTRA_CFLAGS can be used to pass cross-compilation specific compile 
> options
> - HOST_CC is a compiler that can produces binaries that can run on the 
> build host (used in a few parts of the JDK build). This defaults to gcc 
> on Linux but must be explicitly set elsewhere
> - Some build features such as freetype-check and 
> binary-file-verification are disabled as they don't apply when 
> cross-compiling
> 

Rest seems ok.

> The above will form the basis of the documentation for these changes, 
> but as it seems the docs live in a different repository (???) I'll need 
> to file a separate CR etc for that.
> 
> Thanks for the reviews.
> 
> Kelly: I will need to push these via TL not BUILD due to various 
> dependencies. However I also need the module changes to propagate from 
> BUILD to TL before doing so. :(
> 
> David Holmes
> Java SE Embedded Group

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: Preliminary request for review: 7025066 Build system changes to support SE Embedded integration

[Dr Andrew John Hughes]

On 17:35 Thu 10 Mar , David Holmes wrote:
> Dr Andrew John Hughes said the following on 03/10/11 10:26:
> > On 22:09 Wed 09 Mar , David Holmes wrote:
> >> My original reply does not seem to have made it to build-dev.
> >>
> >> I've updated the webrev again to accommodate openjdk builds that set 
> >> REDUCED_JRE and/or REDUCED_HEADLESS_JRE. The main changes are:
> >>
> > 
> > Another problem with these webrevs is that you don't know if someone
> > changed it.  Neither do you then have any history of what went before.
> 
> Sorry, this was just a preliminary RFR so I didn't set up the webrev 
> versioning.
> 

My issue was more a personal distaste for webrevs than anything you did
wrong.  I just find it much easier if everything is in the e-mail and
can be commented on inline rather than on some website that has to be
loaded up in a separate window and can change or even disappear.  It's
especially true for big patches like this, where you really need to
break the patch down in the mail.

> I'm looking into a new structure where the JAVASE_EMBEDDED stuff is 
> factored out into Defs-embedded.gmk and Release-embedded.gmk. This will 
> relegate the reduced-jre targets to being relevant to embedded only and 
> anyone not interested just doesn't look in those files.
> 

My fear is not so much Makefile clutter as that untested options can bit rot.
People make modifications in one area and these unused options are missed.
That's actually more likely if you squirrel it away in a separate file.

> I'm also looking at breaking this into three components
> - build-client-only (if I can't somehow hide that in the embedded bits)
> - basic cross compilation support
> - SE-Embedded support (including things like COMPRESS_JARS and 
> ZIP_CAN_USE_MMAP)
> 
> Stay tuned.
> 
> Thanks again for the feedback.
> 

Thanks.

> David
> 
> >> - don't try to run freetypecheck when cross-compiling
> >> - delete build of freetypecheck from make/tools/Makefile as Sanity.gmk 
> >> will build if needed
> > 
> > These sound sensible changes.  We've run into similar issues with the
> > freetype test in IcedTea too.
> > 
> >> - for OpenJDK builds leave the JRE fonts alone (the Lucida fonts that we 
> >> don't delete are not part of OpenJDK)
> > 
> > Ah, that solves what I just explained in my last reply.
> > 
> >> David
> >> -
> >>
> >> David Holmes said the following on 03/09/11 09:33:
> >>> Andrew,
> >>>
> >>> Dr Andrew John Hughes said the following on 03/09/11 03:24:
> >>>> On 10:51 Tue 08 Mar , David Holmes wrote:
> >>>>>>> Just to clarify for people, BUILD_CLIENT_ONLY refers to building 
> >>>>>>> the client VM only.
> >>>>>>> Some of these variables should be documented in the top level 
> >>>>>>> README-builds.html file, but that
> >>>>>>> can be done under a separate CR if necessary.
> >>>>>>>
> >>>>>> What happens if there is no client VM e.g. x86_64?
> >>>>> If you are not building a client-only configuration then you should 
> >>>>> not set BUILD_CLIENT_ONLY. It's main purpose is to not attempt to 
> >>>>> copy lib//server/*.so files into the JRE/JDK image when they 
> >>>>> don't exist.
> >>>>>
> >>>> But what if someone does?  Will the sanity check not catch this?
> >>> If you specify BUILD_CLIENT_ONLY then you are telling the build system 
> >>> to not try and copy/define anything pertaining to the server VM. Whether 
> >>> or not you've built a server VM in such circumstances is irrelevant and 
> >>> certainly not a fatal error requiring a sanity check (I'm not even sure 
> >>> the sanity check can tell).
> >>>
> >>>>> I can certainly refactor into general flags, however applying those 
> >>>>> flags to all parts of the JDK build process that might want to use 
> >>>>> them is out-of-scope for what I am trying to achieve here (I just 
> >>>>> won't have time to do this and go through a myriad of builds and test 
> >>>>> runs). I'd also prefer not to create multiple changesets, which 
> >>>>> implies multiple CRs. I can't easily test these things in isolation, 
> >>>>> and individual changesets would require complete build/test cycles 
> >>>>

Re: How to check out the openjdk source code from the mercurial repositories

[Dr Andrew John Hughes]

On 06:40 Fri 11 Mar , David Holmes wrote:
> Fredrik Öhrström said the following on 03/10/11 20:22:
> > I think it is important that a recent stock mercurial install
> > can check out the full openjdk with a single clone
> > command.
> > 
> > I.e. you should not have to install special extensions just
> > to get the source code.
> 
> That's a bit of a leading/loaded question ;-)
> 
> > There are several ways this can be solved. But before
> > we dive into discussions on the possible alternatives,
> > I would like to see who else think it is a good idea.
> 
> Stepping up a level, an initial download of openjdk need not involve
> using mercurial at all. You can simply download a stable snapshot as a
> tar file; 

This makes much more sense as a starting point for new users over having
to handle Mercurial and checkouts.  It works fine if you just want to _use_
the latest and greatest, not hack on it.

> or download an install script that will do whatever is
> necessary behind the scenes to get a complete openjdk.

I don't know how that would work.  I guess IcedTea comes close to this idea
in that it detects the needed settings for the build, rather than them all
having to be passed as make variables.

> Personally I'd
> like to see that include the basic build tools as well - in which case I
> don't care about "special extensions" as I just get a working toolkit. 

What do you mean by this?  Can you give an example?

> I
> think in the scheme of things the process of getting the source code for
> the openjdk is the easiest part of the process. Depending on your
> platform setting up mercurial so that you could do that "single clone
> command" may be a far greater problem. And setting up the build
> environment an order of magnitude greater again.
> 
> > Clearly, comments from people outside of Oracle
> > are the most important!
> 
> Clearly. :)
> 

Well as a person outside Oracle, I'd agree that getting a checkout is the
least of my problems.  Configuring builds and fixing bugs is a much greater
problem than having to write a few extra 'hg clone' commands to get a full
checkout.  It's just a matter of using a for loop or cobbling together a
shell script as Kelly has done.  Trivial stuff for anyone planning to
build or hack on OpenJDK.

> Cheers,
> David
> 
> > (When the source is checked out, then there can be
> > mercurial extensions in the checked out source code
> > for example jcheck that assists in sanity tests before
> > committing. So this does not limit the actual extensions
> > used later. Only that we should not "improve" on the versioning
> > part of mercurial.)
> > 

jcheck is server-side.  It needs to be released as Free Software not
so we can all run it but so we can see what the heck it's doing and
fix issues with it.

> > //Fredrik
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

Re: JDK8 Preliminary Repository Layout

[Dr Andrew John Hughes]

On 19:27 Wed 09 Mar , Phil Race wrote:
> Andrew,
> 
> Whilst almost everything you wrote is something I agree with (like getting
> jcheck out there, not adding additional build tools/complexity), the one
> thing I quite like right now comes up here I'd like to keep is the 
> separate repos.
> Its not just hotspot,  but I've been working on JDK for a long time now,
> since before there was a hotspot and last year I built hotspot for the 
> first time,
> and even then only because I was working on the VS2010 compiler upgrade.
> 
> So I like that hotspot and jaxp/jaxws can be pre-built and pulled from an
> import JDK in a way that doesn't slow down my builds, bloat the source
> I need to pull via hg etc etc.
> 

Well HotSpot is one thing I think works well as a separate repository.
It allows us to have a stable branch for OpenJDK6 for example.  The only
real thing that stops it being independent is the servicability agent,
which, IME, would be better held in the JDK.  That would also mean that
the existing rules for building java classes could be used, rather than
reinventing it all in the HotSpot makefiles as at present.

Likewise, I think langtools works as a separate entity.  The other three
(corba, jaxp, jaxws) only really exist separately because no-one on the
OpenJDK project takes care of them.  JAXP and JAXWS get irregular build
drops, but I don't think I've seen anything more than build fixes for
CORBA.  They would be less work if maintaining in the JDK directory
as they'd share the build infrastructure.  They are hardly huge (unlike
HotSpot vs. JDK) and there are dependencies between the JDK and these.

I probably should provide some context.  During this week, I've been
looking at getting OpenJDK bootstrapping well when OpenJDK is not the
bootstrap JDK (i.e. sun.* and com.sun.* classes are not available).
To cut a long story short, it's a week later and I'm still only at
HotSpot.  So far, I've found dependencies in all but JAXP that mean
that the build has to be patched to reference other repositories
(mainly JDK but also langtools in one case).  JAXWS has to be able to
find com.sun.net.httpserver, annotation/javadoc classes and the JAXP
classes, while CORBA needs the sun.tools stuff and HotSpot needs
com.sun.jdi for the servicability agent.

Now you may think this isn't relevant and expect people to just use
OpenJDK to build.  Well, this also becomes a problem if one of these
APIs changes.  You're building stuff in CORBA, JAXWS and HotSpot against
a different API than the one they will eventually run against, hiding
issues which could be exposed at build time until run time.  

I've already run across one place where this is true.  HotSpot builds
the servicability agent with -source 1.4 -target 1.4.  Why? Because
of incompatibilies between its implementation and the com.sun.jdi
interfaces which require Comparable not Comparable.

> Maybe this doesn't matter to people who want to pull a full forest but
> its great for those working on specific components. Which I believe is
> most developers.
> 

It's hard to generalise, especially with an open source project. These
mailing lists show that there will be quite a few newbies who follow
the build guides and try downloading the entire forest.  As was mentioned
elsewhere in this discussion, the tarballs would be better for this
scenario as you don't really need the repos unless you're going to create
a patch (and even then, there are ways to do that without them).

My concern isn't the pull, but simply what makes best sense in terms
of maintenance, both of the code and the build system.  Having independent
repositories also means duplicate build code and cross-repo dependencies.
With HotSpot and langtools it makes sense as you have independent entities
(the VM and javac et. al.).  I don't think it makes sense with code that
has to then be imported into the JDK build.

> -phil.
> 
> 
> On 3/9/2011 4:48 PM, Dr Andrew John Hughes wrote:
> > On 18:32 Tue 08 Mar , Kelly O'Hair wrote:
> >> First, if we talk about the mercurial forests, it has nothing to do with 
> >> the Mercurial Forest Extension.
> >> What we really have is a set of nested repositories, sometimes called our 
> >> "forest" of repositories.
> >>
> >> This email is just about the actual layout of the repositories for jdk8.
> >>
> >> The initial thinking at this time is that the openjdk8 open forest will 
> >> look very much like openjdk7:
> >>
> >> openjdk8/
> >>  corba/
> >>  jaxp/
> >>  jaxws/
> >>  jdk/
> >>  hotspot/
> >>  langtools/
> >>
> >> 7 repositories total. Cloned from the openjdk7 rep

Re: JDK8 Preliminary Repository Layout

[Dr Andrew John Hughes]

On 18:32 Tue 08 Mar , Kelly O'Hair wrote:
> 
> First, if we talk about the mercurial forests, it has nothing to do with the 
> Mercurial Forest Extension.
> What we really have is a set of nested repositories, sometimes called our 
> "forest" of repositories.
> 
> This email is just about the actual layout of the repositories for jdk8.
> 
> The initial thinking at this time is that the openjdk8 open forest will look 
> very much like openjdk7:
> 
>openjdk8/
> corba/
> jaxp/
> jaxws/
> jdk/
> hotspot/
> langtools/
> 
> 7 repositories total. Cloned from the openjdk7 repos so we will have all the 
> openjdk7 history in the openjdk8 repositories.
> 
> Just for discussion sake, not that you can see what is behind the closed 
> curtains, we are considering changing
> the closed overlay a little, from the current jdk7 (bold is a closed repo):
> 
>   jdk7/
> corba/
> deploy/
> jaxp/
> jaxws/
> jdk/
>   src/closed/
>   test/closed
>   make/closed/
> hotspot/
>   src/closed/
>   test/closed
> install/
> langtools/
> pubs/
> 
> To something a little simplier like:
> 
>   jdk8/
> corba/
> deploy/
> jaxp/
> jaxws/
> jdk/
>   closed/{src,test,make}
> hotspot/
>   closed/{src,test,make}
> install/
> langtools/
> pubs/
> 
> The existence of these closed repos should not be a surprise, and it should 
> have no impact on the openjdk itself.
> We are just trying to consolidate and have fewer repositories. Just thought 
> it might be of interest.
> 

Not surprised.  Also don't really care where you put them as I don't seem to 
have them either way ;-)

What I would ask is do the projects get this as well?  Specifially, I'd like an 
icedtea/jdk8 at the same time please.

> But back to the openjdk8 forest.
> 
> Other ideas were considered:
>   * Folding jaxp/jaxws into the root or jdk8/jdk repo

Sounds good.  jdk8/jdk would make more sense as jaxws depends on some classes 
that are in the jdk
tree (com.sun.net.httpserver) and we could then get rid of the Ant junk.  It 
would be good to have
the code there too so we can once again track changes.  The recent security 
issue was a nightmare
due to the unavailability of the source code.

>   * Separating out the jdk demos from the jdk repo to a separate "demos" 
> repository

Makes sense.  Having an option to disable them would be a good first step.

>   * Separating out the client (awt/swing/etc) code from the jdk repo into a 
> separate repo

Why would we want to do this?  IME, there are lots of interdependencies with 
the other code and
this would make the build a nightmare.

>   * Updating the corba sources changing it to an ant build

Please, no!  These Ant builds are already a nightmare and an order of magniture 
harder to debug than
the Makefiles.  Why you want to require a build system that requires an entire 
JDK setup (possibly
bringing another into the mix beyond the bootstrap JDK) is beyond me.

What would make much more sense is to just add corba into the jdk tree.  It 
actually requires sun.tools
classes to compile rmic anyway so it would make much more sense there.

Hey, I'd just make it all one repository as they all interdepend on each other, 
but the HotSpot folks
probably wouldn't like that... ;-)   Moving the HotSpot servicability agent 
into the JDK, where the
interfaces it uses lives, might be a good idea though.  I'm currently working 
on a patch which fixes
up a mismatch between the HotSpot SA implementation and the interfaces in the 
JDK which has existed
for who knows how long (it's certainly in OpenJDK6)...

> 
> None of this seemed urgent to do out of the gate, or delay getting a 
> preliminary jdk8 layout defined.
> 

No, I agree with that.  Splitting off OpenJDK8 already seems overdue.

> I know there is some interest in pulling the actual jaxp/jaxws sources back 
> into their repos, that will
> be discussed separately, we have multiple issues with that, but I am well 
> aware of the pains that the
> source drop zip files have created.
> 

The problem is less technical and more social; there is no obvious way to 
interact with the JAXP and JAXWS
side of things.  We just get these zips of code with no idea of what changes 
are in there or why.

Basically, they shouldn't work either like they do now or did before, but like 
everything else in OpenJDK
with visible commits.  Hey, maybe we could even have some mailing list 
discussion if we're very lucky...

> As always, we would like to get comments, or additional ideas.
> 
> Separate topics:
>   * Forest Extension and it's replacement

Do we really need one?  Current status quo (get_source.sh) works fine.

>   * Mercurial server update to 1.8 or newer

I guess this is related to the forest issue.

>   * Build&Test system [1]
>   * Open bug tracking system [2]
> 

You missed off open sourcing that jcheck thing... that's the biggest problem I 
have with
the Mercurial server.  :