Re: RFR: 8265343: Update Debian-based cross-compilation recipes

[John Paul Adrian Glaubitz]

On Sun, 18 Apr 2021 17:33:56 GMT, John Paul Adrian Glaubitz 
 wrote:

>> After [JDK-8257913](https://bugs.openjdk.java.net/browse/JDK-8257913), we do 
>> not need to set a whole lot of options for cross-compiled builds. Docs 
>> should be updated to reflect that fact. Also put in more configurations that 
>> are buildable with Debian ports: these build routinely at 
>> [builds.shipilev.net](https://builds.shipilev.net/openjdk-jdk/).
>> 
>> Maybe @glaubitz wants to chime in here too :)
>
> @shipilev Nice work. I'll have a go at testing this next week. I didn't get 
> to look this week as I was busy with my dayjob.
> 
> In any case, I'm very happy to see build instructions for so many 
> architectures :-). I should also try to push some more Debian patches 
> upstream so that most cross-builds will work out of the box.

> @glaubitz Yes, please take a look if you can. If not, I'll integrate this as 
> is.

Looks good to me. It should be noted that in some cases such as m68k additional 
patches may be required to fix alignment issues, but I wanted to get these 
upstreamed anyway.

-

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

Re: RFR: 8265343: Update Debian-based cross-compilation recipes

[John Paul Adrian Glaubitz]

On Fri, 16 Apr 2021 11:57:32 GMT, Aleksey Shipilev  wrote:

> After [JDK-8257913](https://bugs.openjdk.java.net/browse/JDK-8257913), we do 
> not need to set a whole lot of options for cross-compiled builds. Docs should 
> be updated to reflect that fact. Also put in more configurations that are 
> buildable with Debian ports: these build routinely at 
> [builds.shipilev.net](https://builds.shipilev.net/openjdk-jdk/).
> 
> Maybe @glaubitz wants to chime in here too :)

@shipilev Nice work. I'll have a go at testing this next week. I didn't get to 
look this week as I was busy with my dayjob.

In any case, I'm very happy to see build instructions for so many architectures 
:-). I should also try to push some more Debian patches upstream so that most 
cross-builds will work out of the box.

-

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

Re: RFR: 8261211: Zero: alpha builds fail with '-fstack-protector not supported for this target' [v2]

[John Paul Adrian Glaubitz]

On Fri, 5 Feb 2021 10:30:56 GMT, Magnus Ihse Bursie  wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Drop -Werror
>
> Marked as reviewed by ihse (Reviewer).

> > Apparently so. But then again all platforms except alpha has this in recent 
> > gcc versions, so I think it was an understandable misunderstanding. :) Do 
> > anyone build alpha at any regularity at all? I thought Debian at least did 
> > that. But this must have been broken for quite some time?

Yes, we're building Alpha regularly in Debian. Keep in mind that we have 
additional patches in Debian which may not have been upstreamed yet (in 
particular on patch for m68k due to the different alignment).

> I discovered it after adding Alpha builds to my CIs, which are supposed to 
> cover me for ongoing Zero maintenance work. So I would be building those 
> regularly :)

Awesome, thanks for adding Alpha to your CI. Much appreciated.

> I just browsed Debian's build logs, and I believe Alpha builds are done with 
> GCC 10 there (is that right, @glaubitz?).

That is correct!

> My CIs build with GCC 9. So maybe this patch would become unnecessary when we 
> move to GCC 10 as default. I can work this around for Alpha builds in my CI, 
> but I was hoping to have the least magical incantation to build cleanly.

I think you should just add a hack to your CI to work around this issue until 
OpenJDK has moved to gcc-10.

Thanks again for helping with the less common architectures. Much much 
appreciated and I owe you a beverage of your choice at the next FOSS conference 
;-).

-

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

Re: RFR: 8256831: MIPS Zero builds fail with undefined __atomic_compare_exchange_8

[John Paul Adrian Glaubitz]

On Mon, 23 Nov 2020 11:41:08 GMT, Magnus Ihse Bursie  wrote:

>>> Otherwise this looks like something that belong in LIBJVM LIBS. In fact, if 
>>> it is _only_ needed for the hotspot build, it is really where it belong. 
>>> And even if it's needed in an additional library or two, it should be added 
>>> on those places. Only if like more or less all libraries require this 
>>> should it be added as a global flag.
>> 
>> So, would adding to `BASIC_JVM_LIBS` at `LIB_SETUP_LIBRARIES` step in 
>> `make/autoconf/libraries.m4` be a good place then?
>
> @shipilev Looks like you found the place! :-)
> 
> But make sure to build all the JDK libraries as well, to see if it is needed 
> by elsewhere as well.

As a heads-up. I have a working Loongson 2k board at home now (mips64el). So, 
in case something needs to be tested natively on MIPS, let me know.

-

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

Re: RFR: 8256829: GNU hash style is not available on MIPS

[John Paul Adrian Glaubitz]

On Sun, 22 Nov 2020 14:19:04 GMT, Aleksey Shipilev  wrote:

> For fun, I tried to build `linux-mips64el-zero-fastdebug`, and it cannot be 
> built, because linker complains:
> 
> 
> collect2: error: ld returned 1 exit status
> 
> I believe it is a regression in 16, as GNU hash style was forced with 
> [JDK-8200738](https://bugs.openjdk.java.net/browse/JDK-8200738). The way out 
> is to special-case MIPS hash-style to `sysv`. This enumerates all MIPS 
> targets that `make/autoconf/platform.m4` knows about.
> 
> Attention @DamonFool, who must be running into this problem for their MIPS 
> builds?
> 
> Testing:
>  - [x] Linux mipsel zero fastdebug build (requires additional unrelated fixes)
>  - [x] Linux mips64el zero fastdebug build

Hi Aleksey!

> For fun, I tried to build `linux-mips64el-zero-fastdebug`, and it cannot be 
> built, because linker complains:

Thanks for looking to fixing the non-mainstream architectures. I'm surprised we 
don't need the sigset patch anymore for MIPS, looks like that has been 
upstreamed already.

If you are looking into fixing more of such issues, you can have a look at the 
patches we currently carry in Debian to address various of such issues:

> https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches

I'm currently busy with LLVM but I'm planning to get more active with OpenJDK 
in the future and get more of such fixes upstreamed.

Again, thanks for fixing this. We actually use OpenJDK on MIPS targets in 
Debian.

-

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

Re: RFR: 8256182: Update qemu-debootstrap cross-compilation recipe [v3]

[John Paul Adrian Glaubitz]

On Wed, 11 Nov 2020 11:53:39 GMT, Aleksey Shipilev  wrote:

>> doc/building.md line 1100:
>> 
>>> 1098:   
>>> --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng-dev
>>>  \
>>> 1099:   --resolve-deps \
>>> 1100:   buster \
>> 
>> I'm guessing `--resolve-deps buster` is the full option; if so, it should be 
>> on a single line, otherwise it reads very strange.
>
> Not really: `buster` is the `SUITE`, it is the argument on its own.

Correct, ```buster``` is the suite (= Debian release).

You might want to use ```stable``` instead of ```buster```, then you don't need 
to adjust that part all the time as ```buster``` is a symlink to ```buster``` 
on the Debian FTP servers.

-

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

Re: RFR: 8253892: Disable misleading-indentation on clang as well as gcc

[John Paul Adrian Glaubitz]

On Tue, 3 Nov 2020 22:25:08 GMT, Magnus Ihse Bursie  wrote:

> With clang 10.0, the compiler now detects a new class of warnings. The 
> `misleading-indentation` warning has previously been disabled on gcc for 
> hotspot and libfdlibm.  Now we need to disable it for clang as well.

Why do we disable the warning instead of fixing the incorrect indentations?

-

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

Re: RFR: 8255412: Add "Linux x32" to platform selection default in custom submit workflow

[John Paul Adrian Glaubitz]

On Tue, 27 Oct 2020 05:48:49 GMT, Aleksey Shipilev  wrote:

> My rationale is simple: I am playing the whack-a-mole against the ongoing 
> x86_32 regressions here

Would it be possible that we add a Travis hook so that commits get tested once 
before they are merged?

Travis supports all of the important architectures of OpenJDK on Linux these 
days: https://docs.travis-ci.com/user/multi-cpu-architectures/

-

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

Re: RFR: 8255412: Add "Linux x32" to platform selection default in custom submit workflow

[John Paul Adrian Glaubitz]

On Mon, 26 Oct 2020 18:45:31 GMT, Aleksey Shipilev  wrote:

> I realized that JDK-8254282 missed "Linux x32" for the platform selection. 
> While you can guess it is accepted from reading the workflow, it would be 
> more convenient to have it in the default argument list.

Note that "Linux x32" is ambigious as this is the name for the x32 ABI (x86_64 
with 32-bit pointers).

-

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

Re: RFR: 8251549: Update docs on building for Git

[John Paul Adrian Glaubitz]

Hi Joe!

On 9/5/20 10:21 PM, Joe Darcy wrote:
> 8251549: Update docs on building for Git
> (...)
> PR: https://git.openjdk.java.net/jdk/pull/21

Does that mean that OpenJDK development has officially moved to Github now?

And are all OpenJDK members becoming members of the OpenJDK Github project?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: JDK14 cross-compile to arm64 fails to locate c++ header new

[John Paul Adrian Glaubitz]

Hi Jiwon!

On 8/25/20 10:06 PM, Choe, Jiwon wrote:
> === Output from failing command(s) repeated here ===
> * For target
> hotspot_variant-server_libjvm_gtest_objs_precompiled_precompiled.hpp.gch:
> In file included from
> /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/classfile/classLoaderData.hpp:28:0,
>  from
> /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/precompiled/precompiled.hpp:34:
> /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/memory/allocation.hpp:31:15:
> fatal error: new: No such file or directory
>  #include 

Do you have "build-essential" installed on the host system, assuming it's 
Debian-based?

> Tools summary:
> * Boot JDK:   openjdk version "13.0.2" 2020-01-14 OpenJDK Runtime
> Environment (build 13.0.2+8) OpenJDK 64-Bit Server VM (build 13.0.2+8,
> mixed mode, sharing)  (at /usr/lib/jvm/jdk-13.0.2)
> * Toolchain:  gcc (GNU Compiler Collection)
> * C Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-gcc)
> * C++ Compiler:   Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-g++)

That version of GCC looks a bit old. I'm not sure whether it's recent enough for
OpenJDK 14.

FWIW, I'm using a different approach for cross-building OpenJDK which works 
particularly
easy on Debian and Ubuntu due to Multi-Arch support which allows co-installing 
library
packages for different architectures on one system.

I have documented it here: 
https://wiki.debian.org/PortsDocs/BootstrappingOpenJDK

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR 8239782: CC_INTERP is only used by Zero interpreter

[John Paul Adrian Glaubitz]

Hi Coleen!

On 6/24/20 8:42 PM, coleen.phillim...@oracle.com wrote:
> Thank you for replying!
> I was going to wait for Adrian but it's a big enough change that it would bit 
> rot if I
> waited too long, and I didn't know how long it would be.  We can fix anything 
> that is
> disagreeable with a future patch, I think.  So I pushed it today.
Apologies for not replying earlier, I missed this thread as I have been busy 
with a workshop
at my day job this week.

I will have a look tomorrow morning and verify that nothing broke.

Thanks for taking care of this!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[John Paul Adrian Glaubitz]

Hi Mikael!

On 5/12/20 12:08 AM, John Paul Adrian Glaubitz wrote:
>> Adrian, did you have a chance to look at the zero patch? I’m running out of 
>> things to
>> address and I’m planning on moving forward with the JEP targeting and 
>> integration shortly.
> 
> I haven't tested the changes by Magnus yet, but they look good to me. Magnus
> create a repo on the Linux SPARC porterbox which I can pull from for testing.
> 
> I finally have time to look into it tomorrow morning (CEST) so I can
> officially ACK the changes.

Changes look fine to me with the additional changes by Magnus squashed
into yours - unless you already have done so in your latest revision.

PS: I was just wondering: Would I be eligible to apply to become a reviewer?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[John Paul Adrian Glaubitz]

Hi Mikael!

On 5/12/20 12:05 AM, Mikael Vidstedt wrote:
>>> * GNM - Magnus to file a follow-up RFE
>>>
>>> * Zero - Waiting for somebody (Adrian?) to provide more information about 
>>> what needs to be preserved
>> I haven't had the time to look at this yet due to $DAYJOB@SUSE, but I should 
>> have time tomorrow
>> as there is a public holiday tomorrow.
>>
>> Also, Magnus should get to a SPARC-T5 running Debian unstable within the 
>> next hours so he
>> will be able to perform build tests as well and provide feedback.
>>
>> Sorry for not being able to reply earlier.
> 
> Adrian, did you have a chance to look at the zero patch? I’m running out of 
> things to
> address and I’m planning on moving forward with the JEP targeting and 
> integration shortly.

I haven't tested the changes by Magnus yet, but they look good to me. Magnus
create a repo on the Linux SPARC porterbox which I can pull from for testing.

I finally have time to look into it tomorrow morning (CEST) so I can
officially ACK the changes.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[John Paul Adrian Glaubitz]

Hi Mikael!

On 5/7/20 2:47 AM, Mikael Vidstedt wrote:
> New webrev available here:
> 
> webrev: 
> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build/open/webrev/
>  
> <http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build/open/webrev/>
> incremental: 
> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build.incr/open/webrev/
>  
> <http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build.incr/open/webrev/>
> 
> I believe I have addressed all the review comments apart from:
> 
> * GNM - Magnus to file a follow-up RFE
> 
> * Zero - Waiting for somebody (Adrian?) to provide more information about 
> what needs to be preserved
I haven't had the time to look at this yet due to $DAYJOB@SUSE, but I should 
have time tomorrow
as there is a public holiday tomorrow.

Also, Magnus should get to a SPARC-T5 running Debian unstable within the next 
hours so he
will be able to perform build tests as well and provide feedback.

Sorry for not being able to reply earlier.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[John Paul Adrian Glaubitz]

Hello Erik!

On 5/4/20 5:54 PM, Erik Joelsson wrote:
> The build changes look ok and will remove all support for building on or 
> recognizing either Solaris or Sparc.
> 
> Kim's note is valid and I would recommend removing that variable completely.
> 
> I do think it would be possible to leave enough in there to enable zero 
> builds on Linux Sparc,
> but I assume you would need help from someone developing the necessary patch 
> as we don't have
> access to a Linux Sparc build environment to test it out.

Indeed, I already mentioned that in [1].

As for the testing, as you may know, I have access to pretty much any 
architecture
running Linux, including SPARC, of course.

But anyone on this list get can get free access to a SPARC-T5 running Debian
unstable through the GCC compile farm [2]. I'm one of the administrators of
this T5 (it's actually an LDOM on a T5).

The GCC compile farm has been created for exactly this purpose and we try to
make as many architectures available, so please feel free to apply for an
account and make use of that possibility :).

Thanks,
Adrian

> [1] https://mail.openjdk.java.net/pipermail/build-dev/2020-May/027344.html
> [2] https://gcc.gnu.org/wiki/CompileFarm

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[John Paul Adrian Glaubitz]

On 5/4/20 9:39 AM, John Paul Adrian Glaubitz wrote:
> I haven't looked at the changes yet, but please make sure you don't kill the
> possibility to build Zero on SPARC on Linux because that should still work
> without many extra ado.
This change should be dropped from make/autoconf/platform.m4:

@@ -148,22 +148,10 @@
   VAR_CPU=sh
   VAR_CPU_ARCH=sh
   VAR_CPU_BITS=32
   VAR_CPU_ENDIAN=little
   ;;
-sparc)
-  VAR_CPU=sparc
-  VAR_CPU_ARCH=sparc
-  VAR_CPU_BITS=32
-  VAR_CPU_ENDIAN=big
-  ;;
-sparcv9|sparc64)
-  VAR_CPU=sparcv9
-  VAR_CPU_ARCH=sparc
-  VAR_CPU_BITS=64
-  VAR_CPU_ENDIAN=big
-  ;;
 *)
   AC_MSG_ERROR([unsupported cpu $1])
   ;;
   esac
 ])

And wouldn't it make sense to keep this change for the future for the
future removal of other architectures?

@@ -564,29 +524,10 @@
   PLATFORM_EXTRACT_TARGET_AND_BUILD
   PLATFORM_SETUP_TARGET_CPU_BITS
   PLATFORM_SET_MODULE_TARGET_OS_VALUES
   PLATFORM_SET_RELEASE_FILE_OS_VALUES
   PLATFORM_SETUP_LEGACY_VARS
-  PLATFORM_CHECK_DEPRECATION
-])
-
-AC_DEFUN([PLATFORM_CHECK_DEPRECATION],
-[
-  UTIL_ARG_ENABLE(NAME: deprecated-ports, DEFAULT: false,
-  RESULT: ENABLE_DEPRECATED_PORTS,
-  DESC: [suppress the error when configuring for a deprecated port])
-
-  if test "x$OPENJDK_TARGET_OS" = xsolaris || \
-  (test "x$OPENJDK_TARGET_CPU_ARCH" = xsparc && \
-  test "x$with_jvm_variants" != xzero); then
-if test "x$ENABLE_DEPRECATED_PORTS" = "xtrue"; then
-  AC_MSG_WARN([The Solaris and SPARC ports are deprecated and may be 
removed in a future release.])
-else
-  AC_MSG_ERROR(m4_normalize([The Solaris and SPARC ports are deprecated 
and may be removed in a
-future release. Use --enable-deprecated-ports=yes to suppress this 
error.]))
-fi
-  fi
 ])
 
 AC_DEFUN_ONCE([PLATFORM_SETUP_OPENJDK_BUILD_OS_VERSION],
 [
   
#######

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[John Paul Adrian Glaubitz]

Hi Mikael!

On 5/4/20 7:12 AM, Mikael Vidstedt wrote:
> 
> Please review this change which implements part of JEP 381:
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224
> webrev: 
> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/build/open/webrev/
> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787
> 
> 
> Note: When reviewing this, please be aware that this exercise was *extremely* 
> mind-numbing, so I appreciate your help reviewing all the individual changes 
> carefully. You may want to get that coffee cup filled up (or whatever keeps 
> you awake)!
I haven't looked at the changes yet, but please make sure you don't kill the
possibility to build Zero on SPARC on Linux because that should still work
without many extra ado.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8199138: Add RISC-V support to Zero

[John Paul Adrian Glaubitz]

Hello!

On 4/6/20 8:09 PM, John Paul Adrian Glaubitz wrote:
> I have reduced the complexity of the patch as some of the changes from
> the previous change set are not necessary, in particular the changes
> to config.{guess,sub}, the definition of EM_RISCV (which is already defined
> by the Linux kernel headers now provided the kernel is recent enough).

After checking various kernel headers of older but still supported enterprise
Linux distributions such as SLE-12 and RHEL-7, I think it's probably better
to include the redundant EM_RISCV definition to avoid build problems on these
platforms [1]. I just want to be on the safe side.

The build changes are unchanged.

Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8199138/webrev.03/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

RFR: 8199138: Add RISC-V support to Zero

[John Paul Adrian Glaubitz]

Hello!

Please review this small change which adds basic support for the riscv64
target for Linux/Zero [1].

I have reduced the complexity of the patch as some of the changes from
the previous change set are not necessary, in particular the changes
to config.{guess,sub}, the definition of EM_RISCV (which is already defined
by the Linux kernel headers now provided the kernel is recent enough).

Additionally, I'm leaving the change for os::get_summary_cpu_info() out
as I would like to clean up this code a bit first - it's rather inconsistent
considering whether the arch override is used for Hotspot arches only or
also for Zero arches.

Thanks,
Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8199138/webrev.02/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[John Paul Adrian Glaubitz]

On 3/3/20 10:26 AM, Andrew Haley wrote:
> But one of the few things of which I am certain is that we must not
> allow the needs of backporting to determine the future of Java. That's
> the way of staying in the past.

Unpopular opinion: It's the enterprise customers that mainly pay for the
development of software, not the users of rolling release distributions.

I know that maintaining old stuff is boring but that's where the money
is made. Too many developers unfortunately seem to forget that.

> As Patrick Head put it, “Some people tell me that Formula 1 would be
> better if the drivers still used stick shifts, but that’s a bit like
> saying, 'isn’t it a pity we don’t still walk around in clogs!'”

Maintenance of stable software isn't done for nostalgic reasons, it's
because enterprise customers need a reliable and stable platform to
run their businesses on. A lot of businesses are still running on JDK-8
for this reason.

Running bleeding edge software might be an option for a single desktop
user, but not in an enterprise environment with thousands of users
or in a critical environment like the booking system of an airline.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Backporting JDK-8235960 to jdk14

[John Paul Adrian Glaubitz]

Hi!

I would like to get the fix JDK-8235960 [1] backported to jdk14, what
do I need to do to achieve that? I have not pushed to any repos besides
"jdk" before.

Thanks,
Adrian

> [1] http://hg.openjdk.java.net/jdk/jdk/rev/2baee52c6a1c

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: JDK-8239789 Follow-up on JVM feature rewrite

[John Paul Adrian Glaubitz]

On 2/21/20 4:36 PM, Magnus Ihse Bursie wrote:
> On 2020-02-21 16:15, Erik Gahlin wrote:
>> jfr should be JDK Flight Recorder.
> Thanks, I should have checked and not guessed. :)
> 
> I updated the code but will not send out a new webrev.
Shouldn't "deprecated-ports" be parts of that list as well?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Is anyone still building multiple JVMs?

[John Paul Adrian Glaubitz]

On 2/20/20 9:32 AM, Magnus Ihse Bursie wrote:
>>> I think we should also ask -- is anyone actually shipping a JDK build with 
>>> multiple libjvm variants in it?
>> Debian and therefore Ubuntu always build and ship both Hotspot and Zero on
>> every architecture which supports both [1].
> But that is not supported by the build system -- if you build zero, you 
> cannot build any other JVM at the
> same time! So if you ship this, you must build them separately and then in a 
> post-processing step copy them
> together and modify jvm.cfg, right?
Yeah, I think those are separate builds running each their own configure run 
[1].

Adrian

> [1] 
> https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/rules

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Is anyone still building multiple JVMs?

[John Paul Adrian Glaubitz]

On 2/20/20 9:24 AM, Ioi Lam wrote:
> I think we should also ask -- is anyone actually shipping a JDK build with 
> multiple libjvm variants in it?
Debian and therefore Ubuntu always build and ship both Hotspot and Zero on
every architecture which supports both [1].

Adrian

> [1] https://packages.debian.org/source/sid/openjdk-14

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

[John Paul Adrian Glaubitz]

Hi Kim!

On 2/18/20 5:07 PM, John Paul Adrian Glaubitz wrote:
> I forgot to use a reference type when I tried the definition within the class
> which is why it failed for me. I will test the proper approach and post a
> patch in a few minutes.

Here's the patch with the changes as you suggested [1].

Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8239001/webrev.03/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

[John Paul Adrian Glaubitz]

On 2/18/20 4:55 PM, Kim Barrett wrote:
> Nope.  That unnecessarily pollutes the global namespace with “dummy_regs”.
> 
> The dummy declaration should be in the RegistersForDebugging class as I 
> suggested earlier.
> But you say that “doesn’t work”.  I thought perhaps that meant I’d made was a 
> mistake in the
> code snippet I’d sent, but that seems to work for me.  So what do you mean by 
> “doesn’t work”?

Ah, I completely missed that mail and the code snippet. Sorry.

I forgot to use a reference type when I tried the definition within the class
which is why it failed for me. I will test the proper approach and post a
patch in a few minutes.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8199138: Add RISC-V support to Zero

[John Paul Adrian Glaubitz]

Hi Aleksey!

On 2/17/20 9:07 AM, Aleksey Shipilev wrote:
> On 2/12/20 6:13 PM, Aleksey Shipilev wrote:
>> On 2/12/20 6:00 PM, John Paul Adrian Glaubitz wrote:
>>> On 2/12/20 5:59 PM, Aleksey Shipilev wrote:
>>>> On 2/12/20 5:54 PM, John Paul Adrian Glaubitz wrote:
>>>>> I assume I can push with those changes and mark it as Reviewed-by: erikj, 
>>>>> shade?
>>>>
>>>> Mark it, yes. I believe non-trivial (yet exceedingly simple) things like 
>>>> these require waiting for
>>>> 24 hours to anyone else to chime in with comments. There seem to be no 
>>>> rush to get it in, right?
>>>
>>> No rush, no. Just wanted to make sure that it's fine to push then :).
>>
>> Yes, I believe it would be fine to push then.
> 
> I think it is fine to push now ;)

