gdx-backend-lwjgl3 references natives that cannot be found or do not exist, causes build to fail #6878
Comments
|
https://repo1.maven.org/maven2/org/lwjgl/lwjgl-glfw/3.3.1/ |
|
This happens to me a lot; I usually just remove |
I did realize that and thought it was strange, but dismissed it since I haven't touched my repositories :^| repositories {
mavenLocal()
mavenCentral()
google()
gradlePluginPortal()
maven { url "https://oss.sonatype.org/content/repositories/snapshots/" }
maven { url "https://oss.sonatype.org/content/repositories/releases/" }
maven { url "https://jitpack.io" }
}Also yes, I am aware that lwjgl-glfw is acessible through maven central (that's where I'm getting it from in the "fix" after all), however the version of lwjgl-glfw on maven central (or wherever my local repo got it from, I guess) does not contain the classifier "natives-linux-arm64", "natives-macos", etc. It does however contain "natives-linux" and "natives-linux-arm32" which is all I need for running it on my system. I call it a "classifier" because that's how it's defined in the pom for gdx-backend-lwjgl3 but I really have no idea what it does other than that it's equivalent to <dependency>
<groupId>org.lwjgl</groupId>
<artifactId>lwjgl</artifactId>
<version>3.3.1</version>
<classifier>natives-linux</classifier>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.lwjgl</groupId>
<artifactId>lwjgl</artifactId>
<version>3.3.1</version>
<classifier>natives-linux-arm32</classifier>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.lwjgl</groupId>
<artifactId>lwjgl</artifactId>
<version>3.3.1</version>
<classifier>natives-linux-arm64</classifier>
<scope>compile</scope>
</dependency> |
This worked! How strange that Gradle doesn't even bother to look elsewhere if it cant find your dependency in the local repository, but only sometimes. I still don't really consider this a fix but someone else can close the issue if they feel like this is a gradle-related hangup and not a problem with gdx-backend-lwjgl3. |
|
These dependencies are added using classifier notation, you are just seeing the "expanded" version that shows you it raw. This is probably not Gradle, but Gradle plugin for IDEA that is not resolving this properly. Running from command line, gradle is probably quite happy. |
|
The only thing that is being changed here is the build.gradle, it's clearly an issue with Gradle as it's Gradle's sole responsibility to resolve those dependencies afaik |
|
No its not, IDEA plugin is integrating Gradle into the IDE tooling system. Its in the stacktrace you posted. Run your project from command line outside of IDEA, if it truly is a Gradle problem, you will get the same failure, but with a different stacktrace because obviously IDEA plugins do not exist there. A simple |
The IDEA plugin is clearly just wrapping gradle functionality and passing along the exceptions, e.g. Again, this only happens when mavenLocal() is included (for some reason). It can either be "fixed" using my hack above or by just omitting mavenLocal(). Presumably, and this is just speculation, Gradle is sucessfully finding natives for the current system (linux makes sense here, linux-arm32 is clearly an exception to this theory) in mavenLocal() and then attempting to find the rest of the natives ONLY in mavenLocal(), since they are all in the same package but different classifiers. This issue has mostly resolved itself: if you dont need mavenLocal() then omit it. If you need mavenLocal(), use the hack above or maybe try installing the natives to your local maven repo if you can find them. However, it's just strange that this is a problem to begin with |
|
Here it is with the --stacktrace option, for your viewing pleasure. |
|
Good to isolate it to Gradle. Are you running on arm32? did you manually build lwjgl natives on your system? Do you have any lwjgl maven artifacts in your maven local repo, if so what are they? Because that should be the only reason mavenLocal would be populated with only those natives. Your idea makes sense as a possible cause, depending on your contents of maven local. If that is the case, where you have the arm32 modules, but none of the other, then that is 100% the reason for this, and this is part of the Gradle specification to behave as it is. Worth noting that that this is not a new issue, been happening in Gradle for 9+years, changing the order of the repositories should also 'fix' it. I have seen many threads address this, and the other repos have also been known to cause this exact failure, jcenter and google in combination with plugins. For us, we should just remove it, since only people that gain anything from it are people building from source, in which case they can add it. But its still an interesting problem to see where exactly this is being. |
|
Q: Are you running on arm32? Q: Did you manually build lwjgl natives on your system? Q: Do you have any lwjgl maven artifacts in your maven local repo? I also did some digging around and found
Moving mavenLocal() to the end of the list does actually 'fix' it. God I love Gradle. |
|
Yeah, so thats it. MavenLocal is searched first, finds a result so chooses that repository for that module. All other repositories are ignored for trying to find artifacts of that module, and then it fails because the other artifacts are not in mavenLocal (as you've shown). This part apparently isn't a bug, this behaviour is as described in their docs. So if we can accept that, then the real bug, is how come there is a partial result of artifacts in mavenLocal. :S
|
|
Oh, @WasabiThumb have you used pure maven with this same version? Like a project managed by maven bringing in deps of 3.3.1? If you did, and had <dependency>
<groupId>org.lwjgl</groupId>
<artifactId>lwjgl</artifactId>
<version>3.3.1</version>
<classifier>natives-linux</classifier>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.lwjgl</groupId>
<artifactId>lwjgl</artifactId>
<version>3.3.1</version>
<classifier>natives-linux-arm32</classifier>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.lwjgl</groupId>
<artifactId>lwjgl</artifactId>
<version>3.3.1</version>
<classifier>natives-linux-arm64</classifier>
<scope>compile</scope>
</dependency>only, then it all makes sense. |
|
For me to remove
fixed the issue |
|
Since this isn't a bug within libGDX, but rather a (usage) problem with Gradle, I'm closing this for now. |
Issue details
In a new project created with the provided tool and imported with IntelliJ IDEA, with a project SDK of 18 and running on Linux, trying to run or build the project fails as gradle cannot locate "natives-linux-arm64" for lwjgl-glfw, lwjgl-openal, lwjgl-opengl, lwjgl-stb and lwjgl.
Version of libGDX and/or relevant dependencies
Stacktrace
Without fix:
See full paste here
With "fix":
Runs fine, however:
Please select the affected platforms
The "fix":
This is not at all ideal, and essentially just excludes lwjgl, lwjgl-glfw etc. from gdx-backend-lwjgl3 and replaces it with all the same stuff except excluding the natives that cause trouble. I've commented out the windows and mac natives, because for some reason they cannot be found on my Linux machine similarly to the Linux ARM64 natives that originally caused this problem (which are also commented out). This is a problem because it will produce a binary that's not actually cross-platform, however it at least runs and I can continue development. The list of natives is based on the pom.xml file for gdx-backend-lwjgl3.
Compare to this version given by the project creation tool, which "causes" the error described:
The text was updated successfully, but these errors were encountered: