Package Details: java-openjfx 22.0.2.u4-1

Git Clone URL: https://aur.archlinux.org/java-openjfx.git (read-only, click to copy)
Package Base: java-openjfx
Description: Java OpenJFX client application platform (open-source implementation of JavaFX) - latest version
Upstream URL: https://wiki.openjdk.java.net/display/OpenJFX/Main
Keywords: javafx openjfx
Licenses: GPL-2.0-only WITH Classpath-exception-2.0
Provides: java-openjfx
Submitter: freswa
Maintainer: AutoUpdateBot
Last Packager: Freso
Votes: 10
Popularity: 0.43
First Submitted: 2023-10-08 20:20 (UTC)
Last Updated: 2024-08-15 13:14 (UTC)

Dependencies (33)

Sources (3)

Pinned Comments

Freso commented on 2024-04-17 10:17 (UTC)

@aubin Just use the java21-openjfx package?

For everyone else, disabling the building of WebKit seems to unbreak the build (for me at least). I’m not sure how essential the WebKit parts are to JavaFX overall, so a bit wary about changing this part of the PKGBUILD here. For anyone who wants to try it out, you can grab the package from this branch: https://gitlab.archlinux.org/freso/java-openjfx/-/tree/java-openjfx-no-webkit

Freso commented on 2024-03-31 22:35 (UTC)

Patches etc. are very welcome at https://gitlab.archlinux.org/freso/java-openjfx if you have any suggestions for how to fix the package. :)

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

sl1pkn07 commented on 2024-03-28 19:20 (UTC) (edited on 2024-03-28 19:22 (UTC) by sl1pkn07)

i think i found the problem. the problem may be is makepkg iself

in the makepkg.conf:

the line LDFLAGS= is separated in two lines: \ character, new line, and 10 spaces

LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now \
         -Wl,-z,pack-relative-relocs"

remove 9 spaces and the new line character (\n), wich correspond to the 9 "/usr/bin/ld: no se puede encontrar : No existe el fichero o el directorio (in english) fails, of them start build without problem. so can trim it with sed or directly in the makepkg.conf file for short to only one unique line

so, bad hack can be:

export LDFLAGS="$(echo ${LDFLAGS} | sed -e 's|[[:space:]][[:space:]]|[[:space:]]|g' -e 's|\n||g')"

greetings

Freso commented on 2024-02-15 08:19 (UTC)

@w568w Does it work/build for you if you change those lines to:

  export CFLAGS="${CFLAGS:=}"
  export LDFLAGS="${LDFLAGS:=}"

w568w commented on 2024-02-05 13:45 (UTC)

@Freso Yes, I can confirm that it builds without these two lines:

export CFLAGS=${CFLAGS:=}
export LDFLAGS=${LDFLAGS:=}

Perhaps a simple workaround would be to terminate with error when CFLAGS or LDFLAGS is missing?

Since the actual problem is in java-openjfx-flags.patch, a more complete solution should be to fix this patch... However, I have no experience in writing Groovy.

Freso commented on 2024-02-03 09:46 (UTC)

Does it build correctly for you with those lines removed/commented out? Because the package doesn’t currently build for me (with or without those lines) and I haven’t figured out what’s going on yet.

w568w commented on 2024-01-20 07:26 (UTC) (edited on 2024-01-20 07:31 (UTC) by w568w)

Hi @Freso , your workaround may not work with LDFLAGS not set. LDFLAGS is set to an empty string in PKGBUILD, which seems to be passed to linker as-is then, i.e.:

ld "" --other-flags /other/paths

Thus ld will complain that it cannot find file named "":

ld  : no such file or directory

w568w commented on 2023-11-05 04:50 (UTC) (edited on 2023-11-05 04:51 (UTC) by w568w)

@Freso In fact these lines seem to be included in this package's patch:

@@ -43,8 +43,11 @@ LINUX.library = { name -> return (IS_STATIC_BUILD ? "lib${name}.a" : "lib${name}
 def commonFlags = [
         "-fno-strict-aliasing", "-fPIC", "-fno-omit-frame-pointer", // optimization flags
         "-fstack-protector",
+        "-Wno-error=cast-function-type",
         "-Wextra", "-Wall", "-Wformat-security", "-Wno-unused", "-Wno-parentheses", "-Werror=trampolines"] // warning flags

+commonFlags.addAll(System.getenv("CFLAGS").trim().replaceAll(" +", " ").split(" "))
+
 if (!IS_64) {
     commonFlags += "-m32"
 }

Does not look like an upstream issue.

Freso commented on 2023-11-02 15:58 (UTC) (edited on 2023-11-02 19:32 (UTC) by Freso)

Did you report the CFLAGS and LDFLAGS issue to upstream? Seems like a check they should have in their build system rather than breaking the build with them unset. Edit: Didn’t see anything on https://bugs.openjdk.org/issues/?jql=component%20%3D%20javafx%20AND%20text%20~%20%22CFLAGS%22 so I’m guessing not.

w568w commented on 2023-10-23 00:23 (UTC) (edited on 2023-10-23 01:33 (UTC) by w568w)

This package requires a non-null CFLAGS and LDFLAGS during the build.

src/jfx21u-21.0.1-6/buildSrc/linux.gradle:

linkFlags.addAll(System.getenv("LDFLAGS").trim().split(" "))

If you have never set them before, make sure they have a value in /etc/makepkg.conf.

Edit: The build process can be very memory-consuming. If you have a small RAM installed like me (<= 16 GB), try specifying less parallelism:

export CMAKE_BUILD_PARALLEL_LEVEL=8
gradle zips

Bitals commented on 2023-10-17 08:53 (UTC)

@Pilli builds fine with your patch from 2023-10-12 and no other changes, thanks.

jghodd commented on 2023-10-16 15:25 (UTC)

@Pilli (et al.) - I was able to complete the build only after changing my java version to 17 from 21 (and after following the advice @Pilli provided). Y'all might want to clarify that one must change the version of the java jre/jdk to 17. Many folks are already running 21. Maybe make it a dependency...?

« First ‹ Previous 1 2 3 4 Next › Last »