I have come up with a better and cleaner approach now which I will
post later this week. But I want to get the fix for JDK-8239001 out
first.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

[John Paul Adrian Glaubitz]

Hi Kim!

On 2/15/20 10:30 PM, Kim Barrett wrote:
> I prefer the approach using a non-ODR-used dummy to the approach of
> casting of some random number to an address.  Non-ODR-used
> declarations are well supported by the standard (C++03 3.2) and widely
> used; that's the basis for the "sizeof trick" metaprogramming idiom,
> for example.

I've now understood that approach and implemented it. Please see my patch in 
[1].

FWIW, I have tried to put the declaration of RegistersForDebugging outside
the X_offset() functions but that doesn't work. Hope the change is now
okay as is :).

Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8239001/webrev.02/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

[John Paul Adrian Glaubitz]

Hi Andrew!

On 2/16/20 12:07 PM, Andrew Haley wrote:
> On 2/15/20 6:33 PM, John Paul Adrian Glaubitz wrote:
>>
>> Here is another approach for fixing 8238281 [1]. Please review.
>>
>>> [1] http://cr.openjdk.java.net/~glaubitz/8239001/webrev.01/
> 
> Can you give us a bit more explanation about why 8238281 broke linux-sparc,
> and why your proposal is valid? This doesn't look valid to me:

The problem is that i[j] is a non-const expression which is not allowed
when using offsetof(). I have included the GCC error message in the
bug report [1].

>   (((RegistersForDebugging*)16)->f[0])
> 

This basically just calculates the offset within the array f with the
offset j, hence the factor j.

I have to admit though that I haven't fully understood Kim's non-odr-used
approach yet.

Thanks,
Adrian

> [1] https://bugs.openjdk.java.net/browse/JDK-8239001

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

[John Paul Adrian Glaubitz]

Hi!

Here is another approach for fixing 8238281 [1]. Please review.

Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8239001/webrev.01/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

[John Paul Adrian Glaubitz]

On 2/13/20 8:35 PM, Kim Barrett wrote:
> I don't think this is the right way to address this problem.
> 
> I think the JDK-8238281 change to offset_of and the associated
> addition of -Wno-invalid-offsetof to the build configuration was a
> mistake, and should be reverted.  Those changes seem unrelated to the
> purpose of JDK-8238281, which was to raise the minimum acceptable gcc
> version.

Alternatively, this works as well:

glaubitz@gcc202:~/jdk-hg$ hg diff
diff -r 274a0bcce99d src/hotspot/cpu/sparc/macroAssembler_sparc.hpp
--- a/src/hotspot/cpu/sparc/macroAssembler_sparc.hppSat Feb 15 17:35:57 
2020 +0800
+++ b/src/hotspot/cpu/sparc/macroAssembler_sparc.hppSat Feb 15 21:05:10 
2020 +0300
@@ -485,12 +485,12 @@
 
   void print(outputStream* s);
 
-  static int i_offset(int j) { return offset_of(RegistersForDebugging, i[j]); }
-  static int l_offset(int j) { return offset_of(RegistersForDebugging, l[j]); }
-  static int o_offset(int j) { return offset_of(RegistersForDebugging, o[j]); }
-  static int g_offset(int j) { return offset_of(RegistersForDebugging, g[j]); }
-  static int f_offset(int j) { return offset_of(RegistersForDebugging, f[j]); }
-  static int d_offset(int j) { return offset_of(RegistersForDebugging, d[j / 
2]); }
+  static int i_offset(int j) { return offset_of(RegistersForDebugging, i) + j 
* sizeof(((RegistersForDebugging*)16)->i[0]); }
+  static int l_offset(int j) { return offset_of(RegistersForDebugging, l) + j 
* sizeof(((RegistersForDebugging*)16)->l[0]); }
+  static int o_offset(int j) { return offset_of(RegistersForDebugging, o) + j 
* sizeof(((RegistersForDebugging*)16)->o[0]); }
+  static int g_offset(int j) { return offset_of(RegistersForDebugging, g) + j 
* sizeof(((RegistersForDebugging*)16)->g[0]); }
+  static int f_offset(int j) { return offset_of(RegistersForDebugging, f) + j 
* sizeof(((RegistersForDebugging*)16)->f[0]); }
+  static int d_offset(int j) { return offset_of(RegistersForDebugging, d) + (j 
/ 2) * sizeof(((RegistersForDebugging*)16)->d[0]); }
 
   // gen asm code to save regs
   static void save_registers(MacroAssembler* a);

What about this approach?

Alternatively, with C++11, this should work as well:

#include 

static int i_offset(int j) { return offset_of(RegistersForDebugging, i) + j * 
sizeof(std::declval().i[0]); }

Comments?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: JDK build fails on Arch Linux

[John Paul Adrian Glaubitz]

Hello!

On 2/12/20 11:15 PM, Ty Young wrote:
> Attempting to build any JDK version with a supported boot JDK results in 
> failure:
> 
> 
> Building target 'images' in configuration 'linux-x86_64-server-release'
> Warning: No SCM configuration present and no .src-rev
> make[3]: *** No rule to make target 
> '/home/ty/Downloads/panama-foreign-linkToNative/build/linux-x86_64-server-release/buildtools/langtools_tools_classes/_the.BUILD_TOOLS_LANGTOOLS.vardeps',
>  needed by 
> '/home/ty/Downloads/panama-foreign-linkToNative/build/linux-x86_64-server-release/buildtools/langtools_tools_classes/_the.BUILD_TOOLS_LANGTOOLS_batch'.
>  Stop.
> make[3]: *** Waiting for unfinished jobs
> make[3]: *** No rule to make target 
> '/home/ty/Downloads/panama-foreign-linkToNative/build/linux-x86_64-server-release/make-support/vardeps/make/ReleaseFile.gmk/create-info-file.vardeps',
>  needed by 
> '/home/ty/Downloads/panama-foreign-linkToNative/build/linux-x86_64-server-release/jdk/release'.
>  Stop.
> make[2]: *** [make/Main.gmk:405: release-file] Error 2
> make[2]: *** Waiting for unfinished jobs
> make[2]: *** [make/Main.gmk:70: buildtools-langtools] Error 2
> make[3]: *** No rule to make target 
> '/home/ty/Downloads/panama-foreign-linkToNative/build/linux-x86_64-server-release/make-support/vardeps/make/ModuleWrapper.gmk/java.base/ORDERED_CFG_VARIANTS.vardeps',
>  needed by 
> '/home/ty/Downloads/panama-foreign-linkToNative/build/linux-x86_64-server-release/support/modules_libs/java.base/jvm.cfg'.
>  Stop.
> make[3]: *** Waiting for unfinished jobs
> make[2]: *** [make/Main.gmk:158: java.base-copy] Error 2
> 
> ERROR: Build failed for target 'images' in configuration 
> 'linux-x86_64-server-release' (exit code 2)
> 
> 
> The exact commands used to compile are:
> 
> 
> "bash configure --disable-warnings-as-errors" and "make images"

Try building with MAKE_VERBOSE=y QUIETLY= LOG=debug to get a more detailed 
debug output.

> This used to work but after an update to *something* it no longer builds. 
> Given that I use Arch Linux(which uses newer software) it could just be a bug 
> introduced in some package and might be fixed soon(TM) but I figure I'd hit 
> up the this list to see if anyone can confirm this.

I'm building on both Debian unstable and openSUSE Tumbleweed regularly without 
any issues.

Just did a successful build on Debian unstable which is bleeding edge at the 
moment.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8199138: Add RISC-V support to Zero

[John Paul Adrian Glaubitz]

Hi!

On 2/12/20 5:51 PM, Aleksey Shipilev wrote:
> Neat. Looks good to me.
> 
> Minor nits in os_linux.cpp:
> 
> *) Can you move the comment to the #define line, as it is done in the similar 
> blocks in the same file?
> 
> 1854 #ifndef EM_RISCV  /* RISCV */
> 1855   #define EM_RISCV  243
> 1856 #endif
> 
> *) I believe this one is sorted alphabetically, so RISCV should be between 
> __powerpc64__ and S390?
> 
> -AARCH64, ALPHA, ARM, AMD64, IA32, IA64, M68K, MIPS, MIPSEL, PARISC, 
> __powerpc__,
> __powerpc64__, S390, SH, __sparc
> +AARCH64, ALPHA, ARM, AMD64, IA32, IA64, M68K, MIPS, MIPSEL, PARISC, 
> __powerpc__,
> __powerpc64__, S390, SH, __sparc, RISCV

I have done that now. Updated RFR in [1].

Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8199138/webrev.01/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8199138: Add RISC-V support to Zero

[John Paul Adrian Glaubitz]

On 2/12/20 5:59 PM, Aleksey Shipilev wrote:
> On 2/12/20 5:54 PM, John Paul Adrian Glaubitz wrote:
>> I assume I can push with those changes and mark it as Reviewed-by: erikj, 
>> shade?
> 
> Mark it, yes. I believe non-trivial (yet exceedingly simple) things like 
> these require waiting for
> 24 hours to anyone else to chime in with comments. There seem to be no rush 
> to get it in, right?

No rush, no. Just wanted to make sure that it's fine to push then :).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8199138: Add RISC-V support to Zero

[John Paul Adrian Glaubitz]

Hi!

On 2/12/20 5:51 PM, Aleksey Shipilev wrote:
> On 2/12/20 5:14 PM, John Paul Adrian Glaubitz wrote:
>>> [1] http://cr.openjdk.java.net/~glaubitz/8199138/webrev.00/
> 
> Neat. Looks good to me.
> 
> Minor nits in os_linux.cpp:
> 
> *) Can you move the comment to the #define line, as it is done in the similar 
> blocks in the same file?
> 
> 1854 #ifndef EM_RISCV  /* RISCV */
> 1855   #define EM_RISCV  243
> 1856 #endif

Yes.

> *) I believe this one is sorted alphabetically, so RISCV should be between 
> __powerpc64__ and S390?
> 
> -AARCH64, ALPHA, ARM, AMD64, IA32, IA64, M68K, MIPS, MIPSEL, PARISC, 
> __powerpc__,
> __powerpc64__, S390, SH, __sparc
> +AARCH64, ALPHA, ARM, AMD64, IA32, IA64, M68K, MIPS, MIPSEL, PARISC, 
> __powerpc__,
> __powerpc64__, S390, SH, __sparc, RISCV

Sure.

I assume I can push with those changes and mark it as Reviewed-by: erikj, shade?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

RFR: 8199138: Add RISC-V support to Zero

[John Paul Adrian Glaubitz]

Hi!

This is an updated RFR to add basic RISC-V support to Zero.

This patch is being used for the riscv64 port in Debian.

Please review the changes in [1].

Thanks,
Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8199138/webrev.00/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8235960: Zero should not trigger the deprecation warning for ports

[John Paul Adrian Glaubitz]

Hi!

On 12/16/19 10:08 PM, John Paul Adrian Glaubitz wrote:
> On 12/16/19 10:08 PM, Mikael Vidstedt wrote:
>>
>> I’m not actually sure, but just to be on the safe side I’d prefer to add the 
>> grouping.
> 
> Okay, will do.

Updated revision here:

> http://cr.openjdk.java.net/~glaubitz/8235960/webrev.01/

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8235960: Zero should not trigger the deprecation warning for ports

[John Paul Adrian Glaubitz]

On 12/16/19 10:08 PM, Mikael Vidstedt wrote:
> 
> I’m not actually sure, but just to be on the safe side I’d prefer to add the 
> grouping.

Okay, will do.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8235960: Zero should not trigger the deprecation warning for ports

[John Paul Adrian Glaubitz]

On 12/16/19 8:40 PM, John Paul Adrian Glaubitz wrote:
> Hi Mikael!
> 
> On 12/16/19 8:38 PM, Mikael Vidstedt wrote:
>> You need to group the OPENJDK_TARGET_CPU_ARCH and with_jvm_variants checks. 
>> The suggested change will incorrectly *not* produce a warning for 
>> solaris/*/zero.
>>
>> Something like this should do the trick:
>>
>> if test "x$OPENJDK_TARGET_OS" = xsolaris || (test 
>> "x$OPENJDK_TARGET_CPU_ARCH" = xsparc && test "x$with_jvm_variants" != 
>> xzero); then
> 
> 
> Thanks for the review. As far as I remember correctly, Zero is not supported, 
> is it?
"Zero is not supported on Solaris", I meant. Sorry.

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8235960: Zero should not trigger the deprecation warning for ports

[John Paul Adrian Glaubitz]

Hi Mikael!

On 12/16/19 8:38 PM, Mikael Vidstedt wrote:
> You need to group the OPENJDK_TARGET_CPU_ARCH and with_jvm_variants checks. 
> The suggested change will incorrectly *not* produce a warning for 
> solaris/*/zero.
> 
> Something like this should do the trick:
> 
> if test "x$OPENJDK_TARGET_OS" = xsolaris || (test 
> "x$OPENJDK_TARGET_CPU_ARCH" = xsparc && test "x$with_jvm_variants" != xzero); 
> then


Thanks for the review. As far as I remember correctly, Zero is not supported, 
is it?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports

[John Paul Adrian Glaubitz]

Hi Martin!

On 12/15/19 5:07 PM, Martin Buchholz wrote:
> I tried both variants as below, but autoconf is failing me when I try to 
> regenerate
> configure.
> 
> 
> You didn't say how.
> (...)
> bulding.md says
> 
> 
> The build system will detect if the Autoconf source files have changed, and
> will trigger a regeneration of the generated script if needed. You can also
> manually request such an update by `bash configure autogen`.

Yep. Already figured out that my changes didn't work. I got it working now
and posted JDK-8235960 for review.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

RFR: 8235960: Zero should not trigger the deprecation warning for ports

[John Paul Adrian Glaubitz]

Hi!

JDK-8234370 introduced a deprecation warning for ports that are going to be 
removed
in the future. The change in question checks for the target architecture and 
operating
system but does however does not account for the Zero variant which doesn't 
need support
for a specific target besides a few autonconf definitions and some #ifdef magic.

This change extends the change from JDK-8234370 to additionally test whether 
we're building
the Zero variant. With this change, I can configure OpenJDK Zero on a 
Linux/SPARC target
again without getting a deprecation message.

Please review.

Thanks,
Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8235960/webrev.00/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports

[John Paul Adrian Glaubitz]

Hi!

On 12/15/19 10:13 AM, John Paul Adrian Glaubitz wrote:
> The change for JDK-8234370 also triggers for Zero which is not correct.
> 
> It should trigger for the normal build only.
> 
> I will file a bug report.

I have filed JDK-8235960 now, but I haven't managed to come up with a working 
fix
yet.

I tried both variants as below, but autoconf is failing me when I try to 
regenerate
configure.

Can anyone remind me what the proper way of regenerating the configure script is
these days?

Thanks,
Adrian

glaubitz@gcc202:~/jdk$ hg diff
diff -r eefd0a71c160 make/autoconf/platform.m4
--- a/make/autoconf/platform.m4 Sat Dec 14 13:50:34 2019 +0800
+++ b/make/autoconf/platform.m4 Sun Dec 15 12:46:47 2019 +0300
@@ -566,7 +566,7 @@
   AC_ARG_ENABLE(deprecated-ports, 
[AS_HELP_STRING([--enable-deprecated-ports@<:@=yes/no@:>@],
[Suppress the error when configuring for a deprecated port 
@<:@no@:>@])])
 
-  if test "x$OPENJDK_TARGET_OS" = xsolaris || test "x$OPENJDK_TARGET_CPU_ARCH" 
= xsparc; then
+  if test "x$OPENJDK_TARGET_OS" = xsolaris || test "x$OPENJDK_TARGET_CPU_ARCH" 
= xsparc && test "x$JVM_VARIANTS" != xzero; then
 if test "x$enable_deprecated_ports" = "xyes"; then
   AC_MSG_WARN([The Solaris and SPARC ports are deprecated and may be 
removed in a future release.])
 else
glaubitz@gcc202:~/jdk$

glaubitz@gcc202:~/jdk$ hg diff
diff -r eefd0a71c160 make/autoconf/platform.m4
--- a/make/autoconf/platform.m4 Sat Dec 14 13:50:34 2019 +0800
+++ b/make/autoconf/platform.m4 Sun Dec 15 12:47:35 2019 +0300
@@ -566,7 +566,7 @@
   AC_ARG_ENABLE(deprecated-ports, 
[AS_HELP_STRING([--enable-deprecated-ports@<:@=yes/no@:>@],
[Suppress the error when configuring for a deprecated port 
@<:@no@:>@])])
 
-  if test "x$OPENJDK_TARGET_OS" = xsolaris || test "x$OPENJDK_TARGET_CPU_ARCH" 
= xsparc; then
+  if test "x$OPENJDK_TARGET_OS" = xsolaris || test "x$OPENJDK_TARGET_CPU_ARCH" 
= xsparc && ! HOTSPOT_CHECK_JVM_VARIANT(zero); then
 if test "x$enable_deprecated_ports" = "xyes"; then
   AC_MSG_WARN([The Solaris and SPARC ports are deprecated and may be 
removed in a future release.])
 else
glaubitz@gcc202:~/jdk$

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports

[John Paul Adrian Glaubitz]

Hi!

The change for JDK-8234370 also triggers for Zero which is not correct.

It should trigger for the normal build only.

I will file a bug report.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports

[John Paul Adrian Glaubitz]

Hi!

On 11/22/19 8:01 PM, Mikael Vidstedt wrote:
> Erik/Tim, thanks for the reviews!
> 
> On more small change: Update building.md (and .html) to reflect the 
> deprecation of the ports:
> 
> http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.02.incr/open/webrev/
>  
> <http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.02.incr/open/webrev/>
> 
> Let me know if you think of other places where this should be reflected.

Out of curiosity: With Oracle Solaris officially being supported until at
least 2034, does that mean the SPARC port of OpenJDK-11 will be maintained
until 2034 as well?

So far I don't understand the reasoning behind deprecating Solaris SPARC when
the platform has still official support until 2034. The last SPARC CPU was
the M8 which was released 2017.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR (trivial): 8219519: Remove linux_sparc.ad and linux_aarch64.ad

[John Paul Adrian Glaubitz]

Hello!

On 3/1/19 3:25 PM, Magnus Ihse Bursie wrote:
>> It's a bit difficult for me to test this patch since I don't have a sparc or 
>> arm machine.
Both SPARC and AArch64 machines running Linux can be accessed through the gcc
compile farm. Any open source developer can request an account for these
machines.

See:

> https://gcc.gnu.org/wiki/CompileFarm
> https://cfarm.tetaneutral.net/machines/list/

I'm admin for the sparc64 box running Linux in case someone needs any particular
package to be installed.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Fail to cross compiling jdk12 for mips64el-linux-gnu target

[John Paul Adrian Glaubitz]

On 1/25/19 3:44 PM, Ao Qi wrote:> FYI, if one wants to debug this issue, below 
is some sctripts I used
> to cross compile a mips zero jdk, which can trigger the bug.

Native builds on Debian unstable on mips* work?

> do one patch [1] then make images

What about the alignment patch? Is that still required?

> https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/hotspot-mips-align.diff

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Fail to cross compiling jdk12 for mips64el-linux-gnu target

[John Paul Adrian Glaubitz]

Hi!

On 1/24/19 3:28 AM, Leslie Zhai wrote:
> Please give me some advice about how to fix the root cause, thanks a lot!

Just as a heads-up: In Debian we have two patches required for OpenJDK on the 
mips
targets:

> https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/hotspot-mips-align.diff
> https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/patches/mips-sigset.diff

I think the stuff with sigset was being worked on upstream at some point, but it
wasn't finished if I remember correctly.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

[John Paul Adrian Glaubitz]

On 1/24/19 2:11 PM, Magnus Ihse Bursie wrote:
> The default binutils linker used by gcc, the bfd linker, is slow.
> The new replacement, gold, has been distributed alongside gcc for
> several years now, and is a well mature, and much faster, replacement.

I would recommend testing this change on all supported targets. Gold is
definitely not as mature on all targets as bfd in my experience. There
are still some cases where it can cause issues.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: jdk HEAD fails to build?

[John Paul Adrian Glaubitz]

Hi Severin!

On 11/12/18 11:05 AM, Severin Gehwolf wrote:
> Is anybody else seing this?

I just pulled the latest revision and was able to built HEAD
just fine.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: build openjdk8 on ubuntu18.04.1

[John Paul Adrian Glaubitz]

Hi!

Please run:

apt build-dep openjdk-8

as root before you continue.

If that doesn’t help, try with “openjdk-9”, “openjdk-10” or “openjdk-11”.

Cheers,
Adrian

> On Oct 25, 2018, at 7:03 AM, Zonghai Shang  wrote:
> 
> Here is my config:
> 
> Running generated-configure.sh
> configure: Configuration created at Thu Oct 25 11:35:50 HKT 2018.
> configure: configure script generated at timestamp 1539613812.
> checking for basename... /usr/bin/basename
> checking for bash... /bin/bash
> checking for cat... /bin/cat
> checking for chmod... /bin/chmod
> checking for cmp... /usr/bin/cmp
> checking for comm... /usr/bin/comm
> checking for cp... /bin/cp
> checking for cut... /usr/bin/cut
> checking for date... /bin/date
> checking for gdiff... no
> checking for diff... /usr/bin/diff
> checking for dirname... /usr/bin/dirname
> checking for echo... /bin/echo
> checking for expr... /usr/bin/expr
> checking for file... /usr/bin/file
> checking for find... /usr/bin/find
> checking for head... /usr/bin/head
> checking for ln... /bin/ln
> checking for ls... /bin/ls
> checking for mkdir... /bin/mkdir
> checking for mktemp... /bin/mktemp
> checking for mv... /bin/mv
> checking for nawk... /usr/bin/nawk
> checking for printf... /usr/bin/printf
> checking for rm... /bin/rm
> checking for sh... /bin/sh
> checking for sort... /usr/bin/sort
> checking for tail... /usr/bin/tail
> checking for tar... /bin/tar
> checking for tee... /usr/bin/tee
> checking for touch... /usr/bin/touch
> checking for tr... /usr/bin/tr
> checking for uname... /bin/uname
> checking for uniq... /usr/bin/uniq
> checking for wc... /usr/bin/wc
> checking for which... /usr/bin/which
> checking for xargs... /usr/bin/xargs
> checking for gawk... no
> checking for mawk... mawk
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for fgrep... /bin/grep -F
> checking for a sed that does not truncate output... /bin/sed
> checking for cygpath... no
> checking for greadlink... no
> checking for readlink... /bin/readlink
> checking for df... /bin/df
> checking for SetFile... no
> checking for cpio... /bin/cpio
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... x86_64-unknown-linux-gnu
> checking target system type... x86_64-unknown-linux-gnu
> checking openjdk-build os-cpu... linux-x86_64
> checking openjdk-target os-cpu... linux-x86_64
> checking compilation type... native
> checking for top-level directory... /home/yiji/jvm/jdk8u
> checking for presence of closed sources... no
> checking if closed source is suppressed (openjdk-only)... no
> checking which variant of the JDK to build... normal
> checking which interpreter of the JVM to build... template
> checking which variants of the JVM to build... server
> checking which debug level to use... fastdebug
> checking for sysroot...
> checking for toolchain path...
> checking for extra path...
> checking where to store configuration... in default location
> checking what configuration name to use...
> linux-x86_64-normal-server-fastdebug
> checking for apt-get... apt-get
> checking for gmake... no
> checking for make... /usr/bin/make
> configure: Testing potential make at /usr/bin/make, found using make in PATH
> configure: Using GNU make 3.81 (or later) at /usr/bin/make (version: GNU
> Make 4.1)
> checking if find supports -delete... yes
> checking for unzip... /usr/bin/unzip
> checking for zip... /usr/bin/zip
> checking for ldd... /usr/bin/ldd
> checking for readelf... /usr/bin/readelf
> checking for hg... /usr/bin/hg
> checking for stat... /usr/bin/stat
> checking for time... /usr/bin/time
> checking for pkg-config... /usr/bin/pkg-config
> checking pkg-config is at least version 0.9.0... yes
> checking for 7z... no
> checking for unzip... unzip
> checking for wget... wget
> checking headful support... include support for both headful and headless
> configure: Found potential Boot JDK using JAVA_HOME
> checking for Boot JDK... /home/yiji/jvm/jdk1.7.0_80
> checking Boot JDK version... java version "1.7.0_80" Java(TM) SE Runtime
> Environment (build 1.7.0_80-b15) Java HotSpot(TM) 64-Bit Server VM (build
> 24.80-b11, mixed mode)
> checking for java in Boot JDK... ok
> checking for javac in Boot JDK... ok
> checking for javah in Boot JDK... ok
> checking for javap in Boot JDK... ok
> checking for jar in Boot JDK... ok
> checking for rmic in Boot JDK... ok
> checking for native2ascii in Boot JDK... ok
> checking if Boot JDK is 32 or 64 bits... 64
> checking flags for boot jdk java command ...
> checking flags for boot jdk java command for big workloads...  -Xms64M
> -Xmx1600M -XX:ThreadStackSize=1536 -XX:PermSize=32m -XX:MaxPermSize=160m
> checking flags for boot jdk java command for small workloads...
> -XX:+UseSerialGC -Xms32M -Xmx512M
> configure: Using default toolchain gcc (GNU Compiler Collection)
> checking for gcc... /usr/bin/gcc
> checking resolved symbolic links for CC... /usr/bin/x86_64-linux-gnu-gcc-7
> 

