[new-package] java-openjdk 23.u9

[MehdiChinoune]

Unfortunately, It fails to build. Doesn't accept clang even after I tried to use /clang64/bin/gcc.exe

@TheShermanTanker

[raedrizqie]

oopss sorry.. my mistake

[TheShermanTanker]

Thanks for paging for me, I'll try to see what's going wrong with the package

[TheShermanTanker]

A few notes:

• make product-bundles creates the JDK as distributed by Oracle, and can probably be used instead of make images. The JDK is inside the bundles directory as a .zip or .tar.gz file
• I'm not sure directly adding those options via --with-extra-cflags and --with-extra-cxxflags is a good idea, especially the optimization options. Those are very specifically set by the make system to fit with the JDK's requirements and touching them should probably be avoided
• I will try to fix the system vs bundled library errors
• --without-version-opt is not the correct way to version the JDK, as I have recently found out. I'm not sure what the right way is, will get back to you when I confirm it with the Oracle build team
• There are build files and source files that can be used to brand the JDK, let me know if MSYS2 wants to custom brand the JDK

[TheShermanTanker]

Picking the commit by SHA from my branch is probably not a good idea, since the SHA often changes when I rebase on top of latest master. Is there a way to do it by name? Also, it seems the packing has failed, seemingly due to the JDK's restriction on using make -jN

  ==> Starting package()...
  Note: Command line contains non-control variables:
  * DESTDIR=/C/_/B/pkg/mingw-w64-ucrt-x86_64-java-openjdk
  Make sure it is not mistyped, and that you intend to override this variable.
  'make help' will list known control variables.
  
  Error: 'make -jN' is not supported, use 'make JOBS=N'
  /c/_/b/src/jdk-jdk-23-9/make/Init.gmk:115: *** Cannot continue.  Stop.
  ==> ERROR: A failure occurred in package().
      Aborting...
  ==> Removing installed dependencies...
  checking dependencies...

[TheShermanTanker]

  # Check for invalid make flags like -j
  define CheckInvalidMakeFlags
    # This is a trick to get this rule to execute before any other rules
    # MAKEFLAGS only indicate -j if read in a recipe (!)
    $$(topdir)/make/Init.gmk: .FORCE
	$$(if $$(findstring --jobserver, $$(MAKEFLAGS)), \
	    $$(info Error: 'make -jN' is not supported, use 'make JOBS=N') \
	    $$(error Cannot continue) \
	)
    .FORCE:
    .PHONY: .FORCE
  endef

seems to be the culprit

[TheShermanTanker]

I've pushed the system library bugfix, there is now no need for the extra patches

[TheShermanTanker]

A few notes:

• make product-bundles creates the JDK as distributed by Oracle, and can probably be used instead of make images. The JDK is inside the bundles directory as a .zip or .tar.gz file
• I'm not sure directly adding those options via --with-extra-cflags and --with-extra-cxxflags is a good idea, especially the optimization options. Those are very specifically set by the make system to fit with the JDK's requirements and touching them should probably be avoided
• I will try to fix the system vs bundled library errors
• --without-version-opt is not the correct way to version the JDK, as I have recently found out. I'm not sure what the right way is, will get back to you when I confirm it with the Oracle build team
• There are build files and source files that can be used to brand the JDK, let me know if MSYS2 wants to custom brand the JDK

I still have a few review points, listed here

[MehdiChinoune]

A few notes:

• make product-bundles creates the JDK as distributed by Oracle, and can probably be used instead of make images. The JDK is inside the bundles directory as a .zip or .tar.gz file

I don't understand this note.

• I'm not sure directly adding those options via --with-extra-cflags and --with-extra-cxxflags is a good idea, especially the optimization options. Those are very specifically set by the make system to fit with the JDK's requirements and touching them should probably be avoided

We have some default to when building packges, we do that with all packages, unless it breaks it. All distributions have something similar.

• --without-version-opt is not the correct way to version the JDK, as I have recently found out. I'm not sure what the right way is, will get back to you when I confirm it with the Oracle build team

I have removed it and used the options used by Arch Linux.

• There are build files and source files that can be used to brand the JDK, let me know if MSYS2 wants to custom brand the JDK

AFAIK, the only package branded by MSYS2 is GCC. @lazka what do you think?

[TheShermanTanker]

Oracle has gotten back to me on how their versioning works, --with-version-build=35 --with-version-pre= --with-version-opt=LTS-2513 is how the following version string was created:

java 21 2023-09-19 LTS Java(TM) SE Runtime Environment (build 21+35-LTS-2513) Java HotSpot(TM) 64-Bit Server VM (build 21+35-LTS-2513, mixed mode, sharing)

I don't understand this note.

What I meant is, instead of make images, we probably should be using make product-bundles. With make product-bundles, the resulting JDK is in the bundles directory as a zip file

We have some default to when building packges, we do that with all packages, unless it breaks it. All distributions have something similar.

The stack protector and optimization flags are somewhat problematic for the JDK, since -O2 hurts the JVM's performance and stack protector can break linking (I've experienced this before when working on the JDK)

[filnet]

We recently branded Rust:

$ rustc --version
rustc 1.76.0 (07dca489a 2024-02-04) (Rev1, Built by MSYS2 project)

[lazka]

• There are build files and source files that can be used to brand the JDK, let me know if MSYS2 wants to custom brand the JDK

AFAIK, the only package branded by MSYS2 is GCC. @lazka what do you think?

I guess branding helps with upstream knowing from which downstream bug reports come from? I don't mind it.

[MehdiChinoune]

@lazka Could you bootstrap it and upload it to repo.

[lazka]

Building with the CI version gives me:

checking for version string... 23+9
checking for javac... /ucrt64/bin/javac.exe
checking for java... /ucrt64/bin/java.exe
configure: Found potential Boot JDK using java(c) in PATH
configure: error: The path of BOOT_JDK, which resolves as "/ucrt64", could not be imported.
configure exiting with result code 1

am I missing something?

[Kreijstal]

Would the next version depend on oracle's jdk or MSYS2's? (After the jdk is in the repo)

[Kreijstal]

Building with the CI version gives me:

checking for version string... 23+9
checking for javac... /ucrt64/bin/javac.exe
checking for java... /ucrt64/bin/java.exe
configure: Found potential Boot JDK using java(c) in PATH
configure: error: The path of BOOT_JDK, which resolves as "/ucrt64", could not be imported.
configure exiting with result code 1

am I missing something?

I managed to build it like this.

wget https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.2+13/OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13.zip
unzip OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13.zip
pushd jdk-21.0.2+13/bin
PATH=$PWD:$PATH
popd
# then makepkg-mingw as usual

https://cdn.discordapp.com/attachments/794220101741838401/1220945506046316614/image.png?ex=6610c91c&is=65fe541c&hm=878dcddfbb1803bdf537f5f08f3fa30c93ee270a2fa68dc6b53c58289d8900cf&

Should bootstrapping be done at CI level?

[MehdiChinoune]

I managed to build it like this.

wget https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.2+13/OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13.zip
unzip OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13.zip
pushd jdk-21.0.2+13/bin
PATH=$PWD:$PATH
popd
# then makepkg-mingw as usual

https://cdn.discordapp.com/attachments/794220101741838401/1220945506046316614/image.png?ex=6610c91c&is=65fe541c&hm=878dcddfbb1803bdf537f5f08f3fa30c93ee270a2fa68dc6b53c58289d8900cf&

Should bootstrapping be done at CI level?

He is talking about bootstrapping, We already succeed to build it.

[Kreijstal]

ahh but stage 2 does not work? It seems I can't compile java with the built compiler?

[TheShermanTanker]

Building with the CI version gives me:

checking for version string... 23+9
checking for javac... /ucrt64/bin/javac.exe
checking for java... /ucrt64/bin/java.exe
configure: Found potential Boot JDK using java(c) in PATH
configure: error: The path of BOOT_JDK, which resolves as "/ucrt64", could not be imported.
configure exiting with result code 1

am I missing something?

I've seen this before, it appears to be a problem when the JDK installed is for a different system (IE trying to configure with a JDK compiled for Windows while using WSL to compile a JDK for Linux). It might be a bug, I feel. I'll try looking into it (but first I need to rebase on top of the huge breaking changes recently made in the JDK's build system...)

[Kreijstal]

Nevermind, it seems you must delete the src and pkg file completely before attempting a new build otherwise it will crash. You can rebuild java with it. Stage 2 does indeed work

[Kreijstal]

Ah I found something

Exception in thread "main" java.lang.UnsatisfiedLinkError: E:\msys64\ucrt64\bin\awt.dll: A dynamic link library (DLL) initialization routine failed
        at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
        at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139)
        at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:259)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:249)
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2411)
        at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
        at java.base/java.lang.System.loadLibrary(System.java:2068)
        at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:1384)
        at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:1382)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
        at java.desktop/java.awt.Toolkit.loadLibraries(Toolkit.java:1381)
        at java.desktop/java.awt.Toolkit.initStatic(Toolkit.java:1419)
        at java.desktop/java.awt.Toolkit.<clinit>(Toolkit.java:1393)
        at java.desktop/javax.swing.UIManager.<clinit>(UIManager.java:387)
        at net.alterorb.launcher.ui.UIConstants.loadResources(UIConstants.java:37)
        at net.alterorb.launcher.Bootstrap.main(Bootstrap.java:18)

while launching https://github.com/alterorb/launcher but temurin jdk, seems to work just fine

[TheShermanTanker]

Ah I found something

Exception in thread "main" java.lang.UnsatisfiedLinkError: E:\msys64\ucrt64\bin\awt.dll: A dynamic link library (DLL) initialization routine failed
        at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
        at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139)
        at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:259)
        at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:249)
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2411)
        at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
        at java.base/java.lang.System.loadLibrary(System.java:2068)
        at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:1384)
        at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:1382)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
        at java.desktop/java.awt.Toolkit.loadLibraries(Toolkit.java:1381)
        at java.desktop/java.awt.Toolkit.initStatic(Toolkit.java:1419)
        at java.desktop/java.awt.Toolkit.<clinit>(Toolkit.java:1393)
        at java.desktop/javax.swing.UIManager.<clinit>(UIManager.java:387)
        at net.alterorb.launcher.ui.UIConstants.loadResources(UIConstants.java:37)
        at net.alterorb.launcher.Bootstrap.main(Bootstrap.java:18)

while launching https://github.com/alterorb/launcher but temurin jdk, seems to work just fine

I'm already aware of that issue, awt.dll seems to be broken when compiled by gcc. Haven't found a solution to the problem yet, unfortunately

[MehdiChinoune]

Sorry, I am not interested anymore in this package. Feel free to open a new PR.