Add warnings on Windows and Linux AArch64 #1279

jperedadnr · 2024-09-09T08:34:12Z

After #1273, Windows and Linux AArch64 are not supported yet.

src/main/java/com/gluonhq/substrate/target/LinuxTargetConfiguration.java

src/main/java/com/gluonhq/substrate/target/WindowsTargetConfiguration.java

ctoabidmaqbool · 2024-09-09T15:30:42Z

Hi! Why Windows are not supported yet? Is there any plans, how much time it's will taks to support windows too, like Linux and MacOs?

Hugolarson · 2024-09-09T15:38:19Z

Tried windows AMD 64 and it works.

credmond · 2024-09-10T00:12:55Z

Hi! Why Windows are not supported yet? Is there any plans, how much time it's will taks to support windows too, like Linux and MacOs?

The fact that there is a PR to warn that Windows is not supported (as opposed to fixing it), is a bad sign.

What's the challenge here?

abhinayagarwal · 2024-09-10T06:44:47Z

What's the challenge here?

We don't have vmone for windows yet. If someone can update the Makefile to bundle the jvm libs with jdklibs, we might be able to do a windows release.

credmond · 2024-09-10T07:36:46Z

What's the challenge here?

We don't have vmone for windows yet. If someone can update the Makefile to bundle the jvm libs with jdklibs, we might be able to do a windows release.

I don't think it's going to come from the community, as vmone doesn't even have a description, etc.

It's very frustrating how Windows (and desktop OS's in general) seem to be second-class citizens / afterthoughts.

#1241 should not be closed just because Gluon's mobile use-cases are covered, it's misleading and confusing.

(of course we're grateful for the efforts in general though!)

ctoabidmaqbool · 2024-09-10T09:32:14Z

What's the challenge here?

We don't have vmone for windows yet. If someone can update the Makefile to bundle the jvm libs with jdklibs, we might be able to do a windows release.

I don't think it's going to come from the community, as vmone doesn't even have a description, etc.

It's very frustrating how Windows (and desktop OS's in general) seem to be second-class citizens / afterthoughts.

#1241 should not be closed just because Gluon's mobile use-cases are covered, it's misleading and confusing.

(of course we're grateful for the efforts in general though!)

Exactly!

johanvos · 2024-09-10T10:17:24Z

What's the challenge here?

We don't have vmone for windows yet. If someone can update the Makefile to bundle the jvm libs with jdklibs, we might be able to do a windows release.

I don't think it's going to come from the community, as vmone doesn't even have a description, etc.

It's very frustrating how Windows (and desktop OS's in general) seem to be second-class citizens / afterthoughts.

#1241 should not be closed just because Gluon's mobile use-cases are covered, it's misleading and confusing.

