Add 32bit ARM armel & armhf GNU/Linux support #3196

xranby · 2015-06-09T13:45:19Z

The following cross compile packages needs to be installed on the build server:
gcc-arm-linux-gnueabi
g++-arm-linux-gnueabi
gcc-arm-linux-gnueabihf
g++-arm-linux-gnueabihf

JDK 8 ARM systems will try to load:
libgdxarmgnueabi.so -> 32bit ARM GNU softfp EABI
libgdxarmgnueabihf.so -> 32bit ARM GNU hard float EABI

JDK 6/7 ARM systems will try to load:
libgdxarm.so -> 32bit ARM unknown ABI.
We will use the gnueabihf compiler for JDK systems with unknown ABI.

Signed-off-by: Xerxes Rånby xerxes@gudinna.com


        Add 32bit ARM armel & armhf GNU/Linux support

The following cross compile packages needs to be installed on the build server: gcc-arm-linux-gnueabi g++-arm-linux-gnueabi gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf JDK 8 ARM systems will try to load: lib*armgnueabi.so -> 32bit ARM GNU softfp EABI lib*armgnueabihf.so -> 32bit ARM GNU hard float EABI JDK 6/7 ARM systems will try to load: lib*arm.so -> 32bit ARM unknown ABI. We will use the gnueabihf compiler for JDK systems with unknown ABI. Signed-off-by: Xerxes Rånby <xerxes@gudinna.com>

badlogic · 2015-06-09T13:50:56Z

How does the library loader know to load these? Also, we'll need to change
jnigen to emit these linux arm build files.

On Tue, Jun 9, 2015 at 3:45 PM, Xerxes Rånby notifications@github.com
wrote:

The following cross compile packages needs to be installed on the build
server:
gcc-arm-linux-gnueabi
g++-arm-linux-gnueabi
gcc-arm-linux-gnueabihf
g++-arm-linux-gnueabihf

JDK 8 ARM systems will try to load:
lib
_armgnueabi.so -> 32bit ARM GNU softfp EABI lib_armgnueabihf.so -> 32bit
ARM GNU hard float EABI

JDK 6/7 ARM systems will try to load:
lib*arm.so -> 32bit ARM unknown ABI.
We will use the gnueabihf compiler for JDK systems with unknown ABI.

Signed-off-by: Xerxes Rånby xerxes@gudinna.com

You can view, comment on, or merge this pull request online at:

#3196
Commit Summary

Add 32bit ARM armel & armhf GNU/Linux support

File Changes

A gdx/jni/build-linux32-arm.xml
https://github.com/libgdx/libgdx/pull/3196/files#diff-0 (144)

A gdx/jni/build-linux32-armgnueabi.xml
https://github.com/libgdx/libgdx/pull/3196/files#diff-1 (144)

A gdx/jni/build-linux32-armgnueabihf.xml
https://github.com/libgdx/libgdx/pull/3196/files#diff-2 (144)

M gdx/jni/build.xml
https://github.com/libgdx/libgdx/pull/3196/files#diff-3 (9)

Patch Links:

https://github.com/libgdx/libgdx/pull/3196.patch

https://github.com/libgdx/libgdx/pull/3196.diff

—
Reply to this email directly or view it on GitHub
#3196.

xranby · 2015-06-09T13:54:42Z

The library loader was patched about a year ago to support this:
8f83f0f

Raspberry Pi users have verified that the loader work:
https://web.archive.org/web/20150519135633/http://www.habitualcoder.com/?page_id=257


        Add JDK 8 ABI detection to ARM GNU/Linux jnigen shared library loading.

JDK 8 ARM systems will try to load: lib*armgnueabi.so -> 32bit ARM GNU softfp EABI lib*armgnueabihf.so -> 32bit ARM GNU hard float EABI lib*armandroideabi.so -> 32bit Android EABI JDK 6/7 ARM systems will try to load: lib*arm.so -> 32bit ARM unknown ABI. Signed-off-by: Xerxes Rånby <xerxes@gudinna.com>

xranby · 2015-06-09T14:36:02Z

Added a commit to update
extensions/gdx-jnigen/src/com/badlogic/gdx/jnigen/JniGenSharedLibraryLoader.java
is there other parts of jnigen that needs to be updated?

badlogic · 2015-06-09T14:37:07Z

Yeah, AntBuildScriptGenerator and all *Build.java files that generate
native libs for various extensions.
On Jun 9, 2015 4:36 PM, "Xerxes Rånby" notifications@github.com wrote:

Added a commit to update

extensions/gdx-jnigen/src/com/badlogic/gdx/jnigen/JniGenSharedLibraryLoader.java
is there other parts of jnigen that needs to be updated?

—
Reply to this email directly or view it on GitHub
#3196 (comment).

xranby · 2015-06-09T15:39:42Z

I will refactor jnigen to support 32bit ARM GNU/Linux systems

In the long run it would be best to differentiate all native library’s using
os, arch & abi

os is currently encoded in the libPrefix and libSuffix
arch is not encoded at all in the native names
abi is currently partially encoded in the 64 bit part of the libSuffix.

