Re: Openjdk (was: Merging core-updates?)
Am Thu, Feb 16, 2023 at 12:38:23PM +0100 schrieb Julien Lepiller: > Upstream ensures openjdk N+1 can be built by openjdk N, but not necessarily > with N-1. We can try :) And fail :) configure: Potential Boot JDK found at /gnu/store/lqfppbbxhq503hfy2xf3djivqv3s8df4-openjdk-17.0.5-jdk is incorrect JDK version (openjdk version "17.0.5" 2022-10-18 OpenJDK Runtime Environment (build 17.0.5+0-adhoc..source) OpenJDK 64-Bit Server VM (build 17.0.5+0-adhoc..source, mixed mode, sharing)); ignoring configure: (Your Boot JDK version must be one of: 18 19) configure: Could not find a valid Boot JDK. OpenJDK distributions are available at http://jdk.java.net/. configure: This might be fixed by explicitly setting --with-boot-jdk configure: error: Cannot continue So @19 does not bootstrap with @17. Neither does @17 with @15. Dommage! Andreas
Re: Openjdk (was: Merging core-updates?)
Am Fri, Feb 17, 2023 at 05:27:02PM + schrieb Kaelyn: > I don't know much about openjdk or its development process, but I had one > possible thought about the pattern of patch application. Was it a patch that > was applied or backported to existing openjdk releases, and are @14 and @16 > the latest releases of those series? At least to me as a naive outside > observer, the patch being needed for some of the older release branches but > not others sounds like a patch applied to multiple existing release branches, > with openjdk@14 and @16 being at older point releases from prior to the patch > being applied upstream. Ah, right, this sounds like a good explanation, thanks, Kaelyn! I think we should consider core-updates frozen for the moment, but someone updating these intermediate openjdk versions in the future should pay attention to it. In the meantime, I have pushed a convoluted patch that adds and removes the patch by dancing back and forth. Andreas
Re: Openjdk (was: Merging core-updates?)
Hi, --- Original Message --- On Friday, February 17th, 2023 at 4:28 PM, Andreas Enge wrote: > Am Fri, Feb 17, 2023 at 03:49:19PM +0100 schrieb Andreas Enge: > > > Hm, I compiled up to openjdk@13, @14 fails with the message below. > > This is strange. It looks as if the patch that has become obsolete, > > because integrated into the source @13, is needed again @14! > > And then @15, the patch is again already integrated into the source code. > > Very weird! > > > Things become totally crazy. > So far I have compiled @13 without the patch, @14 with the patch, > @15 without the patch, and @16 seems to need it again. Is this an > odd/even thing? Are there spring and autumn versions of openjdk with > different release teams? Hi, I don't know much about openjdk or its development process, but I had one possible thought about the pattern of patch application. Was it a patch that was applied or backported to existing openjdk releases, and are @14 and @16 the latest releases of those series? At least to me as a naive outside observer, the patch being needed for some of the older release branches but not others sounds like a patch applied to multiple existing release branches, with openjdk@14 and @16 being at older point releases from prior to the patch being applied upstream. HTH! (And I apologize for the noise if not!) Cheers, Kaelyn > Well, in @17, @18 and @19 the patch seems to be definitely integrated > into the source code. > > Andreas
Re: Openjdk (was: Merging core-updates?)
Am Fri, Feb 17, 2023 at 03:49:19PM +0100 schrieb Andreas Enge: > Hm, I compiled up to openjdk@13, @14 fails with the message below. > This is strange. It looks as if the patch that has become obsolete, > because integrated into the source @13, is needed again @14! > And then @15, the patch is again already integrated into the source code. > Very weird! Things become totally crazy. So far I have compiled @13 without the patch, @14 with the patch, @15 without the patch, and @16 seems to need it again. Is this an odd/even thing? Are there spring and autumn versions of openjdk with different release teams? Well, in @17, @18 and @19 the patch seems to be definitely integrated into the source code. Andreas
Re: Openjdk (was: Merging core-updates?)
> The following seems to work and create source for openjdk13 and later:
> (define-public openjdk13
> (make-openjdk openjdk12 "13.0.13"
> "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji"
> (source (origin
> (inherit (package-source base))
> (patches '())
Hm, I compiled up to openjdk@13, @14 fails with the message below.
This is strange. It looks as if the patch that has become obsolete,
because integrated into the source @13, is needed again @14!
And then @15, the patch is again already integrated into the source code.
Very weird!
Giving it a try now.
Andreas
Creating CDS archive for jdk image
In file included from
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/libstepBreakPopReturn.cpp:31:
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.cpp:
In function 'MethodName* getMethodName(jvmtiEnv*, jmethodID)':
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.cpp:100:12:
warning: 'char* strncpy(char*, const char*, size_t)' specified bound 256
equals destination size [-Wstringop-truncation]
100 | strncpy(mn->classSig, szSignature, sizeof(mn->classSig));
| ~~~^
In file included from
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/share/libIndyRedefineClass.cpp:31:
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.cpp:
In function 'MethodName* getMethodName(jvmtiEnv*, jmethodID)':
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.cpp:100:12:
warning: 'char* strncpy(char*, const char*, size_t)' specified bound 256
equals destination size [-Wstringop-truncation]
100 | strncpy(mn->classSig, szSignature, sizeof(mn->classSig));
| ~~~^
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:
In function 'set_signal_handler':
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:71:15:
error: storage size of 'altstack' isn't constant
71 | static char altstack[SIGSTKSZ];
| ^~~~
make[3]: *** [JtregNativeHotspot.gmk:1532:
/tmp/guix-build-openjdk-14.0.2.drv-0/source/build/linux-x86_64-server-release/support/test/hotspot/jtreg/native/support/exeinvoke/exeinvoke.o]
Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** [make/Main.gmk:550: build-test-hotspot-jtreg-native] Error 2
ERROR: Build failed for target 'all' in configuration
'linux-x86_64-server-release' (exit code 2)
=== Output from failing command(s) repeated here ===
* For target support_test_hotspot_jtreg_native_support_exeinvoke_exeinvoke.o:
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:
In function 'set_signal_handler':
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:71:15:
error: storage size of 'altstack' isn't constant
71 | static char altstack[SIGSTKSZ];
| ^~~~
* All command lines available in
/tmp/guix-build-openjdk-14.0.2.drv-0/source/build/linux-x86_64-server-release/make-support/failure-logs.
=== End of repeated output ===
No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: See doc/building.html#troubleshooting for assistance.
make[1]: *** [/tmp/guix-build-openjdk-14.0.2.drv-0/source/make/Init.gmk:312:
main] Error 2
make: *** [/tmp/guix-build-openjdk-14.0.2.drv-0/source/make/Init.gmk:186: all]
Error 2
error: in phase 'build': uncaught exception:
%exception #< program: "make" arguments: ("all" "JOBS=4")
exit-status: 2 term-signal: #f stop-signal: #f>
phase `build' failed after 1605.0 seconds
command "make" "all" "JOBS=4" failed with status 2
builder for `/gnu/store/3i4i2kh5zbw2l3rdp7gx41ykxgnbfr1x-openjdk-14.0.2.drv'
failed with exit code 1
build of /gnu/store/3i4i2kh5zbw2l3rdp7gx41ykxgnbfr1x-openjdk-14.0.2.drv failed
View build log at
'/var/log/guix/drvs/3i/4i2kh5zbw2l3rdp7gx41ykxgnbfr1x-openjdk-14.0.2.drv.gz'.
Re: Openjdk (was: Merging core-updates?)
Hello, Am Thu, Feb 16, 2023 at 01:03:35PM +0200 schrieb Efraim Flashner: > > Okay to push if I manage to build current openjdk with it? > Yeah, that's probably fine. after a day, I got past the point of mesa in core-updates on x86_64. Which in itself is an encouraging milestone. Andreas
Re: Openjdk (was: Merging core-updates?)
Le 16 février 2023 12:03:35 GMT+01:00, Efraim Flashner a écrit : >On Wed, Feb 15, 2023 at 08:19:08PM +0100, Andreas Enge wrote: > >> Is it necessary to keep all these version of openjdk and to bootstrap >> version n with version n-1? > >Probably? I assume if you can cut some out that'd be ok. I'm pretty sure >openjdk-11 and openjdk-17 are considered LTS by upstream so it would >make sense to keep those specifically. Upstream ensures openjdk N+1 can be built by openjdk N, but not necessarily with N-1. We can try :)
Re: Openjdk (was: Merging core-updates?)
On Wed, Feb 15, 2023 at 08:19:08PM +0100, Andreas Enge wrote: > Am Wed, Feb 15, 2023 at 07:51:56PM +0100 schrieb Andreas Enge: > > Actually the patch has already been applied to openjdk13, if I am not > > mistaken. So I do not understand how the source could be built in master > > then, while the exact same code (?!) fails on core-updates... > > Well, there is a somewhat hidden difference. > core-updates introduces > "openjdk-10-hotspot-pointer-comparison.patch" > "openjdk-10-hotspot-stack-size.patch" > to openjdk10. > > openjdk11 is a package of its own without the patch. > > openjdk12 uses the newly defined make-openjdk to start from openjdk11, > overwriting the source together with openjdk-10-hotspot-stack-size.patch > in core-updates, and without the patch in master. (And it uses an obscure > tarball instead of a git checkout - why?) > > openjdk13 has the same code in core-updates and master: > (define-public openjdk13 > (make-openjdk openjdk12 "13.0.13" > "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji")) > So in core-updates it inherits the patch from openjdk12, in master > it does not (I think). And then I suppose it passes the patch on to all > its descendants. It's definitely possible that the master->core-updates merge messed with the package definitions and the inheritance and I didn't notice it. > The following seems to work and create source for openjdk13 and later: > (define-public openjdk13 > (make-openjdk openjdk12 "13.0.13" > "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji" > (source (origin > (inherit (package-source base)) > (patches '()) > > Okay to push if I manage to build current openjdk with it? Yeah, that's probably fine. > Is it necessary to keep all these version of openjdk and to bootstrap > version n with version n-1? Probably? I assume if you can cut some out that'd be ok. I'm pretty sure openjdk-11 and openjdk-17 are considered LTS by upstream so it would make sense to keep those specifically. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Openjdk (was: Merging core-updates?)
Am Wed, Feb 15, 2023 at 07:51:56PM +0100 schrieb Andreas Enge: > Actually the patch has already been applied to openjdk13, if I am not > mistaken. So I do not understand how the source could be built in master > then, while the exact same code (?!) fails on core-updates... Well, there is a somewhat hidden difference. core-updates introduces "openjdk-10-hotspot-pointer-comparison.patch" "openjdk-10-hotspot-stack-size.patch" to openjdk10. openjdk11 is a package of its own without the patch. openjdk12 uses the newly defined make-openjdk to start from openjdk11, overwriting the source together with openjdk-10-hotspot-stack-size.patch in core-updates, and without the patch in master. (And it uses an obscure tarball instead of a git checkout - why?) openjdk13 has the same code in core-updates and master: (define-public openjdk13 (make-openjdk openjdk12 "13.0.13" "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji")) So in core-updates it inherits the patch from openjdk12, in master it does not (I think). And then I suppose it passes the patch on to all its descendants. The following seems to work and create source for openjdk13 and later: (define-public openjdk13 (make-openjdk openjdk12 "13.0.13" "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji" (source (origin (inherit (package-source base)) (patches '()) Okay to push if I manage to build current openjdk with it? Is it necessary to keep all these version of openjdk and to bootstrap version n with version n-1? Andreas