Re: RFR: 8165440: Add zero support for x86_64-linux-gnux32 target

[John Paul Adrian Glaubitz]

You’re right, sorry. I haven’t been around OpenJDK for some weeks and forgot 
about posting to build-dev when posting.

I will push in around 2-3 hours, currently on a train.

Adrian

> On Sep 5, 2018, at 9:05 AM, Magnus Ihse Bursie 
>  wrote:
> 
>> On 2018-09-04 23:29, David Holmes wrote:
>> Hi Adrian, 
>> 
>> All changes that touch the build system must be reviewed by build-dev - now 
>> cc'd. 
> This has been discussed at some length in build-dev. But I agree, it's good 
> that also the actual RFR is cc:ed here.
> 
> The patch, unsurprisingly, LGTM.
> 
> /Magnus
> 
>> 
>> These changes seem reasonable, though I don't like adding changes in source 
>> code for such an obscure (and unsupported!) platform. 
>> 
>> David 
>> 
>>> On 5/09/2018 3:45 AM, John Paul Adrian Glaubitz wrote: 
>>> Hi! 
>>> 
>>> This rather small change adds build support for the x86_64-linux-gnux32 
>>> target. x32 is a variant of the x86_64 ABI with 64-bit registers and amd64 
>>> instruction set but 32-bit pointers [1]. 
>>> 
>>> One of the Linux distributions supporting x32 is Debian, see [2]. The 
>>> port is not official, but the large majority of packages build fine 
>>> and the toolchain is in good shape. Another distribution supporting 
>>> x32 is Gentoo. 
>>> 
>>> Please review the change in [3]. I have changed the original patch 
>>> a bit that Debian uses downstream to make the changes more consistent 
>>> and cleaner. 
>>> 
>>> Thanks, 
>>> Adrian 
>>> 
>>>> [1] https://en.wikipedia.org/wiki/X32_ABI 
>>>> [2] http://debian-x32.org/ 
>>>> [2] http://cr.openjdk.java.net/~glaubitz/8165440/webrev.00/ 
>>> 
> 

Re: [patch] add zero support for x86_64-linux-gnux32 target

[John Paul Adrian Glaubitz]

On 08/31/2018 01:40 PM, Magnus Ihse Bursie wrote:
> Yes, that looks reasonable! If you want to, you can push this + Klose's fix. 
Is there a bug in the JBS I can reference?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [patch] add zero support for x86_64-linux-gnux32 target

[John Paul Adrian Glaubitz]

Hi Magnus!

I just tested it and the following change in make/autoconf/flags.m4 is
necessary as well so that gcc is not called with "-m64":

diff -r 18afb2097ada -r 1f28530b1f46 make/autoconf/flags.m4
--- a/make/autoconf/flags.m4Fri Aug 31 11:43:06 2018 +0200
+++ b/make/autoconf/flags.m4Fri Aug 31 12:50:02 2018 +0200
@@ -241,7 +241,8 @@
   elif test "x$TOOLCHAIN_TYPE" = xsolstudio; then
 MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}"
   elif test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
-if test "x$OPENJDK_TARGET_CPU_ARCH" = xx86 ||
+if test "x$OPENJDK_TARGET_CPU_ARCH" = xx86 &&
+test "x$OPENJDK_TARGET_CPU" != xx32 ||
 test "x$OPENJDK_TARGET_CPU_ARCH" = xsparc ||
 test "x$OPENJDK_TARGET_CPU_ARCH" = xppc; then
   MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}"

Adrian

On 08/31/2018 10:43 AM, Magnus Ihse Bursie wrote:
> The necroposter strikes back! :-)
> 
> I'm currently trying to fix or close all long standing bugs on 
> infrastructure/build, and now the time has come to JDK-8165440.
> 
> This patch had a bit of bad timing when it was posted, since it could not be 
> accepted into mainline due to feature freeze, and there were no other repo to 
> accept it.
> 
> I adjusted the patch to the current code base (which means that most parts of 
> it were not needed). What remains are two files. However, I can't test if 
> this works. Matthias, can you verify that this is a working patch for jdk/jdk 
> for the gnux32 target? If so, I'll sponsor this patch.
> 
> diff --git a/make/autoconf/platform.m4 b/make/autoconf/platform.m4
> --- a/make/autoconf/platform.m4
> +++ b/make/autoconf/platform.m4
> @@ -35,6 +35,10 @@
>    VAR_CPU_ARCH=x86
>    VAR_CPU_BITS=64
>    VAR_CPU_ENDIAN=little
> +  case "$host" in *x32)
> +    VAR_CPU=x32
> +    VAR_CPU_BITS=32
> +  esac
>    ;;
>  i?86)
>    VAR_CPU=x86
> @@ -455,6 +459,8 @@
>  HOTSPOT_$1_CPU_DEFINE=IA32
>    elif test "x$OPENJDK_$1_CPU" = xx86_64; then
>  HOTSPOT_$1_CPU_DEFINE=AMD64
> +  elif test "x$OPENJDK_$1_CPU" = xx32; then
> +    HOTSPOT_$1_CPU_DEFINE=X32
>    elif test "x$OPENJDK_$1_CPU" = xsparcv9; then
>  HOTSPOT_$1_CPU_DEFINE=SPARC
>    elif test "x$OPENJDK_$1_CPU" = xaarch64; then
> diff --git a/src/hotspot/os/linux/os_linux.cpp 
> b/src/hotspot/os/linux/os_linux.cpp
> --- a/src/hotspot/os/linux/os_linux.cpp
> +++ b/src/hotspot/os/linux/os_linux.cpp
> @@ -1742,7 +1742,7 @@
> 
>  #if  (defined IA32)
>    static  Elf32_Half running_arch_code=EM_386;
> -#elif   (defined AMD64)
> +#elif   (defined AMD64) || defined(X32)
>    static  Elf32_Half running_arch_code=EM_X86_64;
>  #elif  (defined IA64)
>    static  Elf32_Half running_arch_code=EM_IA_64;
> 
> /Magnus
> 
> On 2016-09-06 01:01, David Holmes wrote:
>> Hi Severin, Matthias,
>>
>> On 5/09/2016 10:16 PM, Severin Gehwolf wrote:
>>> On Mon, 2016-09-05 at 14:03 +0200, Matthias Klose wrote:
>>>> The attached patch adds support for building zero for the x86_64-
>>>> linux-gnux32
>>>> target, having changes in the build system, hotspot and jdk.
>>>>
>>>>  - the build system currently only derives the target from
>>>>    the cpu in PLATFORM_EXTRACT_VARS_FROM_CPU; that is not enough
>>>>    for the new target, which only differs by the ending of the
>>>>    triplet. However the $host macro should be available anywhere.
>>>>
>>>>  - the hotspot part just handles the new "cpu"
>>>>
>>>>  - GensrcX11Wrappers.gmk assumes that there is a black/white
>>>>    decision about -m32/-m64. The patch works around it. However
>>>>    the real patch should be to get these flags from the build
>>>>    system, and not hardcode itself.
>>>>
>>>>  - the sysctl system call is unsupported in the x32 kernel, and
>>>>    just the include leads to a build error.  From my point of view
>>>>    the header is not needed. I had successful builds on all other
>>>>    targets without including it. If you want to keep the include,
>>>>    then it should be guarded with
>>>>    #if !(defined(_ILP32) && defined(__x86_64__))
>>>>
>>>> Matthias
>>>
>>> I've filed this bug for this:
>>> https://bugs.openjdk.java.net/browse/JDK-8165440
>>
>> Please note that as a P4 issue this can not be fixed given we have hit RDP1:
>>
>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html
>>
>> Further this is filed as "bug" but seems to clearly be an enhancement, so 
>> you would need approval for it to come in post-Feature-Complete.
>>
>> Please consider if this is something that must be fixed for 9 or can be 
>> deferred. Otherwise you will need to follow additional approval processes.
>>
>> Sorry.
>>
>> David (just the messenger!)
>>
>>> Unfortunately, I have no way of testing it.
>>>
>>> Cheers,
>>> Severin
>>>

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [patch] add zero support for x86_64-linux-gnux32 target

[John Paul Adrian Glaubitz]

On 08/31/2018 11:19 AM, Magnus Ihse Bursie wrote:
> Hah! That's exactly the same patch as I derived. :-)

Great.

> So that means, I assume, that the patch has been tested properly? If so I'll 
> just sponsor and push it.

(sid-x32-sbuild)root@epyc:/# file /usr/lib/jvm/java-11-openjdk-x32/bin/java
/usr/lib/jvm/java-11-openjdk-x32/bin/java: ELF 32-bit LSB executable, x86-64, 
version 1 (SYSV), dynamically linked, interpreter /libx32/ld-linux-x32.so.2, 
for GNU/Linux 3.4.0, BuildID[sha1]=feec974bc65365772119c032d534e49839f8df8f, 
stripped
(sid-x32-sbuild)root@epyc:/# /usr/lib/jvm/java-11-openjdk-x32/bin/java --version
openjdk 11 2018-09-25
OpenJDK Runtime Environment (build 11+27-Debian-1)
OpenJDK Zero VM (build 11+27-Debian-1, interpreted mode)
(sid-x32-sbuild)root@epyc:/#

Yes. Go ahead, please :-).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [patch] add zero support for x86_64-linux-gnux32 target

[John Paul Adrian Glaubitz]

On 08/31/2018 10:57 AM, John Paul Adrian Glaubitz wrote:
> On 08/31/2018 10:43 AM, Magnus Ihse Bursie wrote:
>> I adjusted the patch to the current code base (which means that most parts 
>> of it were not needed). What remains are two files. However, I can't test if 
>> this works. Matthias, can you verify that this is a working patch for 
>> jdk/jdk for the gnux32 target? If so, I'll sponsor this patch.
> I can test it. Didn't know that Matthias posted a patch for x32
> support. The current patch that the Debian openjdk-11 package
> is using at the moment can be found in [1].

Oh, and here's the build log of openjdk-11 in Debian with that
patch [1].

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=openjdk-11=x32=11%7E27-1=1534788109=0

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [patch] add zero support for x86_64-linux-gnux32 target

[John Paul Adrian Glaubitz]

On 08/31/2018 10:43 AM, Magnus Ihse Bursie wrote:
> I adjusted the patch to the current code base (which means that most parts of 
> it were not needed). What remains are two files. However, I can't test if 
> this works. Matthias, can you verify that this is a working patch for jdk/jdk 
> for the gnux32 target? If so, I'll sponsor this patch.
I can test it. Didn't know that Matthias posted a patch for x32
support. The current patch that the Debian openjdk-11 package
is using at the moment can be found in [1].

Adrian

> [1] 
> https://sources.debian.org/src/openjdk-11/11%7E27-1/debian/patches/zero-x32.diff/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR (S) 8208665: Amend cross-compilation docs with qemu-debootstrap recipe

[John Paul Adrian Glaubitz]

Hi Aleksey!

On 08/13/2018 12:26 PM, Aleksey Shipilev wrote:
> This is the recipe I have been using for creating artifacts on my personal CI 
> server [1], and it
> seems to work reliably starting from jdk11. It is partially applicable for 
> building jdk{8,9,10}, but
> freetype and friends still need to be pointed out explicitly there. 
> Nevertheless, this seems to be
> the most straightforward way to cross-compile to foreign architectures if 
> there are no devkit
> bundles available.

Thanks for this. This is actually a clever idea and should also work with
Debian Ports, i.e. the non-release architectures in Debian such as sparc64,
m68k and sh4.

For Debian Ports, there is only sid/unstable though and the FTP server is
a different one. Also, you need to include the package 
debian-ports-archive-keyring:

+  sudo qemu-debootstrap --arch=m68k --verbose \
+
--include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev,debian-ports-archive-keyring
\
+   --resolve-deps sid /chroots/m68k 
http://ftp.ports.debian.org/debian-ports/

I should give this a shot and if it works, it might be a good idea to add
the instructions for Debian Ports as well. Since I have some more patches
for m68k and co in the pipeline, I can actually test it for that ;-).

With current versions of qemu (either from git or Debian unstable), you should
even be able to build OpenJDK natively inside the emulated chroot. In Debian
Ports, we're heavily making use of qemu-user and qemu-system (for riscv64) to
build packages which hashelped finding and fixing tons of bugs in qemu (I have
alone reported countless bugs ;-)).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: JDK 8 Build Issue(s)

[John Paul Adrian Glaubitz]

On 07/22/2018 05:15 PM, mr rupplin wrote:
> Great.  I tried JDK 8 as base and it gave the generic linux error at build.
Whenever you build OpenJDK on any Linux distribution, you have to
install the build dependencies first. The easiest way to achieve
that on Debian or Debian derivatives, is to run the following command:

# apt update && apt build-dep openjdk-8

For OpenJDK 9, 10 and 11, use:

# apt update && apt build-dep openjdk-9
# apt update && apt build-dep openjdk-10
# apt update && apt build-dep openjdk-11

FWIW, OpenJDK 9 has already been dropped from Debian unstable. Don't
know about the various derivatives though.

Don't forget to configure with "--disable-warnings-as-error" and the
proper part to the build JDK

"--with-build-jdk=/usr/lib/jvm/java-8-openjdk-amd64/"

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8205616: Build fails with system headers after 8204572

[John Paul Adrian Glaubitz]

Oops, I missed your reply. Will commit now.

Submit repo also passed without problems.

Adrian

On 06/26/2018 04:51 PM, Erik Joelsson wrote:
> Correct.
> 
> /Erik
> 
> 
> On 2018-06-26 07:35, John Paul Adrian Glaubitz wrote:
>> Hi Erik!
>>
>> Thanks!
>>
>> I assume since this affects the build infrastructure only, one reviewer
>> is enough, correct?
>>
>> Adrian
>>
>> On 06/26/2018 04:33 PM, Erik Joelsson wrote:
>>> Looks good.
>>>
>>> /Erik
>>>
>>>
>>> On 2018-06-25 17:21, John Paul Adrian Glaubitz wrote:
>>>> Hi!
>>>>
>>>> Please review this small change contributed by Fridrich Strba of SUSE
>>>> and modified by Magnus which fixes the OpenJDK build when configuring
>>>> to use system headers for libraries like jpeg and lcms.
>>>>
>>>> The bug report can be found in [1] and the webrev in [2].
>>>>
>>>> Thanks,
>>>> Adrian
>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8205616
>>>>> [2] http://cr.openjdk.java.net/~glaubitz/8205616/webrev.00/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8205616: Build fails with system headers after 8204572

[John Paul Adrian Glaubitz]

Hi Erik!

Thanks!

I assume since this affects the build infrastructure only, one reviewer
is enough, correct?

Adrian

On 06/26/2018 04:33 PM, Erik Joelsson wrote:
> Looks good.
> 
> /Erik
> 
> 
> On 2018-06-25 17:21, John Paul Adrian Glaubitz wrote:
>> Hi!
>>
>> Please review this small change contributed by Fridrich Strba of SUSE
>> and modified by Magnus which fixes the OpenJDK build when configuring
>> to use system headers for libraries like jpeg and lcms.
>>
>> The bug report can be found in [1] and the webrev in [2].
>>
>> Thanks,
>> Adrian
>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8205616
>>> [2] http://cr.openjdk.java.net/~glaubitz/8205616/webrev.00/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

RFR: 8205616: Build fails with system headers after 8204572

[John Paul Adrian Glaubitz]

Hi!

Please review this small change contributed by Fridrich Strba of SUSE
and modified by Magnus which fixes the OpenJDK build when configuring
to use system headers for libraries like jpeg and lcms.

The bug report can be found in [1] and the webrev in [2].

Thanks,
Adrian

> [1] https://bugs.openjdk.java.net/browse/JDK-8205616
> [2] http://cr.openjdk.java.net/~glaubitz/8205616/webrev.00/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Python issues with defpath and jcheck

[John Paul Adrian Glaubitz]

Hi Erik!

On 06/25/2018 08:38 PM, Erik Joelsson wrote:
> I have a patch on review for fixing trees to work with Mercurial 4.6:
> 
> http://mail.openjdk.java.net/pipermail/hg-tools-dev/2018-June/000236.html
> 
> It looks like the defpath plugin is suffering similar problems. If you want 
> to fix your local copy, Mercurial moved the method util.Abort to error.Abort.
Indeed. For defpath, it's enough to add "error" to the list of imports
from mercurial.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Python issues with defpath and jcheck

[John Paul Adrian Glaubitz]

Hi!

I have tried to submit a patch to the submit repository today and was
presented with a Python backtrace. I have already updated both "defpath"
and "jcheck" to their latest version from Mercurual (trace below).

Has anyone else seen this?

glaubitz@z6:..incoming/submit> hg defpath -du glaubitz
** Unknown exception encountered with possibly-broken third-party extension 
jcheck
** which supports versions unknown of Mercurial.
** Please disable jcheck and try your action again.
** If that fixes the bug please report it to the extension author.
** Python 2.7.15 (default, May  1 2018, 05:55:50) [GCC 7.3.0]
** Mercurial Distributed SCM (version 4.6.1)
** Extensions loaded: strip, mq, histedit, purge, jcheck, defpath
Traceback (most recent call last):
  File "/usr/bin/hg", line 41, in 
dispatch.run()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 90, in run
status = (dispatch(req) or 0)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 210, in 
dispatch
ret = _runcatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 351, in 
_runcatch
return _callcatch(ui, _runcatchfunc)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 359, in 
_callcatch
return scmutil.callcatch(ui, func)
  File "/usr/lib/python2.7/dist-packages/mercurial/scmutil.py", line 160, in 
callcatch
return func()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 341, in 
_runcatchfunc
return _dispatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 971, in 
_dispatch
cmdpats, cmdoptions)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 727, in 
runcommand
ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 979, in 
_runcommand
return cmdfunc()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 968, in 

d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1555, in check
return func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1555, in check
return func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/hgext/mq.py", line 3599, in mqcommand
return orig(ui, repo, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1555, in check
return func(*args, **kwargs)
  File "/home/glaubitz/upstream/defpath/defpath.py", line 352, in cmd_defpath
return defpath(ui, repo, peer, peer_push, walk_self, opts)
  File "/home/glaubitz/upstream/defpath/defpath.py", line 287, in defpath
except util.Abort, x:
AttributeError: 'module' object has no attribute 'Abort'
glaubitz@z6:..incoming/submit>

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

[John Paul Adrian Glaubitz]

On 06/25/2018 04:35 PM, John Paul Adrian Glaubitz wrote:
>> Adrian, any update on this? Is there a bug open? We need this fix for
>> our future JDK 11 packages.
> 
> Sorry, I was traveling over the weekend. I should be able to do it later
> today.

Bug report is:

> https://bugs.openjdk.java.net/browse/JDK-8205616

Webrev coming.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

[John Paul Adrian Glaubitz]

Hi Severin!

On 06/25/2018 04:12 PM, Severin Gehwolf wrote:
>>> I'd propose:
>>>
>>> Contributed-by: Magnuse Ihse Bursie , 
>>> Fridrich Strba 
>>
>> Perfect, thank you!
> 
> Adrian, any update on this? Is there a bug open? We need this fix for
> our future JDK 11 packages.

Sorry, I was traveling over the weekend. I should be able to do it later
today.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

[John Paul Adrian Glaubitz]

Hi Severin!

On 06/22/2018 01:19 PM, Severin Gehwolf wrote:
>> Now, before I create the bug report, do you happen to know which changeset
>> introduced the regression? We usually include that in the bug report.
> 
> http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855
> 
>> And I also need to know whom to credit for the patch because of the several
>> backs and forths, I lost the overview.
> 
> I'd propose:
> 
> Contributed-by: Magnuse Ihse Bursie , Fridrich 
> Strba 

Perfect, thank you!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

[John Paul Adrian Glaubitz]

Hi Fridrich!

On 06/21/2018 02:34 PM, Fridrich Strba wrote:
> Yes, I have tested this consolidated version and it builds just fine for me.
I have just verified that the problem exists on Debian unstable as well when
using the system headers for libjpeg and the other libraries. I can also
confirm that the patch you provided fixes the problem for me.

Now, before I create the bug report, do you happen to know which changeset
introduced the regression? We usually include that in the bug report.

And I also need to know whom to credit for the patch because of the several
backs and forths, I lost the overview.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

[John Paul Adrian Glaubitz]

Hi Fridrich!

Is this still an issue? Shall I open a bug report in JBS?

Adrian

On 06/15/2018 06:02 PM, Fridrich Strba wrote:
> Hello, Magnus,
> 
> Your original patch had a problem, since the second statement overwrote
> the $1_SRC_HEADER_FLAGS instead of appending to it. With that, things
> like osSupport.hpp, jawt_md.h and so on could not be found in build of
> tests. So, I modified your patch to read as attached and the build
> finished. It is basically a 2-liner.
> 
> Cheers
> 
> Fridrich
> 
> On 15/06/18 13:10, Magnus Ihse Bursie wrote:
>> Here's a better patch. Please try and see if it solves your problems.
>> Unfortunately, I'm leaving on vacation for today and will be gone most
>> of the summer, so I can't help sponsor this patch. But if it works, I'm
>> sure someone else can take over it.
>>
>> If it does not work, the original patch should at the very least be
>> changed so that EXTRA_HEADER_DIRS gets an additional "$(call
>> GetJavaHeaderDir, $(MODULE))", instead of the -I (which I've been trying
>> hard to eradicate from the CFLAGS).

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: JDK Build on Fedora 28

[John Paul Adrian Glaubitz]

Hi Patrick!

Try building with “—disable-warnings-as-errors”, that should fix the problem.

Adrian

PS: Replying from mobile, excuse my brevity.

> On Jun 18, 2018, at 9:36 PM, Patrick Reinhart  wrote:
> 
> Hi everybody,
> 
> Can anyone give me some advice in what I should do in order to build the 
> OpenJDK on a Fedora 28?
> 
> 
> -Patrick
> 
> 
> At the moment I get those errors:
> 
> Compiling 5 files for jdk.internal.vm.compiler.management
> /home/pr/sources/jdk/src/hotspot/os/posix/os_posix.cpp: In static member 
> function ‘static int os::create_file_for_heap(const char*)’:
> /home/pr/sources/jdk/src/hotspot/os/posix/os_posix.cpp:172:16: error: ‘char* 
> strncpy(char*, const char*, size_t)’ specified bound depends on the length of 
> the source argument [-Werror=stringop-overflow=]
>   (void)strncpy(fullname, dir, strlen(dir)+1);
> ~~~^~
> /home/pr/sources/jdk/src/hotspot/os/posix/os_posix.cpp:172:38: note: length 
> computed here
>   (void)strncpy(fullname, dir, strlen(dir)+1);
>~~^
> /home/pr/sources/jdk/src/hotspot/os/posix/os_posix.cpp:173:16: error: ‘char* 
> strncat(char*, const char*, size_t)’ specified bound depends on the length of 
> the source argument [-Werror=stringop-overflow=]
>   (void)strncat(fullname, name_template, strlen(name_template));
> ~~~^~~~
> cc1plus: all warnings being treated as errors
> gmake[3]: *** [lib/CompileJvm.gmk:151: 
> /home/pr/sources/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/os_posix.o]
>  Error 1
> gmake[3]: *** Waiting for unfinished jobs
> gmake[2]: *** [make/Main.gmk:257: hotspot-server-libs] Error 2
> 
> ERROR: Build failed for target 'default (exploded-image)' in configuration 
> 'linux-x86_64-normal-server-release' (exit code 2)
> Stopping sjavac server

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

[John Paul Adrian Glaubitz]

On 06/15/2018 01:10 PM, Magnus Ihse Bursie wrote:
> I think I understand the underlying issue but I'm not sure how to try 
> reproduce a build problem from it.

I have an openSUSE box here, so I should be able to reproduce it :).

> Here's a better patch. Please try and see if it solves your problems. 
> Unfortunately, I'm leaving on vacation for today and will be gone most of the 
> summer, so I can't help sponsor this patch. But if it works, I'm sure someone 
> else can take over it.