During this initial bring-up I will add support 32bit ARM GNU/Linux systems by extending linux32 systems from using
libPrefix + sharedLibName + libSuffix;
to
libPrefix + sharedLibName + arch + abi + libSuffix;

nhydock · 2015-06-11T02:35:33Z

How is this different from what #2940 is trying to do?

xranby · 2015-06-13T01:27:41Z

My initial change here make the libgdx build servers provide pre-compiled libgdx .so integrated into the gdx-platform- -natives-desktop.jar for easy use by gradle project users. This also would fix the #3188 enhancement

It is neat, that Robbiedobbie #2940 have patched jnigen! this means that I dont have to do it as well ^_^

Both I and Robbiedobbi #2940 aim to support ARM GNU/Linux systems by picking/inventing a namespace to use for native librarys

the core difference is that I aim to handle the differences in abi variants as well.
The two works have overlap in:
extensions/gdx-jnigen/src/com/badlogic/gdx/jnigen/JniGenSharedLibraryLoader.java

Robbiedobbie #2940 only to support unknown abi 32bit arm and unknown abi 64bit arm.
I feel this is an unessecery invented new namespace that do not cover the namespaces used to differentiate native librarys by the distributions.

I aim to support the 3 versions of 32bit ARM and 1 version of 64bit ARM using the abi names provided by the jvm if available. This would fix the #3188 enhancement that require differentiate natives using the abi. I think the approach to reuse the abi namespace used by the distribution toolchains will be more robust (handled by the jvm instead of manual labor by the libgdx team), it all depends if the new sun.arch.abi system property introduced in jdk 8 will be enforced by the linux distributions.

xoppa · 2015-08-18T19:55:10Z

Thanks @xranby, I've pulled in @Robbiedobbie jnigen PR. Can you pull in changes and solve conflicts for the loader?

RBogie · 2015-08-19T10:17:14Z

I think you should use your loader, and can then use my buildscript generator. One thing that you should adapt is the SharedLibraryFinder. In your commits, you forgot to add support to it for finding arm libraries. I changed it in my commits, but mine doesn't support the multiple ABIs.

I do think it is a big improvement supporting different ABIs. I simply did not include it for time reasons. It was much simpler assuming that the program would only be run on a single arm platform on linux. Finding out how to detect the abi was way too much work for me considering the time constraints I had. (I needed it for some small hobby project that I had to do in the very little spare time I have 😉)


        Merge remote-tracking branch 'libgdx/master' into HEAD

Conflicts: extensions/gdx-jnigen/src/com/badlogic/gdx/jnigen/JniGenSharedLibraryLoader.java

xranby · 2015-08-23T21:43:08Z

I resolved the conflict in JniGenSharedLibraryLoader by using the loader that supports different ABI's.

I have kept Robbiedobbie's implementation of the SharedLibraryFinder interface for now mainly because there is no code using this interface inside the libgdx main source tree.
Robbiedobbie: can you elaborate when it is useful to use the SharedLibraryFinder interface to override the way of searching for a library on each platform?
I have searched github and I cant find any source currently using it
https://github.com/search?q=implements+SharedLibraryFinder&ref=searchresults&type=Code&utf8=%E2%9C%93

johnnyapol · 2015-08-25T23:15:46Z

Regardless of the way it is implemented - I can't personally validate this PR because of my absence from this project. I feel this is something that should definitely be supported. A friend of mine lent me his Raspberry Pi 2 a few days ago so I could tool around with coding on it and I am now awaiting for my own to come. I think that it is a market certainly reachable for indie developers. The more platforms we can easily support, the better. In this case we just need additional native libraries and a modified loader.


        Merge add 32bit ARM armel & armhf GNU/Linux support into jogamp-2.3.2…

…-libgdx-1.7.1 libgdx#3196

littletinman · 2016-01-05T17:40:25Z

Any updates on this? Would absolutely love Raspi support as it's the perfect platform to bring places for people to try my games/apps. Literally being able to plug it into a tv, attach a keyboard, and show my friends my latest project would be golden!

If there is anyway I can help with this, please let me know! I have a Rasp a+, b+, and 2 as well as another arm based netbook.

natdan · 2016-01-21T16:08:32Z

+1 it would really help having it in a main stream LibGDX.

littletinman · 2016-01-22T19:09:58Z

This merge request has been open for 227 days... any reason it's not merging in? ARM support is my TOP LibGDX feature hope for 2016!

If there was a step by step tutorial for building our own natives, that would be awesome! But I have not found anything beyond general suggestions to date.

badlogic · 2016-01-23T11:03:09Z

@littletinman the reason this is still open is that it's a bad way to solve this issue. jnigen, the thing that creates bindings and build scripts for cross-platform builds, needs to be changed. All this PR does is add additional ant scripts manually, and only to the gdx core native project.

badlogic · 2016-01-23T11:07:39Z

Also needs to be integrated on the Maven side of things.

xranby · 2016-01-23T16:49:23Z

jnigen have already been patched for ARM by the #2940 pull request