(of course we're grateful for the efforts in general though!)

Everything we released so far comes from "the community". We are not Oracle. We are not Microsoft. We have no VC's. I think we can honestly say that we (Gluon) are part of "the community".
Building native things in Windows is not trivial, and with zero help/interest from Microsoft, it's not easy for us.

In general, I recommend being more friendly towards people who spend most of their spare time on open source projects, without getting paid for it.

johanvos · 2024-09-10T10:24:39Z

About the reason why we focus on Mobile first: there is no real alternative if you want to run the latest Java on iOS/Android. It is far from simple to provide that. It costs lots of time, and it spans completely different skills (Java/C, compiler understanding, posix structures, build tools) that are hard to find (in an OSS project).
There are other solutions for desktop, and while probably not ideal, at least there is something.
We have to decide how to use the limited number of resources, and I personally think it's better to make sure we have a more recent build that works on iOS and Android in the near future, rather than having to wait years before we have a build that works on all desktop platforms.
And trust me, I'd love to have head-support for all desktop platforms as well. It's just that the pressure for having the mobile platforms is really high, so we have to make choices.

credmond · 2024-09-10T11:24:42Z

About the reason why we focus on Mobile first: there is no real alternative if you want to run the latest Java on iOS/Android. It is far from simple to provide that. It costs lots of time, and it spans completely different skills (Java/C, compiler understanding, posix structures, build tools) that are hard to find (in an OSS project). There are other solutions for desktop, and while probably not ideal, at least there is something. We have to decide how to use the limited number of resources, and I personally think it's better to make sure we have a more recent build that works on iOS and Android in the near future, rather than having to wait years before we have a build that works on all desktop platforms. And trust me, I'd love to have head-support for all desktop platforms as well. It's just that the pressure for having the mobile platforms is really high, so we have to make choices.

Sorry if these or other comments are coming across as unfriendly or demanding @johanvos, 100% not the intentional tone from myself anyway (you'd see if it was a voice conversation) -- I do have a habit of typing like a robot when rushing. Although at times frustrated, I am genuinely trying to be constructive and represent the feelings of the desktop-only folks out there (I've chatted to a few of the devs from big JavaFX projects over the years -- they're practically all interested in going native).

Regarding this release, I see the main sources of frustration as being primarily a simple communication problem that should be easily solvable.

E.g., regarding this/similar releases, it's confusing trying to understand what's going on in the background with Gluon (i.e., outcomes of the conversations that happen elsewhere), and what's on any roadmap or what obstacles are being encountered, or what "not supported yet" actually might mean (i.e., it's being worked on by someone, it's on some roadmap, or it's not and don't expect it, etc). There's lots of knowledge and insights that could be shared, but those of us outside the Gluon inner-circle have no feasible way of figuring out what's going on or what's being worked on by those most knowledgeable.

Regarding the rationale on desktop vs mobile priorities -- this is all understandable and I think we've discussed before, but it could just be made clearer about what's being delivered and why -- what works and what doesn't, and what to expect. It doesn't need to be a costly or particularly well-written form of communication.

When I said "the community" I of course did not mean to imply Gluon is some separate well-funded entity with deep pockets, but I mean those folks outside of Gluon who have no idea what vmone is, as an example, or what the challenges around Windows/whatever are, how problematic they are or aren't -- the vast majority of folks won't be both competent Java & C engineers and won't know where to begin, but many probably could contribute with some help.

But the only source of discussion seems to be via raising issues and chatting such as on this one. It would be great if there was a better way to communicate, share knowledge, encourage and accept contributions -- but I've said that elsewhere on another thread you've responded to.

FYI I'm currently a hobbyist when it comes to desktop JavaFX apps, providing (currently) free-to-use apps -- I get no income either despite pumping insane amounts of time into some projects. I'm also not unfamiliar with C / compilers / posix, etc., though I'd dip-in-and-out only as strictly required these-days and by no means an expert, but would have attempted to contribute more if I knew where to begin or that the contributions were on the right track and not already being worked on by someone, etc.

ctoabidmaqbool · 2024-09-10T11:46:43Z

In Asian countries like Pakistan, most of the people are Windows users, followed by Android users.

So my priorities are: Windows -> Android -> Linux -> macOS

I have been using JavaFX for almost 10 years and Gluon plugins too from the very beginning.

Now when I hear, "Hi! Windows support from Gluon becomes second priority," I think, what's going on?

Honestly, after the old javafxmobile-plugin, everything has changed. Now it's like building the technology first then using technology!

I am struggling hard to switch to gluonfx-maven-plugin / gluonfx-gradle-plugin, but honestly, I can't. There are tons of issues. Still using the old javafxmobile-plugin and Java 8 for the Android part.

And still, native desktop apps are too challenging, using simple Zulu JDK 17.x for desktop Windows apps.

johanvos · 2024-09-10T12:04:46Z

As for the communications/discussions: I get the point that it is difficult to understand what is happening and where.
But here again, contrary to the big companies, we have no devrel/marketing/docwriters/sales people that make it clear. I wish there were more people from the community picking up that role, but I am not blaming anyone as it is not trivial.

One of the things is that Substrate is just one of the components. The codebase of Substrate itself is rather small, it is mainly the glue between different components that are not created to work together. I try to move the focus to OpenJDK/mobile (see https://github.com/openjdk/mobile) and I try to gather more contributions/discussions on the mailinglist there, but it's hard. I get great feedback from OpenJDK developers there, and I'm very happy with that.

Currently, we use the artifacts produced by OpenJDK/mobile code/builds, and those are very reproducible, and they don't contain dirty hacks. So that is the first step towards a clear, understandable, documented path -- as the diff with upstream jdk is really small.
The AOT compiler is another thing. We currently use GraalVM native-image for this, and we're happy with the research that was done in the past, but the focus/usecase for GraalVM is not really Java on Mobile. The development process is also different, and much harder to deal with for an external project. (in OpenJDK, we can create JBS issues, and we know that there won't be a commit pushed to the sources unless it is clearly described in a JBS issue and discussed).
The result of a GraalVM native-image compilation is an object file with parts of the VM in it. But not all parts. Also, the JDK class libs (that come from openjdk/mobile) need to talk to the VM as well. There is no 1-1 match between a GraalVM release and an OpenJDK release. Hence, having a single VM that can work with both the GraalVM created artifacts and the JDK static libs is not trivial. We had frustrating issues in the past, related to dependencies on different versions of Graal/JDK, and related to different platforms/and versions.
We now have the VM code in one repository (vmone) which I don't consider the best solution, but at least it allows us to have a set of files that we know are working with both the GraalVM artifacts and the JDK static libs, without having to rely on dirty hacks in the past where we were never sure whether some functions were already in the objectfile or not.

In the longer term, I think it would be better if we can get the VM files from the source itself (openjdk/jdk), but the current showstopper for this is that we can not use hotspot on iOS.

This is a discussion though that I think should happen on the openjdk/mobile list, where we should be able to come to a clean, maintainable solution that works on all platforms (mobile and desktop). Meanwhile, we have Substrate as a project where we try to combine things-that-were-not-designed-to-work-together. That is already a difficult task if we had one target platform (e.g. Android OR iOS), and it becomes harder if we have 2 platforms (Android AND iOS). It's also non-trivial because we need a GraalVM build for Mac to support iOS development, and a Linux build to support Android development.
Add the different versions of iOS/Android, different versions of Java, different versions of JavaFX to that mix, and it becomes really hard to maintain. Add a non-posix platform like Windows, and it's even harder.

johanvos

The choice is clear:

do we want an up-to-date Java and JavaFX for mobile now?
or
do we want an up-to-date Java and JavaFX for all platforms in an unspecified time in the future?

I vote for 1.

ctoabidmaqbool · 2024-09-10T14:29:03Z

2. do we want an up-to-date Java and JavaFX for all platforms in an unspecified time in the future?

Many of the peoples use JavaFx only for cross-platform development, not for just Mobile only cross-platfom, I think so!

Otherwise, for native codding, native method are best choice e.g. Android Studio way for Android Apps and so on (the reason behind we get 100% quick support and lot of community using, can get helps from anywhere)!

The main technology which is using is still GraalVM native-image, and GraalVM native-image is not 100% supporting Swing/AWT. Can any one create secessfully GUI Apss with Swing/AWT, as 100'rd of lib are dependent upon it!

Then Android part is another issue ast .awt package is not there and so on!

So how can someone make secessfully comple GUI apps for mobile!

In short GUI cross-platforms must be the target both desktop os and mobile os!

As we get benefits that our Apps can run on Desktop OS, so development, and testing becomes easy then ports to mobile as the apps move forward!

johanvos · 2024-09-10T14:49:11Z

Many of the peoples use JavaFx only for cross-platform development

True, but what is missing from the "regular" JavaFX builds and plugins for doing this? I could be missing something, but that is where the default platform builds are for (https://gluonhq.com/products/javafx), in combination with the javafx-maven plugin.

ctoabidmaqbool · 2024-09-10T16:40:00Z

but what is missing from the "regular" JavaFX builds and plugins for doing this?

I was thinking, my Windows Javafx Apps boot-up performance using graalvm native-image. But that dream is going to be ended up!

Gluon only for Mobile devices, and Javafx for Desktop one!

credmond · 2024-09-10T20:59:04Z

but what is missing from the "regular" JavaFX builds and plugins for doing this?

I was thinking, my Windows Javafx Apps boot-up performance using graalvm native-image. But that dream is going to be ended up!

Gluon only for Mobile devices, and Javafx for Desktop one!

I think the message here is to stick with JDK 17, GraalVM 22 and substrate plugin version 1.0.23 if you want native images. It seems to me that the mobile-first approach was a tactical decision and that there will be a solution in time for Windows/desktop...

ctoabidmaqbool · 2024-09-11T08:31:45Z

What's the challenge here?

We don't have vmone for windows yet. If someone can update the Makefile to bundle the jvm libs with jdklibs, we might be able to do a windows release.

@abhinayagarwal @jperedadnr @johanvos

I hace secessfully created vmone for windows!

I AM NOT SURE, HOW CAN I TELL THE NECESSORY CHANGES.

should i have to fork the repo or what is the next process?

jperedadnr · 2024-09-11T08:53:16Z

That's great!

Have you tested that your libvmone.lib works for you?

With the latest 1.0.24-SNAPSHOT as is now, have you tried

mvn -Djavalibspath=path\to\staticjdk\lib gluonfx:build gluonfx:nativerun

over some of the Gluon samples (HelloFX, HelloGluon)?

Either if that is the case, or if you get some issues that you can't easily fix, you can fork https://github.com/gluonhq/vmone, add a branch with your changes, and create a PR.

ctoabidmaqbool · 2024-09-11T14:51:22Z

I am working here, after working is my local PC!
https://github.com/ctoabidmaqbool/vmone-fork/tree/windows-impl
yet some testing needed!

ctoabidmaqbool · 2024-09-11T16:22:02Z

Most of the stuff is going to github actions:
https://github.com/ctoabidmaqbool/vmone-fork/actions

credmond · 2024-09-11T17:19:40Z

Most of the stuff is going to github actions: https://github.com/ctoabidmaqbool/vmone-fork/actions

If you setup a self-hosted Windows runner (it's very easy) and get GitHub Actions to use that instead of a remote Windows, you'd probably be able to figure out what's going wrong or what's missing, much easier. I regretted not doing that much much sooner for my projects. Debugging GitHub remote runners is too painful when you can't simply browse the file system or logs, etc...

Just an idea!

ctoabidmaqbool · 2024-09-12T03:26:00Z

If you setup a self-hosted Windows runner (it's very easy) and get GitHub Actions to use that instead of a remote Windows, you'd probably be able to figure out what's going wrong or what's missing, much easier. I regretted not doing that much much sooner for my projects. Debugging GitHub remote runners is too painful when you can't simply browse the file system or logs, etc...

We have a pirvate VPS Linux Hosting at Contabo. A long time ago I alrday have steup custom github runner using VPS hosting. And yeah, it's more easy to do debugging and testing on own customer runnter then Github provided runner. It's a much pain to works with remotly gihtub provided runner.
Another option also is github worksplaces too. Maybe I have to setup again own runner!

ctoabidmaqbool · 2024-09-13T11:48:16Z

@jperedadnr I have almost comple the vmone windows!
You can see here finally!
https://github.com/ctoabidmaqbool/vmone-fork/releases/tag/gvm-24-3
&&
https://github.com/ctoabidmaqbool/vmone-fork/actions/runs/10848462496

I need to tests these, any suggstions and review or changes are most welcome! @ALL let test these!

ctoabidmaqbool · 2024-09-13T12:05:03Z

mvn -Djavalibspath=path\to\staticjdk\lib gluonfx:build gluonfx:nativerun

my staic lib is here D:\GraalVM-Projects\gluonhq\hello-gluon-ci\lib\libvmone.lib

I am trying but it's not picking static lib at all, what could be?

D:\GraalVM-Projects\gluonhq\hello-gluon-ci>mvnw -Djavalibspath=lib -Pdesktop gluonfx:build gluonfx:nativerun
[INFO] Scanning for projects...
[INFO]
[INFO] -------------------< com.gluonhq.samples:hellogluon >-------------------
[INFO] Building HelloGluon 1.0.0-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- gluonfx-maven-plugin:1.0.24-SNAPSHOT:build (default-cli) @ hellogluon ---
[WARN] Maven will be executed in interactive mode, but no input stream has been configured for this MavenInvoker instance.
[INFO] Scanning for projects...
[INFO]
[INFO] -------------------< com.gluonhq.samples:hellogluon >-------------------
[INFO] Building HelloGluon 1.0.0-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] >>> gluonfx-maven-plugin:1.0.24-SNAPSHOT:compile (default-cli) > process-classes @ hellogluon >>>
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hellogluon ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 11 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ hellogluon ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] <<< gluonfx-maven-plugin:1.0.24-SNAPSHOT:compile (default-cli) < process-classes @ hellogluon <<<
[INFO]
[INFO]
[INFO] --- gluonfx-maven-plugin:1.0.24-SNAPSHOT:compile (default-cli) @ hellogluon ---
Configuration: ProjectConfiguration{graalPath='D:\Programs\graalvm-java23-windows-amd64-gluon-23+25.1-dev', javaStaticSdkVersion='24-2', javafxStaticSdkVersion='24-ea+7.1', javaVersion=23, graalVersion=23, useJNI=true, useJavaFX=true, usePrismSW=false, enableCheckHash=true, targetTriplet=x86_64-microsoft-windows, hostTriplet=x86_64-microsoft-windows, backend='null', bundlesList=[], resourcesList=[], reflectionList=[], jniList=[], initBuildTimeList=[], runtimeArgsList=[], releaseSymbolsList=null, appName='HelloGluon', releaseConfiguration='ReleaseConfiguration{packageType=null, description='The HelloGluon app', vendor='Gluon', version='null', macAppStore=false, macSigningUserName=null, macAppCategory=null, bundleName='null', bundleVersion='null', bundleShortVersion='null', providedSigningIdentity='null', providedProvisioningProfile='null', skipSigning=false, simulatorDevice='null', appLabel='null', versionCode='null', versionName='null', providedKeyStorePath='null', providedKeyStorePassword='null', providedKeyAlias='null', providedKeyAliasPassword='null'}', mainClassName='com.gluonhq.hello.HelloGluonApp', classpath='D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\classes;D:\.my-m2\repository\com\gluonhq\charm-glisten\6.2.3\charm-glisten-6.2.3.jar;C:\Users\MSC-30\.m2\repository\com\gluonhq\attach\display\4.0.21\display-4.0.21-desktop.jar;D:\.my-m2\repository\com\gluonhq\attach\display\4.0.21\display-4.0.21.jar;C:\Users\MSC-30\.m2\repository\com\gluonhq\attach\lifecycle\4.0.21\lifecycle-4.0.21-desktop.jar;D:\.my-m2\repository\com\gluonhq\attach\lifecycle\4.0.21\lifecycle-4.0.21.jar;C:\Users\MSC-30\.m2\repository\com\gluonhq\attach\statusbar\4.0.21\statusbar-4.0.21.jar;D:\.my-m2\repository\com\gluonhq\attach\statusbar\4.0.21\statusbar-4.0.21.jar;C:\Users\MSC-30\.m2\repository\com\gluonhq\attach\storage\4.0.21\storage-4.0.21-desktop.jar;D:\.my-m2\repository\com\gluonhq\attach\storage\4.0.21\storage-4.0.21.jar;D:\.my-m2\repository\com\gluonhq\attach\util\4.0.21\util-4.0.21.jar;D:\.my-m2\repository\org\openjfx\javafx-base\24-ea+5\javafx-base-24-ea+5-win.jar;D:\.my-m2\repository\org\openjfx\javafx-base\24-ea+5\javafx-base-24-ea+5.jar;D:\.my-m2\repository\org\openjfx\javafx-controls\24-ea+5\javafx-controls-24-ea+5-win.jar;D:\.my-m2\repository\org\openjfx\javafx-controls\24-ea+5\javafx-controls-24-ea+5.jar;D:\.my-m2\repository\org\openjfx\javafx-graphics\24-ea+5\javafx-graphics-24-ea+5-win.jar;D:\.my-m2\repository\org\openjfx\javafx-graphics\24-ea+5\javafx-graphics-24-ea+5.jar'}
[Sat Sep 14 05:00:08 PKT 2024][INFO] ==================== COMPILE TASK ====================
             _______  ___      __   __  _______  __    _
[Sat Sep 14 05:00:10 PKT 2024][INFO] We will now compile your code for x86_64-microsoft-windows. This may take some time.
            |       ||   |    |  | |  ||       ||  |  | |
            |    ___||   |    |  | |  ||   _   ||   |_| |
[Sat Sep 14 05:00:10 PKT 2024][FINE] Processing JavaStatic dependencies at lib
            |   | __ |   |    |  |_|  ||  | |  ||       |
            |   ||  ||   |___ |       ||  |_|  ||  _    |
[Sat Sep 14 05:00:10 PKT 2024][FINE] java files not found in lib
            |   |_| ||       ||       ||       || | |   |
            |_______||_______||_______||_______||_|  |__|

    Access to the latest docs, tips and tricks and more info on
java.io.IOException: A location for the static sdk libs was supplied, but the java libs are missing lib
        at com.gluonhq.substrate.util.FileDeps.setupDependencies(FileDeps.java:230)
    how to get support? Register your usage of Gluon Substrate now at

        at com.gluonhq.substrate.util.FileDeps.resolvePath(FileDeps.java:174)
        at com.gluonhq.substrate.util.FileDeps.getJavaFXSDKLibsPath(FileDeps.java:106)
        at com.gluonhq.substrate.target.AbstractTargetConfiguration.processClassPath(AbstractTargetConfiguration.java:788)
        at com.gluonhq.substrate.target.AbstractTargetConfiguration.validateCompileRequirements(AbstractTargetConfiguration.java:392)
        at com.gluonhq.substrate.target.AbstractTargetConfiguration.compile(AbstractTargetConfiguration.java:131)
        at com.gluonhq.substrate.SubstrateDispatcher.nativeCompile(SubstrateDispatcher.java:422)
        at com.gluonhq.NativeCompileMojo.execute(NativeCompileMojo.java:54)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
        at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:370)
    https://gluonhq.com/activate

        at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:351)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:215)


        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:171)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:163)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.519 s
        at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[INFO] Finished at: 2024-09-14T05:00:10+05:00
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:299)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.gluonhq:gluonfx-maven-plugin:1.0.24-SNAPSHOT:compile (default-cli) on project hellogluon: Error: A location for the static sdk libs was supplied, but the java libs are missing lib -> [Help 1]
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:963)
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:296)
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Skipping HelloGluon
[INFO] This project has been banned from the build due to previous failures.
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  14.121 s
[INFO] Finished at: 2024-09-14T05:00:11+05:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.gluonhq:gluonfx-maven-plugin:1.0.24-SNAPSHOT:build (default-cli) on project hellogluon: Error, gluonfx:build failed -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

credmond · 2024-09-13T12:27:13Z

A location for the static sdk libs was supplied

It's looking for libvmone.a only... and throwing that error if it doesn't exist:

private static final List<String> JAVA_FILES = Arrays.asList(
        "libvmone.a"
);

credmond · 2024-09-13T12:30:24Z

A location for the static sdk libs was supplied

It's looking for libvmone.a only... and throwing that error if it doesn't exist:
private static final List<String> JAVA_FILES = Arrays.asList(
        "libvmone.a"
);

As a test (but by no means a solution) rename your lib to "libvmone.a" and see how far it gets?

jperedadnr · 2024-09-13T12:57:42Z

You'll need to apply the necessary changes in Substrate to support vmone on Windows, so you can fork, do the changes and then create a PR.

To test your local changes, clone both Substrate and GluonFX Maven plugin, and install locally:
Substrate: gradlew publishToMavenLocal
Plugin: mvn clean install

ctoabidmaqbool · 2024-09-13T15:56:27Z

To test your local changes, clone both Substrate and GluonFX Maven plugin, and install locally:

Okey! Let me do it!

ctoabidmaqbool · 2024-09-13T16:26:03Z

Okey here is the substrate-fork

hello-gluon-ci after using custome substrate plugins compile tasks done secessfully without any issue e.g. mvnw -Pdesktop gluonfx:compile
But link task having issue, need to be fixed e.g. mvnw -Pdesktop gluonfx:link

