libgdx
Lower GLIBC requirements by using building linux natives on ubuntu 18.04 docker
alternative https://github.com/libgdx/Jamepad/pull/22 closes https://github.com/libgdx/Jamepad/issues/30
@theofficialgman hi, just curious does the github action build still work on your side? I had recently problems on my end so I checked out your changes but still it doesn't seem to succeed building the Linux binaries. Here is a test fork of my project
https://github.com/streamingdv/Jamepad/
Are you encountering the same issues in your fork branches? It seems the docker branch fixes the strange issue "Unable to locate package linux-libc-dev:i386" which seems to be occurring recently but fails now at run make -j make not found. E.g.
https://github.com/streamingdv/Jamepad/actions/runs/6625468273/job/17996650912
@theofficialgman okay fixed it, I think something has changed in the docker build image
https://github.com/streamingdv/Jamepad/commit/c077df9371fbd876e2e1db47b1e8d8db07013c99
Fails now on the Gradle task...
@theofficialgman okay fixed it, I think something has changed in the docker build image
Fails now on the Gradle task...
link:
[exec] g++: error: /__/__w/Jamepad/Jamepad/SDL/build-linux32/build/.libs/libSDL2.a: No such file or directory
yeah strange. this is happening in jamepad master branch as well. I can reproduce on my x86_64 computer locally as well. there is no libSDL2.a produced by the make command.
this is strange as nothing has changed at all that I can see.
maybe gradle was previously able to use these files instead
│ ├── libSDL2.la
│ ├── libSDL2main.la
│ ├── libSDL2_test.la
Yeah I saw that, It's super strange, the make command passes now but the necessary output files weren't build. Nothing changed and I'm not sure what is causing that problem all of a sudden.
I did not yet check on a real machine, does these files maybe get outputted to a different location than previously expected?
@theofficialgman for testing purposes I just reverted the build action file to the original and disabled all Linux builds in it (only Windows x64/x86 enabled) and it seems that is working. (I removed the linux-libc-dev:i386 dependency as well)
https://github.com/streamingdv/Jamepad/blob/master/.github/workflows/pushaction.yml
So something different when make is building the Linux stuff. Not sure if it only affects Linux x86 maybe? Windows binaries can be successfully produced
https://github.com/streamingdv/Jamepad/actions/runs/6629530789
ok too me many hours but I finally realized what the actual issue is @streamingdv
[exec] g++: error: /__/__w/Jamepad/Jamepad/SDL/build-linux64/build/.libs/libSDL2.a: No such file or directory
the issue is the /__ the beginning of the filepath.... it was never to do with the SDL2 build itself. the issue lies with gradle
@MrStahlfelge I have spent most of my day trying to bug test your CIs issue with the incorrect filepath issue. This has no relation to this PR as it happens on the master branch as well.
This PR is good for merging, I will leave it up to you to fix your CI
Probably the fix is already suggested in #21
Nope. Read again. We have no issues installing dependencies.
Issue is during linking https://github.com/libgdx/Jamepad/pull/23#issuecomment-1783585903
As I said. Fix your scripts as is (they don't work) and then you can come back to merging PRs.
@MrStahlfelge build failing in same place https://github.com/theofficialgman/Jamepad/actions/runs/6936137715/job/18867810888#step:39:71
@theofficialgman I'm still not 100% sure what is causing the issue but I had this problem as well in my fork when I used your action script to build inside a docker container. If you are building the lib normally (without using a container) it will work and you will not run into this problem.
still same linker error https://github.com/theofficialgman/Jamepad/actions/runs/8681588836/job/23804515917#step:39:74
The issue seems to be in jni/build-linux32.xml at line 47 (it's also in build-linux64.xml and the build-windows xmls as well)
<property name="libraries" value="-L/__w/Jamepad/Jamepad/SDL/lib /__/__w/Jamepad/Jamepad/SDL/build-linux32/build/.libs/libSDL2.a -lm -ldl -lpthread"/>
I don't know how/where these xmls are generated but I'm assuming that would be the cause.
I think I found the cause. It seems to be the replaceAll operations in the build.gradle. You can verify this by printing result of getSdl2StaticLibs without and with the replaceall.absolutePath and comparing the outputs.
For Linux x32, for example:
println getSdl2StaticLibs('./SDL/build-linux32/') :
-L/__w/Jamepad/Jamepad/SDL/lib /__w/Jamepad/Jamepad/SDL/lib/libSDL2.a -lm -ldl -lpthread
println getSdl2StaticLibs('./SDL/build-linux32/').replaceAll("[a-zA-Z0-9\\.\\-/]+libSDL2.a", file("SDL/build-linux32/build/.libs/libSDL2.a").absolutePath) :
-L/__w/Jamepad/Jamepad/SDL/lib /__/__w/Jamepad/Jamepad/SDL/build-linux32/build/.libs/libSDL2.a -lm -ldl -lpthread
Looks like the issue is that the underscore character is missing from the regex and therefore is not being matched and replaced. I'll create an issue for this.