All the libgdx Maven pom's do is to download the pre-compiled
https://libgdx.badlogicgames.com/nightlies/dist/gdx-natives.jar
jar and use it. Therefore once this gdx-natives.jar have been created by the build server using the ant scripts makes it all integrated on the maven side!

badlogic · 2016-01-24T08:33:40Z

#2940 did NOT patch jnigen properly. It ignores ABI as you want it. Also, GdxBuild.java, FreeTypeBuild.java, BulletBuild.java and Box2DBuild.java also need to be fixed up to emit the additional Ant scripts. Finally, the master Ant script of each native build needs to include the additional shared libraries for ARM Linux in the *-natives-desktop.jar. So again, this PR is not even close to fixing the underlying issue.

I've just looked into what it'd take to fix up JNIGen properly, and it's quite an amount of work. I currently do not have the time to spend on this, nor do i have any test devices (save for QEMU) to test this on. I welcome any proper PR that fixes this issue by:

Not breaking existing "user space" code
Not introducing Ant scripts manually into the build

I'll be happy to have this build and deployed to Central from our build server, even with the additional overhead for the ARM libraries.

entangledloops · 2016-02-19T20:19:16Z

I've written 2 jni build files for armgnueabihf: 1 for libgdx and 1 for libgdx-freetype.

Download these files and place in their respective jni subfolders.
Remove the prefixes "freetype-" and "gdx-" and change extension to xml.
From each jni folder, run: ant -f build-armgnueabihf.xml
Resulting libs produced in libs/armgnueabihf
freetype-build-armgnueabihf.txt
gdx-build-armgnueabihf.txt

Note:
These builds are tuned for arm v7a. You can change those build settings if you are using different hardware without breaking the script.

badlogic · 2016-02-20T00:47:57Z

I'm closing this out now. 3rd parties have the option to build, maintain, and publish their own artifacts that include the natives. I'm happy to make modifications to SharedLibraryLoader as necessary, unless it breaks existing user code.

I hope I've explained why this PR is insufficient in my previous comments. I'm happy to merge (tested) PRs that accomodate the requirements outlined in my previous comments.

xranby mentioned this pull request Jun 11, 2015

headless backend on raspberry pi [enhancement] #3188

Closed

xranby force-pushed the xranby:master branch 2 times, most recently from 5b4eade to dbb3a55 Aug 21, 2015

Merge remote-tracking branch 'libgdx/master' into HEAD

e4f9a1e

Conflicts: extensions/gdx-jnigen/src/com/badlogic/gdx/jnigen/JniGenSharedLibraryLoader.java

xranby added a commit to xranby/libgdx that referenced this pull request Nov 2, 2015

Merge add 32bit ARM armel & armhf GNU/Linux support into jogamp-2.3.2…

e79fb68

…-libgdx-1.7.1 libgdx#3196

badlogic closed this Feb 20, 2016

natdan mentioned this pull request Jan 28, 2017

ARM/RPI Support for GDX Headless #4571

Open

1 of 7 tasks complete

libgdx / libgdx

Add 32bit ARM armel & armhf GNU/Linux support #3196

Add 32bit ARM armel & armhf GNU/Linux support #3196

xranby commented Jun 9, 2015

badlogic commented Jun 9, 2015

Signed-off-by: Xerxes Rånby xerxes@gudinna.com

xranby commented Jun 9, 2015

xranby commented Jun 9, 2015

badlogic commented Jun 9, 2015

xranby commented Jun 9, 2015

nhydock commented Jun 11, 2015

xranby commented Jun 13, 2015

xoppa commented Aug 18, 2015

RBogie commented Aug 19, 2015

xranby commented Aug 23, 2015

johnnyapol commented Aug 25, 2015

littletinman commented Jan 5, 2016

natdan commented Jan 21, 2016

littletinman commented Jan 22, 2016

badlogic commented Jan 23, 2016

badlogic commented Jan 23, 2016

xranby commented Jan 23, 2016

badlogic commented Jan 24, 2016

entangledloops commented Feb 19, 2016

badlogic commented Feb 20, 2016

libgdx / libgdx

Sponsor libgdx/libgdx

Join GitHub today

Add 32bit ARM armel & armhf GNU/Linux support #3196

Add 32bit ARM armel & armhf GNU/Linux support #3196

Conversation

xranby commented Jun 9, 2015

badlogic commented Jun 9, 2015

Signed-off-by: Xerxes Rånby xerxes@gudinna.com

xranby commented Jun 9, 2015

xranby commented Jun 9, 2015

badlogic commented Jun 9, 2015

xranby commented Jun 9, 2015

nhydock commented Jun 11, 2015

xranby commented Jun 13, 2015

xoppa commented Aug 18, 2015

RBogie commented Aug 19, 2015

xranby commented Aug 23, 2015

johnnyapol commented Aug 25, 2015

littletinman commented Jan 5, 2016

natdan commented Jan 21, 2016

littletinman commented Jan 22, 2016

badlogic commented Jan 23, 2016

badlogic commented Jan 23, 2016

xranby commented Jan 23, 2016

badlogic commented Jan 24, 2016

entangledloops commented Feb 19, 2016

badlogic commented Feb 20, 2016