bug#50567: [core-updates-frozen] icedtea-6 fails to build.

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Guillaume Le Vaillant]

[-- Attachment #1.1: Type: text/plain, Size: 474 bytes --]

I'm trying to get icedtea-6 to build on the core-updates-frozen branch.
I fixed a few C/C++ related issues, but then I get this error:

--8<---------------cut here---------------start------------->8---
Preload failed: checksum of class list was incorrect.
make: *** [Makefile:2746: stamps/add-archive-ecj.stamp] Error 1
--8<---------------cut here---------------end--------------->8---

Does someone know how to solve that?

Here's the patch I'm using to get to this point:

[-- Attachment #1.2: 0001-WIP-gnu-icedtea-6-Fix-build.patch --]
[-- Type: text/x-patch, Size: 2022 bytes --]

From 6767793eccffea3bfddca5c4a0c0cff21abb965b Mon Sep 17 00:00:00 2001
From: Guillaume Le Vaillant <glv@posteo.net>
Date: Mon, 13 Sep 2021 14:37:40 +0200
Subject: [PATCH] WIP: gnu: icedtea-6: Fix build.

* gnu/packages/java.scm (icedtea-6)[arguments]: Add 'fix-openjdk' phase.
---
 gnu/packages/java.scm | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 51fc5c60a1..374a9d9cba 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -17,6 +17,7 @@
 ;;; Copyright © 2021 Vincent Legoll <vincent.legoll@gmail.com>
 ;;; Copyright © 2021 Mike Gerwitz <mtg@gnu.org>
 ;;; Copyright © 2021 Pierre Langlois <pierre.langlois@gmx.com>
+;;; Copyright © 2021 Guillaume Le Vaillant <glv@posteo.net>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -907,6 +908,19 @@ machine.")))
                             "patches/hotspot/hs23/drop_unlicensed_test.patch")
                (("#!/bin/sh") (string-append "#!" (which "sh"))))
              #t))
+         (add-after 'unpack 'fix-openjdk
+           (lambda _
+             (substitute* "openjdk/jdk/make/common/Defs-linux.gmk"
+               (("CFLAGS_COMMON  = -fno-strict-aliasing" all)
+                (string-append all " -fcommon")))
+             (substitute* "openjdk/hotspot/src/share/vm/code/relocInfo.hpp"
+               (("inline friend relocInfo prefix_relocInfo\\(int datalen = 0\\);")
+                "inline friend relocInfo prefix_relocInfo(int datalen);"))
+             (substitute*
+                 '("openjdk/jdk/src/solaris/native/java/net/PlainSocketImpl.c"
+                   "openjdk/jdk/src/solaris/native/java/net/PlainDatagramSocketImpl.c")
+               (("#include <sys/sysctl.h>")
+                "#include <linux/sysctl.h>"))))
          (add-after 'unpack 'patch-paths
            (lambda* (#:key inputs #:allow-other-keys)
              ;; buildtree.make generates shell scripts, so we need to replace
-- 
2.33.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

I had the same issue on my previous attempt. It seems that using gcc-7 as an input fixes the issue (although when I tried, I had other fixes like yours too). Our gcc on core-updates seems to be too aggressive with this old code base.

Le 13 septembre 2021 09:01:55 GMT-04:00, Guillaume Le Vaillant <glv@posteo.net> a écrit :
>I'm trying to get icedtea-6 to build on the core-updates-frozen branch.
>I fixed a few C/C++ related issues, but then I get this error:
>
>--8<---------------cut here---------------start------------->8---
>Preload failed: checksum of class list was incorrect.
>make: *** [Makefile:2746: stamps/add-archive-ecj.stamp] Error 1
>--8<---------------cut here---------------end--------------->8---
>
>Does someone know how to solve that?
>
>Here's the patch I'm using to get to this point:

[-- Attachment #2: Type: text/html, Size: 1108 bytes --]

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Ludovic Courtès]

Hi Guillaume,

Guillaume Le Vaillant <glv@posteo.net> skribis:

> I'm trying to get icedtea-6 to build on the core-updates-frozen branch.
> I fixed a few C/C++ related issues,

Thanks for fixing those!  After <https://issues.guix.gnu.org/49990#10>
Julien mentioned on IRC that using an older GCC allowed us to work
around those C++ issues, but your approach looks nicer to me.

> but then I get this error:
>
> Preload failed: checksum of class list was incorrect.
> make: *** [Makefile:2746: stamps/add-archive-ecj.stamp] Error 1

Woow, never seen that.  Julien, Ricardo, does that ring a bell?

Java is the main stumbling block on core-updates-frozen; making
progress!

Thanks,
Ludo’.

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

Again this is exactly where I was blocked. There is a checksum being generated in classlist files from java code during the build. The classlist file is exactly the same as the one in master, so it's correctly generated. Fowever, at some point, the process needs toqload that file, and that ultimately calls some C code (identical to the java code) that re-computes and compares the checksum. After printing some values, it seems that it always computes "0…031" as the hash of any classlist file, despite running the function and taking everything into account. I think this is again an optimization issue, anl it's not clear how to work around that.

Le 14 septembre 2021 04:44:18 GMT-04:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>Hi Guillaume,
>
>Guillaume Le Vaillant <glv@posteo.net> skribis:
>
>> I'm trying to get icedtea-6 to build on the core-updates-frozen branch.
>> I fixed a few C/C++ related issues,
>
>Thanks for fixing those!  After <https://issues.guix.gnu.org/49990#10>
>Julien mentioned on IRC that using an older GCC allowed us to work
>around those C++ issues, but your approach looks nicer to me.
>
>> but then I get this error:
>>
>> Preload failed: checksum of class list was incorrect.
>> make: *** [Makefile:2746: stamps/add-archive-ecj.stamp] Error 1
>
>Woow, never seen that.  Julien, Ricardo, does that ring a bell?
>
>Java is the main stumbling block on core-updates-frozen; making
>progress!
>
>Thanks,
>Ludo’.

[-- Attachment #2: Type: text/html, Size: 2078 bytes --]

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

Ludovic Courtès <ludo@gnu.org> skribis:

> Hi Guillaume,
>
> Guillaume Le Vaillant <glv@posteo.net> skribis:
>
>> I'm trying to get icedtea-6 to build on the core-updates-frozen branch.
>> I fixed a few C/C++ related issues,
>
> Thanks for fixing those!  After <https://issues.guix.gnu.org/49990#10>
> Julien mentioned on IRC that using an older GCC allowed us to work
> around those C++ issues, but your approach looks nicer to me.
>
>> but then I get this error:
>>
>> Preload failed: checksum of class list was incorrect.
>> make: *** [Makefile:2746: stamps/add-archive-ecj.stamp] Error 1
>
> Woow, never seen that.  Julien, Ricardo, does that ring a bell?
>
> Java is the main stumbling block on core-updates-frozen; making
> progress!
>
> Thanks,
> Ludo’.

It looks like the checksum failure is caused by the miscompilation of
a multiplication in the function computing the checksum.
I added a workaround to the other fixes in
f8cff361245cc0c546211ff51100cbaf869d15eb, which makes the build succeed.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

Sorry for the possible confusion. These replies stacked up in my client and I didn't notice until they were sent just now. Please disregard :)

Le 14 septembre 2021 07:37:53 GMT-04:00, Julien Lepiller <julien@lepiller.eu> a écrit :
>Again this is exactly where I was blocked. There is a checksum being generated in classlist files from java code during the build. The classlist file is exactly the same as the one in master, so it's correctly generated. Fowever, at some point, the process needs toqload that file, and that ultimately calls some C code (identical to the java code) that re-computes and compares the checksum. After printing some values, it seems that it always computes "0…031" as the hash of any classlist file, despite running the function and taking everything into account. I think this is again an optimization issue, anl it's not clear how to work around that.
>
>Le 14 septembre 2021 04:44:18 GMT-04:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>>Hi Guillaume,
>>
>>Guillaume Le Vaillant <glv@posteo.net> skribis:
>>
>>> I'm trying to get icedtea-6 to build on the core-updates-frozen branch.
>>> I fixed a few C/C++ related issues,
>>
>>Thanks for fixing those!  After <https://issues.guix.gnu.org/49990#10>
>>Julien mentioned on IRC that using an older GCC allowed us to work
>>around those C++ issues, but your approach looks nicer to me.
>>
>>> but then I get this error:
>>>
>>> Preload failed: checksum of class list was incorrect.
>>> make: *** [Makefile:2746: stamps/add-archive-ecj.stamp] Error 1
>>
>>Woow, never seen that.  Julien, Ricardo, does that ring a bell?
>>
>>Java is the main stumbling block on core-updates-frozen; making
>>progress!
>>
>>Thanks,
>>Ludo’.

[-- Attachment #2: Type: text/html, Size: 2502 bytes --]

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

Julien Lepiller <julien@lepiller.eu> skriver:

> Again this is exactly where I was blocked. There is a checksum being generated in classlist files from java code during the build. The classlist file is exactly the same as the one in master, so it's correctly generated. Fowever, at some point, the process needs toqload that file, and that ultimately calls some C code (identical to the java code) that re-computes and compares the checksum. After printing some values, it seems that it always computes "0…031" as the hash of any classlist file, despite running the function and taking everything into account. I think this is again an optimization issue, anl it's not clear how to work around that.

For the record, this showed up again after switching to GCC 11.  I ended
up disabling optimizations for dump.cpp in 321e866b1cea4916e3568efb
instead of trying to fool the compiler.

Probably it would be better to figure out exactly which optimization
causes this problem, but that's a journey for a different time.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]