the error fatal error LNK1181: cannot open input file 'vmone.lib'

D:\GraalVM-Projects\gluonhq\hello-gluon-ci>mvnw -Pdesktop gluonfx:link
[INFO] Scanning for projects...
[INFO]
[INFO] -------------------< com.gluonhq.samples:hellogluon >-------------------
[INFO] Building HelloGluon 1.0.0-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- gluonfx-maven-plugin:1.0.24-SNAPSHOT:link (default-cli) @ hellogluon ---
Configuration: ProjectConfiguration{graalPath='D:\Programs\graalvm-java23-windows-amd64-gluon-23+25.1-dev', javaStaticSdkVersion='24-3', javafxStaticSdkVersion='24-ea+7.1', javaVersion=23, graalVersion=23, useJNI=true, useJavaFX=true, usePrismSW=false, enableCheckHash=true, targetTriplet=x86_64-microsoft-windows, hostTriplet=x86_64-microsoft-windows, backend='null', bundlesList=[], resourcesList=[], reflectionList=[], jniList=[], initBuildTimeList=[], runtimeArgsList=[], releaseSymbolsList=null, appName='HelloGluon', releaseConfiguration='ReleaseConfiguration{packageType=null, description='The HelloGluon app', vendor='Gluon', version='null', macAppStore=false, macSigningUserName=null, macAppCategory=null, bundleName='null', bundleVersion='null', bundleShortVersion='null', providedSigningIdentity='null', providedProvisioningProfile='null', skipSigning=false, simulatorDevice='null', appLabel='null', versionCode='null', versionName='null', providedKeyStorePath='null', providedKeyStorePassword='null', providedKeyAlias='null', providedKeyAliasPassword='null'}', mainClassName='com.gluonhq.hello.HelloGluonApp', classpath='D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\classes;D:\.my-m2\repository\com\gluonhq\charm-glisten\6.2.3\charm-glisten-6.2.3.jar;C:\Users\MSC-30\.m2\repository\com\gluonhq\attach\display\4.0.21\display-4.0.21-desktop.jar;D:\.my-m2\repository\com\gluonhq\attach\display\4.0.21\display-4.0.21.jar;C:\Users\MSC-30\.m2\repository\com\gluonhq\attach\lifecycle\4.0.21\lifecycle-4.0.21-desktop.jar;D:\.my-m2\repository\com\gluonhq\attach\lifecycle\4.0.21\lifecycle-4.0.21.jar;C:\Users\MSC-30\.m2\repository\com\gluonhq\attach\statusbar\4.0.21\statusbar-4.0.21.jar;D:\.my-m2\repository\com\gluonhq\attach\statusbar\4.0.21\statusbar-4.0.21.jar;C:\Users\MSC-30\.m2\repository\com\gluonhq\attach\storage\4.0.21\storage-4.0.21-desktop.jar;D:\.my-m2\repository\com\gluonhq\attach\storage\4.0.21\storage-4.0.21.jar;D:\.my-m2\repository\com\gluonhq\attach\util\4.0.21\util-4.0.21.jar;D:\.my-m2\repository\org\openjfx\javafx-base\24-ea+5\javafx-base-24-ea+5-win.jar;D:\.my-m2\repository\org\openjfx\javafx-base\24-ea+5\javafx-base-24-ea+5.jar;D:\.my-m2\repository\org\openjfx\javafx-controls\24-ea+5\javafx-controls-24-ea+5-win.jar;D:\.my-m2\repository\org\openjfx\javafx-controls\24-ea+5\javafx-controls-24-ea+5.jar;D:\.my-m2\repository\org\openjfx\javafx-graphics\24-ea+5\javafx-graphics-24-ea+5-win.jar;D:\.my-m2\repository\org\openjfx\javafx-graphics\24-ea+5\javafx-graphics-24-ea+5.jar'}
[Sat Sep 14 09:08:21 PKT 2024][INFO] ==================== LINK TASK ====================
[Sat Sep 14 09:08:21 PKT 2024][FINE] Creating icon resource
[Sat Sep 14 09:08:21 PKT 2024][FINE] Looking for resource: /native/windows/assets/icon.ico
[Sat Sep 14 09:08:21 PKT 2024][FINE] Copied resource D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gensrc\windows\assets\icon.ico to D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gvm\tmp\icon\icon.ico
[Sat Sep 14 09:08:21 PKT 2024][INFO] Default icon.ico image generated in D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gensrc\windows\assets.
Consider copying it to D:\GraalVM-Projects\gluonhq\hello-gluon-ci\src\windows before performing any modification
[Sat Sep 14 09:08:21 PKT 2024][FINE] Looking for resource: /native/windows/assets/IconGroup.rc
[Sat Sep 14 09:08:21 PKT 2024][FINE] PB Command for rc compile: rc -fo D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gvm\tmp\icon\IconGroup.res D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gvm\tmp\icon\IconGroup.rc
[Sat Sep 14 09:08:21 PKT 2024][FINE] Start process rc compile...
[Sat Sep 14 09:08:21 PKT 2024][FINE] [SUB] Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
[Sat Sep 14 09:08:21 PKT 2024][FINE] [SUB]
[Sat Sep 14 09:08:21 PKT 2024][FINE] [SUB] Copyright (C) Microsoft Corporation.  All rights reserved.
[Sat Sep 14 09:08:21 PKT 2024][FINE] [SUB]
[Sat Sep 14 09:08:21 PKT 2024][FINE] [SUB]
[Sat Sep 14 09:08:21 PKT 2024][FINE] Result for rc compile: 0
[Sat Sep 14 09:08:21 PKT 2024][FINE] PB Command for cvtres: cvtres  /machine:x64 -out:D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gvm\tmp\icon\IconGroup.obj D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gvm\tmp\icon\IconGroup.res
[Sat Sep 14 09:08:21 PKT 2024][FINE] Start process cvtres...
[Sat Sep 14 09:08:21 PKT 2024][FINE] [SUB] Microsoft (R) Windows Resource To Object Converter Version 14.39.33523.0
[Sat Sep 14 09:08:22 PKT 2024][FINE] [SUB] Copyright (C) Microsoft Corporation.  All rights reserved.
[Sat Sep 14 09:08:22 PKT 2024][FINE] [SUB]
[Sat Sep 14 09:08:22 PKT 2024][FINE] Result for cvtres: 0
[Sat Sep 14 09:08:22 PKT 2024][FINE] IconGroup.obj created successfully
[Sat Sep 14 09:08:22 PKT 2024][FINE] Copied resource D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gvm\tmp\icon\IconGroup.obj to D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gvm\HelloGluon\IconGroup.obj
[Sat Sep 14 09:08:22 PKT 2024][FINE] Looking for resource: /native/windows/launcher.c
[Sat Sep 14 09:08:22 PKT 2024][FINE] PB Command for compile-additional-sources: cl -c -DGVM_VERBOSE -DSUBSTRATE /MD /D_UNICODE /DUNICODE /DWIN32 /D_WINDOWS -ID:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gvm\HelloGluon launcher.c
[Sat Sep 14 09:08:22 PKT 2024][FINE] Start process compile-additional-sources...
[Sat Sep 14 09:08:22 PKT 2024][FINE] [SUB] Microsoft (R) C/C++ Optimizing Compiler Version 19.39.33523 for x64
[Sat Sep 14 09:08:22 PKT 2024][FINE] [SUB] Copyright (C) Microsoft Corporation.  All rights reserved.
[Sat Sep 14 09:08:22 PKT 2024][FINE] [SUB]
[Sat Sep 14 09:08:22 PKT 2024][FINE] [SUB] launcher.c
[Sat Sep 14 09:08:22 PKT 2024][FINE] Result for compile-additional-sources: 0
[Sat Sep 14 09:08:22 PKT 2024][FINE] PB Command for link: link D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gvm\HelloGluon\launcher.obj D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gvm\tmp\SVM-1726286331870\com.gluonhq.hello.hellogluonapp.obj D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gvm\HelloGluon\IconGroup.obj vmone.lib /NODEFAULTLIB:libcmt.lib /SUBSYSTEM:WINDOWS /ENTRY:mainCRTStartup comdlg32.lib dwmapi.lib gdi32.lib imm32.lib shell32.lib uiautomationcore.lib urlmon.lib winmm.lib glass.lib javafx_font.lib javafx_iio.lib prism_common.lib prism_d3d.lib /WHOLEARCHIVE:glass.lib /WHOLEARCHIVE:javafx_font.lib /WHOLEARCHIVE:javafx_iio.lib /WHOLEARCHIVE:prism_common.lib /WHOLEARCHIVE:prism_d3d.lib /OUT:D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\HelloGluon.exe /LIBPATH:C:\Users\MSC-30\.gluon\substrate\javafxStaticSdk\24-ea+7.1\windows-x86_64\sdk\lib /LIBPATH:C:\Users\MSC-30\.gluon\substrate\javaStaticSdk\24-3\windows-x86_64\lib
[Sat Sep 14 09:08:22 PKT 2024][FINE] Start process link...
[Sat Sep 14 09:08:22 PKT 2024][INFO] [SUB] Microsoft (R) Incremental Linker Version 14.39.33523.0
[Sat Sep 14 09:08:22 PKT 2024][INFO] [SUB] Copyright (C) Microsoft Corporation.  All rights reserved.
[Sat Sep 14 09:08:22 PKT 2024][INFO] [SUB]
[Sat Sep 14 09:08:22 PKT 2024][INFO] [SUB] LINK : fatal error LNK1181: cannot open input file 'vmone.lib'
[Sat Sep 14 09:08:22 PKT 2024][FINE] Result for link: 1181
[Sat Sep 14 09:08:22 PKT 2024][SEVERE] Process link failed with result: 1181
Check the log files under D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gvm\log
And please check https://docs.gluonhq.com/ for more information.
[Sat Sep 14 09:08:22 PKT 2024][INFO] Logging process [link] to file: D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\log\process-link-1726286902499.log
[Sat Sep 14 09:08:22 PKT 2024][SEVERE] Linking failed.
Check the log files under D:\GraalVM-Projects\gluonhq\hello-gluon-ci\target\gluonfx\x86_64-windows\gvm\log
And please check https://docs.gluonhq.com/ for more information.
             _______  ___      __   __  _______  __    _
            |       ||   |    |  | |  ||       ||  |  | |
            |    ___||   |    |  | |  ||   _   ||   |_| |
            |   | __ |   |    |  |_|  ||  | |  ||       |
            |   ||  ||   |___ |       ||  |_|  ||  _    |
            |   |_| ||       ||       ||       || | |   |
            |_______||_______||_______||_______||_|  |__|

    Access to the latest docs, tips and tricks and more info on
    how to get support? Register your usage of Gluon Substrate now at

    https://gluonhq.com/activate



