On 5/16/2018 10:49 AM, Ty Young wrote:

That one, as mentioned in the wiki build guide. I get an immediate build fail(see: https://pastebin.com/geR4LLMm). The JDK works just fine: I can set it as the default JDK, run Netbeans, set the project source to 11, and my application builds just fine.

Ah, I see. You didn't say what version of gradle or JDK you were using, but this looks like a known problem in trying to run gradle with JDK 11. See:

https://github.com/gradle/gradle/issues/4860
https://bugs.openjdk.java.net/browse/JDK-8199069

This is marked as fixed in gradle 4.8-rc1, but I haven't confirmed this.

And could the new standalone modules be integrated with the source code somehow so that a JDK without JavaFX support can be compiled?

Not sure what you mean, but you can use an OpenJDK without modules + the JavaFX standalone modules to build and run your program.



It's an option, sure. My problem with it is that it creates so much unnecessary disk usage because each bundled application requires it's own copy of JavaFX. If you had 10 standalone JavaFX applications it would be 1GB easily if they where all modular projects, which are around 106MB for me. Creating an app bundle using classpath is around 200MB(post JDK 8 was 250+ IIRC).


One option for you would be to use jlink to create a jre image that includes the javafx modules. This week's openjfx-11-ea+14 build will have a jmods bundle that you can use for this purpose.


As I wrote before and am still having issues with, after a successful first compile, JavaFX no longer compiles in Arch Linux for me. Any attempt to do so results in a bunch of warning messages(see: https://pastebin.com/rJqu7Nws) which cause the build to fail due to warnings being treated as errors(Should they even be ignored?). In addition. I'm now getting a GCC warning about XIMProc returning an int when it should return void (*). I don't know C or the native APIs so right now I'm at a loss of what to do besides trying to compile on another distro - which is something I *really* would prefer not to have to do.

What gcc version are you using? And what Linux distro?


8.1.0 and Arch Linux(Antergos which is basically Arch Linux).


That's not a distro I'm familiar with, but it may or may not be related to the issue you are seeing. The gcc errors may be related to compiling with a more-strict 8.1 compiler; we have tested with up to gcc 7.3, but nothing newer than that. A quick look suggests that we will need some way to suppress that warning. For now, you can modify buildSrc/linux.gradle and remove the "-Werror" flag from LINUX.glass.glassgtk2.ccFlags (ditto for gtk3).

-- Kevin




-- Kevin



Reply via email to