Community
Participate
Working Groups
Raspberry Pi has been tremendous success as low cost computing platform, volume-wise and interest-wise. It is already being used in home automation and other embedded applications, both in DIY and professional sense , http://bit.ly/10LCU43. Most common Linux version on RaspPi is Debian is "wheezy:" with hardware FP, http://www.raspberrypi.org/downloads Oracle has pre-release version of Java 8 SE Embedded for Raspberry Pi available, https://blogs.oracle.com/java/entry/developer_preview_of_java_se, using hardware FP. It would be good to have an easy way to export an Equinox based OSGi application for Raspberry Pi with a native launcher for several reasons: - make it easy to use OSGi in embedded applications on RaspPi for both DIY and professional - make it "easiest" to use OSGi from the start for all "new" programmers that bought an RaspPi - make Eclipse the "platform of choice" for doing RaspPi, both for OSGi/Java based, but also Lua based tools - many more... I'm no expert but it looks like compiling the Linux launcher for ARM architecture, plus a few tweaks. Of course it would also require adding Raspberry Pi to Eclipse Bugzilla as platform, debian as OS and other admin stuff. But it would be cool if Eclipse was tool set of choice for this.
Hey Maarten
Created attachment 230236 [details] Patch for SWT binaries
Created attachment 230238 [details] Patch for eclipse-platform-parent (environment configuration)
Created attachment 230239 [details] Patch for eclipse-platform-parent (environment configuration)
Created attachment 230240 [details] Patch for eclipse-platform-parent and rcp.config
Created attachment 230241 [details] Arm inclusion in org.eclipse.e4.rcp feature.
Created attachment 230242 [details] Arm enablement (commented out) in org.eclipse.e4.rcp feature
Created attachment 230243 [details] Binary arm folder in rt.equinox.binaries
Created attachment 230244 [details] Arm launchers enablement (commented out) for rt.equinox.framework
Created attachment 230245 [details] Arm launchers enablement (commented out) for e4.rcp feature
Created attachment 230246 [details] Root properties (commented out) for tycho/rcp build.properties
*** Bug 391879 has been marked as a duplicate of this bug. ***
Ok, here is the list of patches that were applied to Fedora ARM build (of course they are uncommented). I commented some bits in order to avoid interaction with current CBI build. My patches don't contain any binaries. One is supposed to build them using CBI native build http://wiki.eclipse.org/Platform-releng/Platform_Build#Building_natives.
Nice blog post with how to DIY this: http://torkild.resheim.no/2013/05/running-eclipse-rcp-applications-on.html
Nice. Looks pretty familiar :-) Note that ARM instruction sets are different so i.e. ARMv9 binaries are not compatible with ARMv7. The other way around may be true though. So one would probably need different bundles for each architecture.
I'm having another stab at this as I want to build a custom version of PiPlug [1] with support for small screens. I'm also building on top of Luna, which means I probably have to do a few adjustments. Anyways, I'm looking through these patches in case I missed something in my blog post [2]. One difference I find is the architecture name. Should we not be using what "uname -a" returns? Which is "armv6l". Simply using "arm" would be quite ambiguous. [1] https://github.com/Genuitec/piplug [2] http://torkild.resheim.no/2013/05/running-eclipse-rcp-applications-on.html
Todd, as per comment 14: arm processor instruction sets differ, and they are not compatible. We were using in fedora generic arm* because we were guarded by the distro and had proper builders. If you are preparing your binaries to be freely distributable, then building for specific arm versions would be more appropriate.
Todd, to make the question more direct: Do you want to have arm launcher fragment that you can easily build from git or you want to have actual native executable to be downloadable from eclipse.org? The former is feasible and I would go for simple "arm" and whoever needs binaries builds them no matter it's armv5, armv6, armv7 or any of their subvariants. The later would be way harder as we would need fragments for each of them , builders for each of them would have to be setup and maintained by existing committer for rebuilds and I have concerns about general usability of such builds through various distributions.
I'm building for "armv6l" as I specifically need support for Raspberry Pi. I guess having a ARM launcher fragment for DYI builds would be useful though. Who's Todd?
There is http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.equinox.launcher.gtk.linux.arm in Neon. Passing "-Dnative=gtk.linux.arm" to your maven build and having all the devel packages properly foundable should build it.
I have tried this on my Shield Tablet for many times without success, until I read the following in the maven log file: [exec] cc -g -s -Wall -fpic -DLINUX -DMOZILLA_FIX -DDEFAULT_OS="\"linux\"" -DDEFAULT_OS_ARCH="\"armv7l\"" -DDEFAULT_WS="\"gtk\"" -DDEFAULT_JAVA_JNI -DGTK_LIB="\"libgtk-x11-2.0.so.0\"" -DGDK_LIB="\"libgdk-x11-2.0.so.0\"" -DGTK3_LIB="\"libgtk-3.so.0\"" -DGDK3_LIB="\"libgdk-3.so.0\"" -DPIXBUF_LIB="\"libgdk_pixbuf-2.0.so.0\"" -DGOBJ_LIB="\"libgobject-2.0.so.0\"" -DX11_LIB="\"libX11.so.6\"" -I. -I.. -I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux `pkg-config --cflags gtk+-2.0` -c ../eclipseNix.c -o eclipseNix.o [exec] cc -shared -fpic -Wl,--export-dynamic -o eclipse_1616.so eclipse.o eclipseGtk.o eclipseUtil.o eclipseJNI.o eclipseMozilla.o eclipseShm.o eclipseNix.o eclipseConfig.o eclipseCommon.o eclipseGtkCommon.o eclipseGtkInit.o -lpthread -ldl [exec] cp eclipse ../../../../../rt.equinox.binaries/org.eclipse.equinox.executable/bin/gtk/linux/armv7l [exec] cp eclipse_1616.so ../../../../../rt.equinox.binaries/org.eclipse.equinox.executable/../org.eclipse.equinox.launcher.gtk.linux.armv7l [exec] rm -f eclipse eclipse_1616.so eclipseMain.o eclipseConfig.o eclipseCommon.o eclipseGtkCommon.o eclipseGtkInit.o eclipse.o eclipseGtk.o eclipseUtil.o eclipseJNI.o eclipseMozilla.o eclipseShm.o eclipseNix.o [...] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (copy-launcher-natives) on project org.eclipse.equinox.launcher.gtk.linux.arm: An Ant BuildException has occured: /home/haolu/Öffentlich/eclipse.platform.releng.aggregator/rt.equinox.binaries/org.eclipse.equinox.launcher.gtk.linux.arm does not exist. [ERROR] around Ant part ...<copy todir="/home/haolu/Öffentlich/eclipse.platform.releng.aggregator/rt.equinox.framework/bundles/org.eclipse.equinox.launcher.gtk.linux.arm/target" overwrite="true">... @ 4:171 in /home/haolu/Öffentlich/eclipse.platform.releng.aggregator/rt.equinox.framework/bundles/org.eclipse.equinox.launcher.gtk.linux.arm/target/antrun/build-main.xml So funnily it is copied as a file, since no folder was created there, and the name was also wrong due to my architecture being "armv7l" for cc (in my interpretation). I have yet to wait till the rebuild finishes, as I have tried to copy it out and rename it to .arm, clean up and restart the build process and manually put it back. I assume I‘d have to do the necessary changes to the ant script(s) in order to make the references match, although I found out that the binary is also missing from the test builds in the Fedora repository managed by Mat Booth <mat.booth@redhat.com> since Neon. Maybe it is worth revising some scripts out there.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This should not be stalebug, RaspPi should be a standard distribution as it used extensively in education and is also the basis for OpenHab. Both of these can recruit new participants in the Eclipse community.