[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  7.813 s
[INFO] Finished at: 2024-09-14T09:08:24+05:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.gluonhq:gluonfx-maven-plugin:1.0.24-SNAPSHOT:link (default-cli) on project hellogluon: Linking failed -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

ctoabidmaqbool · 2024-09-14T06:01:42Z

Last time error just solved: gvm-24-4

Now main errors are happening, see error logs:

process-link-1726336424713.log

client-debug0.log

ctoabidmaqbool · 2024-09-14T06:13:55Z

@jperedadnr @johanvos @abhinayagarwal @credmond
Anyone, Please see my last logs, #1279 (comment)
Any help, how can I solve these issue!

ctoabidmaqbool · 2024-09-15T03:44:18Z

The instrusting thing is that using official gluon providing substrate and vmone in linux is still causing issues, maybe something went wrong at gluon side!

process-compile-1726375861304.log
process-link-1726375886148.log

client-debug0.log
client-debug0.1.log

jperedadnr · 2024-09-15T11:32:18Z

It seems you need to enable sw rendering (for the linux build).

As for the link issues on Windows:

If I run on macOS

% nm /path/to/libvmone.a | grep -i jni_onload
0000000000000000 T _JNI_OnLoad_java
0000000000000024 T _JNI_OnLoad_net
...

as those symbols are archived in libjdk.a:

% nm /path/to/libjdk.a | grep -i jni_onload
0000000000000000 T _JNI_OnLoad_java
0000000000000024 T _JNI_OnLoad_net
...

So you need to make sure that vmone.lib contains all the object files that come from libjdk.lib.

ctoabidmaqbool · 2024-09-17T06:02:02Z

@jperedadnr
On my local PC all is going well withot any issue, But I am not sure how can i solve the problem online e.g. Github Actions Windows Container, As there is no such D:\ drive online!

When I try, to see the content of libjdk.lib it's showing parts are absoute here, so extracted files will be gone to these dir too

maqboolstudiopc@MSC-30:/mnt/d/GraalVM-Projects/gluonhq/hello-gluon-ci/tmp$ ar t libjdk.lib
d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/AccessController.obj
d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/Array.obj
d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/BootLoader.obj
d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/CDS.obj
d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/Class.obj
d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/ClassLoader.obj
d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/Console_md.obj
d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/ConstantPool.obj
d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/Continuation.obj
d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/ContinuationSupport.obj
d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/Double.obj
d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/Executable.obj

in this case both ar or lib extract to abs path! I am not sure, why there is not ref path or just file in libjdk.a

any solution?

jperedadnr · 2024-09-17T08:52:30Z

Can you try

ar x --output <your_path> libjdk.lib

ctoabidmaqbool · 2024-09-17T09:11:02Z

find: ‘D:/a/mobile/mobile/build/windows-x64/support/native’: No such file or directory
if [ -s C:/temp/libjdk.lib ]; then \
	echo "Including C:/temp/libjdk.lib in lib"; \
	TMPDIR=lib/windows/temp_objs; \
	mkdir -p $TMPDIR; \
	ar t C:/temp/libjdk.lib | xargs -n 1 dirname | sort -u > dirlist.txt; \
	xargs mkdir -p < dirlist.txt; \
	(cd $TMPDIR && mkdir -p temp && ar x --output temp C:/temp/libjdk.lib); ls temp; \
	ar rcs lib/windows/staticjdk/lib/vmone.lib  build/windows/codeSynchronization.o build/windows/cpuid.o build/windows/cSunMiscSignal.o build/windows/debug.o build/windows/dummy.o build/windows/exitWithMessage.o build/windows/getEnviron.o build/windows/getThreadId.o build/windows/getThreadUserTime.o build/windows/jio.o build/windows/JvmFuncs.o build/windows/macrosAsFunctions.o build/windows/svmTimeZone.o build/windows/varargs_helper.o; \
else \
	echo "Existing library not found. Creating static library with object files only."; \
	ar rcs lib/windows/staticjdk/lib/vmone.lib build/windows/codeSynchronization.o build/windows/cpuid.o build/windows/cSunMiscSignal.o build/windows/debug.o build/windows/dummy.o build/windows/exitWithMessage.o build/windows/getEnviron.o build/windows/getThreadId.o build/windows/getThreadUserTime.o build/windows/jio.o build/windows/JvmFuncs.o build/windows/macrosAsFunctions.o build/windows/svmTimeZone.o build/windows/varargs_helper.o; \
fi
Including C:/temp/libjdk.lib in lib
temp/d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/AccessController.obj: No such file or directory
ls: cannot access 'temp': No such file or directory

@jperedadnr same issue!
https://github.com/ctoabidmaqbool/vmone-fork/actions/runs/10899946312/job/30246486181

ctoabidmaqbool · 2024-09-17T09:14:00Z

temp/d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/AccessController.obj: No such file or directory

main issues,

ar x --output temp libjdk.lib
temp/d:/a/mobile/mobile/build/windows-x64/support/native/java.base/libjava/static/AccessController.obj: No such file or directory

I try almost any possibility using ar or lib but same issue, but on my local pc however i have solve the problem as there is d drive and nested folder i can make easily!

ctoabidmaqbool · 2024-09-17T09:41:31Z

https://github.com/gluonhq/mobile/releases/tag/gvm-24-1
I think, the simple solution is re-create tag with window .lib with reference path not d:/ one

I alrey have tried, lib.exe way too
https://gist.github.com/gaspardpetit/b37d52321a160879e2759e2db87bfd92

ctoabidmaqbool · 2024-09-17T16:38:56Z

Online at github actions runner (windows container) I am unable to build the vmone.lib, I have metioned the issue above!

I am able to build the lib vmone.lib locally.
Just replace the lib at C:\Users\{user}\.gluon\substrate\javaStaticSdk\24-4\windows-x86_64\lib after downloading by gluon maven plugin.

Now I have run the program, but more and more errors are happening let see the logs:

process-link-1726632991547.log
client-debug0.log

abhinayagarwal · 2024-09-18T08:23:11Z

Hi,

Thank you for all the inputs. I have opened #1284 and #1285 to further discuss the progress on supporting Windows and Linux Aarch64.

For now I am going to merge this PR and we can continue discussing the same on the individual issues.

ctoabidmaqbool · 2024-09-18T08:34:42Z

@abhinayagarwal You are going to close this issue!
But what about my inputs here!

abhinayagarwal · 2024-09-18T08:37:40Z

@abhinayagarwal You are going to close this issue!

I created an issue to continue the discussion on the correct channel. The comments on the PR will always be available to build things on top of all the work you have already achieved.

Add warnings on Windows and Linux AArch64

465ca9d

jperedadnr requested review from johanvos and abhinayagarwal September 9, 2024 08:34

abhinayagarwal reviewed Sep 9, 2024

View reviewed changes

src/main/java/com/gluonhq/substrate/target/LinuxTargetConfiguration.java Outdated Show resolved Hide resolved

address feedback

a5bdb55

abhinayagarwal reviewed Sep 9, 2024

View reviewed changes

src/main/java/com/gluonhq/substrate/target/WindowsTargetConfiguration.java Outdated Show resolved Hide resolved

Address feedback

a9e04a8

johanvos approved these changes Sep 10, 2024

View reviewed changes

abhinayagarwal merged commit 33adb7a into gluonhq:master Sep 18, 2024
2 checks passed

ctoabidmaqbool mentioned this pull request Sep 18, 2024

Add support for Windows #1284

Open

ctoabidmaqbool mentioned this pull request Sep 18, 2024

Trying to do Windows Implementation of Vmone gluonhq/vmone#7

Open

ctoabidmaqbool mentioned this pull request Oct 5, 2024

Where is vmone relase for windows? gluonhq/vmone#5

Open

Add warnings on Windows and Linux AArch64 #1279

Add warnings on Windows and Linux AArch64 #1279

Conversation

jperedadnr commented Sep 9, 2024

ctoabidmaqbool commented Sep 9, 2024

Hugolarson commented Sep 9, 2024

credmond commented Sep 10, 2024

abhinayagarwal commented Sep 10, 2024

credmond commented Sep 10, 2024 • edited Loading

ctoabidmaqbool commented Sep 10, 2024

johanvos commented Sep 10, 2024

johanvos commented Sep 10, 2024

credmond commented Sep 10, 2024

ctoabidmaqbool commented Sep 10, 2024 • edited Loading

johanvos commented Sep 10, 2024

johanvos left a comment

Choose a reason for hiding this comment

ctoabidmaqbool commented Sep 10, 2024

johanvos commented Sep 10, 2024

ctoabidmaqbool commented Sep 10, 2024

credmond commented Sep 10, 2024

ctoabidmaqbool commented Sep 11, 2024

jperedadnr commented Sep 11, 2024

ctoabidmaqbool commented Sep 11, 2024

ctoabidmaqbool commented Sep 11, 2024

credmond commented Sep 11, 2024

ctoabidmaqbool commented Sep 12, 2024

ctoabidmaqbool commented Sep 13, 2024

ctoabidmaqbool commented Sep 13, 2024 • edited Loading

credmond commented Sep 13, 2024

credmond commented Sep 13, 2024

jperedadnr commented Sep 13, 2024

ctoabidmaqbool commented Sep 13, 2024

ctoabidmaqbool commented Sep 13, 2024

ctoabidmaqbool commented Sep 14, 2024

ctoabidmaqbool commented Sep 14, 2024

ctoabidmaqbool commented Sep 15, 2024

jperedadnr commented Sep 15, 2024 • edited Loading

ctoabidmaqbool commented Sep 17, 2024

jperedadnr commented Sep 17, 2024 • edited Loading

ctoabidmaqbool commented Sep 17, 2024

ctoabidmaqbool commented Sep 17, 2024 • edited Loading

ctoabidmaqbool commented Sep 17, 2024

ctoabidmaqbool commented Sep 17, 2024

abhinayagarwal commented Sep 18, 2024

ctoabidmaqbool commented Sep 18, 2024

abhinayagarwal commented Sep 18, 2024

credmond commented Sep 10, 2024 •

edited

Loading

ctoabidmaqbool commented Sep 10, 2024 •

edited

Loading

ctoabidmaqbool commented Sep 13, 2024 •

edited

Loading

jperedadnr commented Sep 15, 2024 •

edited

Loading

jperedadnr commented Sep 17, 2024 •

edited

Loading

ctoabidmaqbool commented Sep 17, 2024 •

edited

Loading