Don't worry. I will help Fridrich to sort this issue out.

> If it does not work, the original patch should at the very least be changed 
> so that EXTRA_HEADER_DIRS gets an additional "$(call GetJavaHeaderDir, 
> $(MODULE))", instead of the -I (which I've been trying hard to eradicate from 
> the CFLAGS).
Thanks for the heads-up! I will test your patch in any case.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

[John Paul Adrian Glaubitz]

Hi Fridrich!

I can help you getting this issue fixed. If I remember correctly, you said
that SUSE has signed Oracle's OCA, so I it should be fine if I submit the
patch with you as the author.

Let me have a look at the problem first though.

Adrian

On 06/15/2018 10:27 AM, Severin Gehwolf wrote:
> Just for the completeness, this is a normal openSUSE package build with
> --with-system-jpeg and --with-system-lcms. Maybe the
> LIBJPEG_HEADERS_FROM_SRC := false is culprit. Some other people were
> able to build jdk-11+18 with bundled jpeg and lcms without problems.
> 
> Cheers
> 
> Fridrich
> 
> On 15/06/18 09:31, Fridrich Strba wrote:
>> Hello, good people,
>>
>> Since I cannot submit anything to bugzilla, I spam this list with this
>> patch that I needed to be able to build jdk-11+18.
>>
>> I saw that http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855 changed
>> the way the headers are included, but in my analysis, the generated
>> headers in $(SUPPORT_OUTPUTDIR)/headers/java.desktop were not added by
>> the new way of doing. The patch makes it build for me. Do what you want
>> with it :)
>>
>> Fridrich
>>
> 

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)

[John Paul Adrian Glaubitz]

On 05/24/2018 03:01 PM, David Holmes wrote:
>> I'm not building Zero in this case but Hotspot native for linux-sparc.
> 
> Are you building an interpreter only version of linux-sparc?

No, I don't think so:

MAKE_VERBOSE=y QUIETLY= LOG=debug sh ./configure --with-jvm-variants=server
 
--with-boot-jdk=/usr/lib/jvm/java-10-openjdk-sparc64
 --disable-precompiled-headers
 --with-debug-level=release
 --disable-warnings-as-errors
 --disable-javac-server
 --with-num-cores=16

> This barrier code seems highly suspect to me with regards to how it tries to 
> deal with C1 versus C2. I suspect at least one must be present.
> 
> But if this is not Minimal nor Zero then it needs another bug filed :)

Already done: https://bugs.openjdk.java.net/browse/JDK-8203787

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)

[John Paul Adrian Glaubitz]

On 05/24/2018 02:57 PM, Aleksey Shipilev wrote:
> Oh. I am just confused you are replying to the stale review thread for 
> "Minimal, Zero builds fail
> after JDK-8202377 (Modularize C2 barriers)". What you are seeing is something 
> else.

As I said, "hg blame" indicates the change which probably broke linux-sparc
here is 8202377, most likely because it was assumed SPARC needs to work
on Solaris only -.-.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)

[John Paul Adrian Glaubitz]

On 05/24/2018 02:53 PM, Aleksey Shipilev wrote:
> Yeah, but this issue dealt with:
> 
> /pool/buildbot/slaves/sobornost/jdkX/build/src/hotspot/share/opto/optoreg.hpp:32:39:
>  fatal error:
> adfiles/adGlobals_x86.hpp: No such file or directory
>  #include CPU_HEADER(adfiles/adGlobals)
> 
> Let's not conflate the two. What you are seeing seems to be specific to Zero, 
> and not to Minimal.

I'm not building Zero in this case but Hotspot native for linux-sparc.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)

[John Paul Adrian Glaubitz]

On 05/24/2018 02:42 PM, Aleksey Shipilev wrote:
>> Does SPARC have support for C2 on Solaris so that we need to
>> add it for linux-sparc as well or is this limited to x86_64 only?
> 
> You must be seeing something new, because the fix for Minimal and Zero was 
> pushed to jdk/jdk
> already. Submit a bug report?

I am seeing the same problem as yesterday (or was it the day before yesterday?),
after running "hg pull && hg update --clean" today. And "hg blame" showed me
the regression came through JDK-8202377.

The error remains the same:

=== Output from failing command(s) repeated here ===
/usr/bin/printf "* For target 
hotspot_variant-server_libjvm_objs_library_call.o:\n"
* For target hotspot_variant-server_libjvm_objs_library_call.o:
(/bin/grep -v -e "^Note: including file:" <  
/srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_library_call.o.log
 || true) | /usr/bin/head -n 12
/srv/openjdk/jdk/src/hotspot/share/opto/library_call.cpp: In member function 
‘bool LibraryCallKit::inline_native_clone(bool)’:
/srv/openjdk/jdk/src/hotspot/share/opto/library_call.cpp:4272:38: error: 
incomplete type ‘BarrierSet’ used in nested name specifier
   BarrierSetC2* bs = BarrierSet::barrier_set()->barrier_set_c2();
  ^~~
if test `/usr/bin/wc -l < 
/srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_library_call.o.log`
 -gt 12; then /bin/echo "   ... (rest of output omitted)" ; fi
/usr/bin/printf "\n* All command lines available in 
/srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs.\n"

* All command lines available in 
/srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs.
/usr/bin/printf "=== End of repeated output ===\n"
=== End of repeated output ===

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)

[John Paul Adrian Glaubitz]

Hi!

On 05/19/2018 11:20 AM, Aleksey Shipilev wrote:
> Other GCs that would eventually bring their own BarrierSetC2 files (e.g. 
> Epsilon, Shenandoah, ZGC)
> would require excluding their "gc//c2" as well.

I'm seeing this bug on linux-sparc as well.

Does SPARC have support for C2 on Solaris so that we need to
add it for linux-sparc as well or is this limited to x86_64 only?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR(xxs): 8202822: Add .git to .hgignore

[John Paul Adrian Glaubitz]

Shouldn't we also add .hg to .gitignore? :-)

On 05/09/2018 05:52 PM, Erik Joelsson wrote:

Looks good to me.

/Erik


On 2018-05-08 21:59, Thomas Stüfe wrote:

Hi all,

could we add .git to .hgignore?

Bug: https://bugs.openjdk.java.net/browse/JDK-8202822

Diff:

--- a/.hgignore Wed May 09 06:51:41 2018 +0200
+++ b/.hgignore Wed May 09 06:55:10 2018 +0200
@@ -13,3 +13,4 @@
  NashornProfile.txt
  .*/JTreport/.*
  .*/JTwork/.*
+.*/.git/.*

Thanks!

Thomas


--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: strange configure error on Linux Mint 18.3

[John Paul Adrian Glaubitz]

On 04/24/2018 06:24 PM, Thomas Stüfe wrote:
> Thanks Adrian!
> 
> I installed the build prereqs and now I am fine.

Great. I'm glad I was able to help :).

> Wiki is good, btw.

I have written down instructions for bootstrapping various compilers
in Debian since that happens every time we are adding a new architecture:

> https://wiki.debian.org/PortsDocs/BootstrappingFPC
> https://wiki.debian.org/PortsDocs/BootstrappingGHC
> https://wiki.debian.org/PortsDocs/BootstrappingOpenJDK
> https://wiki.debian.org/PortsDocs/BootstrappingRust

The instructions aren't necessary complete or up-to-date, but they
should give good pointers.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: strange configure error on Linux Mint 18.3

[John Paul Adrian Glaubitz]

On 04/24/2018 03:25 PM, Thomas Stüfe wrote:

Have you tried "apt build-dep openjdk-9"? This should install all the
necessary build dependencies.


This is cool! I did not know that.

Unfortunately it seems not to work on my box:

thomas@mint18 /shared/projects/openjdk/jdk-jdk/source $ sudo apt-get
build-dep openjdk-9
Reading package lists... Done
E: You must put some 'source' URIs in your sources.list


You need to add the corresponding "deb-src" entries for the "deb"
entries in your /etc/apt/sources.list.

On my Debian box, it looks like this:

deb http://ftp.de.debian.org/debian unstable main contrib non-free
deb-src http://ftp.de.debian.org/debian unstable main contrib non-free

For Linux Mint, you need to use the corresponding line from the
Linux Mint mirrors. After editing the sources.list, you need to
run "apt update".


:) Sure. As I wrote, I think the bug would be that configure does not
display nice "you should run apt-get x" messages like it used to.


PS: If you are using a real Debian instead of Linux Mint, you get a
 free Multi-Arch environment for free and can easily cross-build
 OpenJDK for all the architectures found in Debian. Let me know
 if you want me to write up a small HowTo.



Such a braindump from you would be surely welcome.


I just realized I already did that:


https://wiki.debian.org/PortsDocs/BootstrappingOpenJDK


Needs some updating though.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: strange configure error on Linux Mint 18.3

[John Paul Adrian Glaubitz]

Hi Thomas!

On 04/24/2018 02:50 PM, Thomas Stüfe wrote:

I got a configure error on a fresh, virgin Linux Mint 18.3 install. I
have not yet installed anything on that box (the only thing I
installed is autoconf).


Have you tried "apt build-dep openjdk-9"? This should install all the
necessary build dependencies.


This fails at a point where normally I would get suggestions about
which tools to install with apt-get (which, btw, is really nice).
config.log contains this:
(...)
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find crtn.o: No such file or directory


You're missing the Debian package libc6-dev:

root@z6:~> dpkg -L libc6-dev |grep crt
/usr/lib/x86_64-linux-gnu/Mcrt1.o
/usr/lib/x86_64-linux-gnu/Scrt1.o
/usr/lib/x86_64-linux-gnu/crt1.o
/usr/lib/x86_64-linux-gnu/crti.o
/usr/lib/x86_64-linux-gnu/crtn.o
/usr/lib/x86_64-linux-gnu/gcrt1.o
/usr/lib/x86_64-linux-gnu/grcrt1.o
/usr/lib/x86_64-linux-gnu/rcrt1.o
root@z6:~>


Weirdly enough the compiler is ran once with -qversion, which is an
AIX-only option, and once with -V, which is not valid either.


This is perfectly normal and the way autoconf works. It tries various
compiler options and runs various tests, including test compiles,
and checks the result. autoconf cannot know in advance what toolchain
and which operating system you are using, so it has to perform these
tests. The error messages are normally just redirected to /dev/null
and only show in config.log.


Has anyone seen this already? (Note that I used Mint18.3 as
development machine before and it just worked).


Yes, it's perfectly normal when you try to configure OpenJDK without
any of its build dependencies installed :).

PS: If you are using a real Debian instead of Linux Mint, you get a
free Multi-Arch environment for free and can easily cross-build
OpenJDK for all the architectures found in Debian. Let me know
if you want me to write up a small HowTo.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8201360: Zero fails to build on linux-sparc after 8201236

[John Paul Adrian Glaubitz]

Hi Magnus!

On 04/10/2018 10:01 PM, Magnus Ihse Bursie wrote:
> The regression you noted was not caused by JDK-8201236, but by JDK-8198862 
> "Stop doing funky compilation stuff for dtrace". In fact, JDK-8201236 (which 
> is
> pushed to jdk/jdk but not yet integrated into jdk/hs, apparently) will once 
> again remove EXTRA_FILES from the SetupNativeCompilation, making zero work 
> again.
> 
> So if you just wait until JDK-8201236 moves into jdk/hs, this will be fixed. 
> Otherwise, you're just creating a merge conflict for the integrator. :(

Since the jdk/jdk and jdk/hs merge was finished today, I gave Zero on 
linux-sparc
another shot and lo and behold, it builds fine again :-).

Will update the bug report accordingly.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Invalid use of -m32 on certain targets

[John Paul Adrian Glaubitz]

Hi Severin!

On 04/13/2018 02:16 PM, Severin Gehwolf wrote:

Is there a bug for this already?


Here is one:
https://bugs.openjdk.java.net/browse/JDK-8201536

Great, thank you. I couldn't reply earlier as I was just on my way.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Invalid use of -m32 on certain targets

[John Paul Adrian Glaubitz]

Hi!

I have been playing around with Zero on new (old) architectures and one
of them is hppa, which needs some additional work due to its stack growing
from bottom to top but that's another story.

Anyway, adding hppa to platform.m4 and running configure results in the
following error message:

configure:35290: checking whether the C compiler works
configure:35312: /usr/bin/hppa-linux-gnu-gcc -m32-m32   conftest.c  >&5
hppa-linux-gnu-gcc: error: unrecognized command line option '-m32'
hppa-linux-gnu-gcc: error: unrecognized command line option '-m32'
configure:35316: $? = 1
configure:35354: result: no
configure: failed program was:

Didn't we recently have the discussion about which target gcc versions
understand "-m32" and which don't? Apparently, someone thought hppa's
gcc supports that option but apparently it doesn't.

Was there any conclusion on this discussion? I remember that some
people mentioned that the current situation is not ideal.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8201360: Zero fails to build on linux-sparc after 8201236

[John Paul Adrian Glaubitz]

Hi Magnus!

On 04/10/2018 10:01 PM, Magnus Ihse Bursie wrote:

The regression you noted was not caused by JDK-8201236, but by JDK-8198862 "Stop 
doing funky compilation stuff for dtrace". In fact, JDK-8201236 (which is pushed to 
jdk/jdk but not yet integrated into jdk/hs, apparently) will once again remove 
EXTRA_FILES from the SetupNativeCompilation, making zero work again.


Ok, so I will update the bug report title accordingly.


So if you just wait until JDK-8201236 moves into jdk/hs, this will be fixed. 
Otherwise, you're just creating a merge conflict for the integrator. :(


Ah, even better. I don't mind waiting then and in the meantime continue
investigating on the other SPARC stuff.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8201360: Zero fails to build on linux-sparc after 8201236

[John Paul Adrian Glaubitz]

On 04/10/2018 08:51 PM, Gary Adams wrote:

Is any update needed for EXTRA_OBJECT_FILES?


No. I just made the single change Erik suggested and it builds fine for me.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

RFR: 8201360: Zero fails to build on linux-sparc after 8201236

[John Paul Adrian Glaubitz]

Hi!

Please review this minor change which fixes the Zero build on linux-sparc
which got broken after "JDK-8201236 Straighten out dtrace build logic".

The change affects the Zero build on linux-sparc only since SPARC has its
own implementation of memset_with_concurrent_readers() in memset_with_\
concurrent_readers_sparc.cpp which needs to be added to $(EXTRA_FILES)
by adding $(BUILD_LIBJVM_EXTRA_FILES) to $(EXTRA_FILES).

Thanks,
Adrian


[1] http://cr.openjdk.java.net/~glaubitz/8201360/webrev.00/


--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Zero fails to build on SPARC again, similar to JDK-8186578

[John Paul Adrian Glaubitz]

On 04/10/2018 08:04 PM, Erik Joelsson wrote:

"JDK-8201236 Straighten out dtrace build logic"


Aye, changeset is coming up ;).


Indeed, this fixes it! Thanks so much, I was already about to give up ;).


We should have been explicit with that parameter in the first place, then 
Magnus would not have missed it. Glad I could help.


After that, I'll try to tackle the server build on linux-sparc again.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Zero fails to build on SPARC again, similar to JDK-8186578

[John Paul Adrian Glaubitz]

Hi Erik!

On 04/10/2018 06:54 PM, Erik Joelsson wrote:

I've found the problem. In JvmFeatures.gmk we have:

ifeq ($(call check-jvm-feature, zero), true)
   JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP 
-DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
   JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
   ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
     BUILD_LIBJVM_EXTRA_FILES := 
$(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
   endif
endif

The BUILD_LIBJVM_EXTRA_FILES is implicitly trying to set the EXTRA_FILES 
argument to the BUILD_LIBJVM SetupNativeCompilation call. This used to work 
because there was no setting of that parameter in the actual call. In a recent 
change, that parameter is not set to something else, overriding the assignment 
above.


Aha! Do you happen to know which change was responsible for that? Then I can
adjust the bug summary accordingly.


To fix this, you need to add $(BUILD_LIBJVM_EXTRA_FILES) to the EXTRA_FILES 
line in CompileJvm.gmk.


Indeed, this fixes it! Thanks so much, I was already about to give up ;).

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Zero fails to build on SPARC again, similar to JDK-8186578

[John Paul Adrian Glaubitz]

   ... (rest of output omitted)" ; fi
/usr/bin/printf "* For target jdk_modules_java.base__the.java.base_batch:\n"
* For target jdk_modules_java.base__the.java.base_batch:
(/bin/grep -v -e "^Note: including file:" <  
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.log
 || true) | /usr/bin/head -n 12
if test `/usr/bin/wc -l < 
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.log`
 -gt 12; then /bin/echo "   ... (rest of output omitted)" ; fi
/usr/bin/printf "\n* All command lines available in 
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs.\n"

* All command lines available in 
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs.
/usr/bin/printf "=== End of repeated output ===\n"
=== End of repeated output ===

Any ideas?

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Execution problems with Atomic Operations on OpenJDK10 for ARM5 Soft Float

[John Paul Adrian Glaubitz]

CC'ing hotspot-dev

On 04/04/2018 12:29 PM, b...@juanantonio.info wrote:
> I think that in OpenJDK10 changed something in compare to OpenJDK9 in 
> relation to ARM5 support.

It was OpenJDK9 which dropped support for ARM CPUs prior ARMv7. If you are
using ARMv5, you have to resort to OpenJDK Zero, i.e. the unoptimized, generic
implementation of the JVM.

As for the atomic operation, I'm not sure whether Zero supports this particular
atomic operation. I will have to dig into the code myself.

Would it be possible that you provide sample code that helps reproduce the 
problem?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c

[John Paul Adrian Glaubitz]

On 03/27/2018 06:42 PM, Magnus Ihse Bursie wrote:
> * Linux and macosx used a uint32_t/uint64_t instead of sigset_t for jvmsigs, 
> as aix and solaris do. This is a less robust solution, and the added checks 
> show
> that it has failed in the past. Now all platforms use sigset_t/sigismember().

Ah, this is great. I guess Debian can then drop this patch we have for the MIPS
targets [1, 2]. This patch is necessary because MIPS has 128 signals and 
uint64_t
is not enough for that.

I will test whether your change makes this particular Debian patch obsolete.

Adrian

> [1] 
> https://sources.debian.org/src/openjdk-11/11%7E5-1/debian/patches/mips-sigset.diff/
> [2] 
> https://sources.debian.org/src/openjdk-9/9.0.4+12-3/debian/patches/mips-sigset.diff/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8199138: Add RISC-V support to Zero

[John Paul Adrian Glaubitz]

On 03/27/2018 05:23 PM, Edward Nevill wrote:
> Sorry for the delay. I was doing another test build on qemu which takes about 
> 3 days.
> 
> Please review the following webrev
> 
> http://cr.openjdk.java.net/~enevill/8199138/webrev.02
> 
> This has the following additional changes over the previous webrev
> 
> 1) Add comment in os_linux.cpp
> 
> @@ -1733,6 +1733,9 @@
>  #ifndef EM_AARCH64
>#define EM_AARCH64183   /* ARM AARCH64 */
>  #endif
> +#ifndef EM_RISCV  /* RISCV */
> +  #define EM_RISCV  243
> +#endif

What confuses me: Why RISCV here and not RISCV64?

In particular this hunk:

@@ -1758,6 +1761,7 @@
 {EM_PARISC,  EM_PARISC,  ELFCLASS32, ELFDATA2MSB, (char*)"PARISC"},
 {EM_68K, EM_68K, ELFCLASS32, ELFDATA2MSB, (char*)"M68k"},
 {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, (char*)"AARCH64"},
+{EM_RISCV,   EM_RISCV,   ELFCLASS64, ELFDATA2LSB, (char*)"RISCV"},
   };

I know there is already 32-bit RISC-V and there are actually plans for
using it. So, it looks to me you would be breaking 32-bit RISC-V here.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8199138: Add RISC-V support to Zero

[John Paul Adrian Glaubitz]

On 03/24/2018 02:26 AM, Magnus Ihse Bursie wrote:
> 
> On 2018-03-20 14:54, Edward Nevill wrote:
>> Thanks for this. I have updated the webrev with the above comment.
>>
>> http://cr.openjdk.java.net/~enevill/8199138/webrev.01
> I note that in platform.m4 (sorry I didn't say this earlier), you set the 
> CPU_ARCH to riscv64 as well, and not just riscv. Now I don't know how likely 
> it is
> that OpenJDK will ever support the 32-bit version of riscv, but it seems like 
> it would make more sense to define the CPU_ARCH as "riscv", and the CPU as 
> "riscv64".
> 
> It's just a minor thing, if you like it the way it is, keep it.

I agree, this is a bit odd.

@Edward: Is this correct as it currently is? Would be great if this changeset
could finally get merged as Debian just recently bootstrapped riscv64 and
is now building packages on real hardware with 10 build machines running:

> https://buildd.debian.org/status/architecture.php?a=riscv64=sid

I assume the build dependencies for OpenJDK in Debian will be built in around
a week or so. Until I then, we should have sorted this patch out so I can
add a (backported) patch to Debian's openjdk-8/9/10/11 packages.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8200203: Missing platform definitions for ia64

[John Paul Adrian Glaubitz]

On 03/26/2018 04:44 PM, Magnus Ihse Bursie wrote:
>> For the time being, it would be nice if I can get this and a second follow-up
>> change for ia64 merged so downstream (currently Debian and Gentoo for ia64)
>> doesn't have to carry any additional patches anymore.
> Your patch looks good to me.

Thank you. I just pushed it. I hope I did everything correctly being it
my second push on my own. Added Thomas and you as reviewers and ran
"hg jcheck" before pushing.

Still a bit nervous when pushing to master.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8200203: Missing platform definitions for ia64

[John Paul Adrian Glaubitz]

On 03/26/2018 08:08 AM, David Holmes wrote:
> Everytime I see these zero-only platform definitions it makes we think we 
> really
> should have these isolated into a zero-specific file. At the moment this can
> paint a false picture that all these platforms have full OpenJDK ports 
> available.

Is that really the case though? If someone is reading the platform.m4 file, they
might think that but simply trying to build the server variant for ia64 would
fail very quickly anyway and people would realize it's not supported.

In the end, I think the extended portability OpenJDK highly outweighs your
reservations above. Someone who doesn't understand the difference between Zero
and the official ports, is also unlikely to try building OpenJDK from source
themselves.

> I also wonder if the values here can be reliably obtained via uname/sysconf
> or some such utility so that we don't have to list every single platform
> individually?

I think autoconf normally has support for this, yes. It's rather unusual
having to add targets manually. But you will need the mapping to VAR_CPU,
for example. I will have a look at it anyway.

For the time being, it would be nice if I can get this and a second follow-up
change for ia64 merged so downstream (currently Debian and Gentoo for ia64)
doesn't have to carry any additional patches anymore.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

RFR: 8200203: Missing platform definitions for ia64

[John Paul Adrian Glaubitz]

Hi!

Please review this small change to the build system which adds the
platform definitions for ia64. This is one of two changes that is
necessary to get OpenJDK to build on ia64 (Zero variant).

Thanks,
Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8200203/webrev.01/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[John Paul Adrian Glaubitz]

On 03/24/2018 01:07 AM, Magnus Ihse Bursie wrote:
> But if javac developers are seriously hindered in their effort to enhance 
> Java due to this, then maybe developer convenience is not as important.

But is using the latest Java features really so important for OpenJDK
development? I mean, do people seriously say "Oh, we have type inference
for variables now. We have to use it immediately, it's making the code so
much better and faster!!!" (sorry, couldn't resist the hyperbole).

I mean, in the end, OpenJDK is developed for users and not for the OpenJDK
developers sake to use Java, isn't it? So, I think the project should always
keep users and downstream interests in mind.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [NEW BUG]: Configure broken on MIPS

[John Paul Adrian Glaubitz]

On Mar 23, 2018, at 7:04 PM, Ao Qi  wrote:

>>> 
>>> It might be some time still. I'm working on a complete overhaul of all
>>> CFLAGS and LDFLAGS, where this is a part of that picture, but I was not
>>> planning on addressing just this thing urgently.
>>> 
>>> So, I think this patch will do for now. It solves the immediate problem
>>> for MIPS, and I can come back and make a cleaner solution later on.
>> 
>> 
>> Isn't the best quick fix one that only adds -m64 for x86? I recall  a report
>> that arm32 is similarly broken.
> 
> I had a look at man gcc. It seems that at least -m64 is for S/390 and
> zSeries, SPARC , RS/6000 and PowerPC, and x86.

I hope you don’t break architectures like m68k which don’t support that flag.

Adrian