Raspberry Pi 2 anyone?


Ok next up: trying to build an example.
I’m pretty sure I’ll run into some more issues.


I’ve made a pull request which should allow to use the tools on a rpi without either of the two flags, if you could confirm it works.

The changes are easy to manually add,


Ok I added the changes from the pull-request.
removed the lime command from /usr/bin
and ran haxelib run lime setup -rpi

but it still complained unless I added the -rpi option.

I then realized that the raspberry pi 2 is an ARMV7 architecture and not an ARMV6.
So I added

|| PlatformHelper.hostArchitecture == Architecture.ARMV7

to your changes in CommandLineTools.hx

else if (output.indexOf (“armv7”) > -1) {

                    _hostArchitecture = Architecture.ARMV7;

to PlatformHelper.hx:

then ran lime rebuild tools -rpi
and now I can run lime without the -rpi option

I then created an tested and example project:

openfl create DisplayingABitmap

openfl test neko

but it trows an error:

./DisplayingABitmap: 1: ./DisplayingABitmap: Syntax error: “)” unexpected

I was surprised to find a linux64-rpi folder under Export

any ideas?


if it helps: this is the contents of final.hxml that is created in my projectfolder

-main ApplicationMain
-cp /usr/lib/haxe/lib/openfl/3,2,2
-D openfl=3.2.2
-cp /home/pi/software/lime
-D lime=2.5.2
-cp Source
-D lime-openal
-D openfl-next
-D tools=2.5.2
-D lime-cairo
-D no-compilation
-D lime-opengl
-D native
-D rpi=1
-D lime-native
-D lime-curl
-D openfl-native
-D linux
-D desktop
–remap flash:openfl
-cp Export/linux64-rpi/neko/haxe
-neko Export/linux64-rpi/neko/obj/ApplicationMain.n
–macro keep(“Main”)
-D final


Is that a compile time or run time error? Looks werid for both,
decomposing the test in build then run may make it easier to see.


It’s a runtime error.
There’s no errors building openfl build neko
But running any project openfl run neko , even an empty HelloWorld example results in

./HelloWorld: 1: ./HelloWorld: Syntax error: “)” unexpected

I’m trying to understand the toolchain (I’m completely new to haxe and neko)
so I can figure out what is building/creating the linux64-rpi
cause it looks like there’s some other part not finding the right architecture…


If you can build the Lime tools and run them, that’s a good sign – it means Haxe and Neko are working properly, at least to a point :wink:

Could you do openfl test neko -verbose and see what you get?

EDIT: Oh, sorry, runtime error. What happens if you do a C++ build? openfl test linux -rpi -verbose


below is the output of openfl test linux -rpi -verbose

the line
PlatformHelper.hx:69: Detected host architecture: ARMV7
in the gist comes from a line added by me ,trying to see if scripts detect the right architecture



Ok, interesting, the haxelib run hxcpp command is being called with the -DHXCPP_M64=1 option.
If I manually call this command but exchange M64 with M32 it appears to compile without errors.


Ok that kinda worked…

I tried openfl test linux -rpi -verbose
then manually ran
haxe Export/linux64-rpi/cpp/haxe/release.hxml -D HXCPP_M32
haxelib run hxcpp Build.xml -DHXCPP_M32="1" -Ddesktop="1" -Dhaxe3="1" -Dhaxe_ver="3.103" -Dhxcpp_api_level="311" -Dlime="2.5.2" -Dlime-cairo="1" -Dlime-curl="1" -Dlime-native="1" -Dlime-openal="1" -Dlime-opengl="1" -Dlime_cairo="1" -Dlime_curl="1" -Dlime_native="1" -Dlime_openal="1" -Dlime_opengl="1" -Dlinux="1" -Dnative="1" -Dopenfl="3.2.2" -Dopenfl-native="1" -Dopenfl-next="1" -Dopenfl_native="1" -Dopenfl_next="1" -Drpi="1" -Dtools="2.5.2" -DHXCPP_M32 -verbose

in the DisplayingABitmap/Export/linux64-rpi/cpp/obj dir
and then waited a long time

then copied the ApplicationMain over to the bin directory, started xwindows and doubleclicked ApplicationMain


I found a line in RunScript.hx in Lime Tools that I think needs to be updated:

line 84:

if (PlatformHelper.hostPlatform == LINUX && PlatformHelper.hostArchitecture == X86) {

I think that should be:

if (PlatformHelper.hostPlatform == LINUX && ( PlatformHelper.hostArchitecture == X86 || PlatformHelper.hostArchitecture == ARMV6 || PlatformHelper.hostArchitecture == ARMV7)) {

and then
lime rebuild tools

now I can run
openfl test linux -rpi
without errors.


I have started on a fresh raspbian installation, but I’m stuck again with 64bit errors. Guess I did something else that I have forgotten about. Will elaborate soon


It might also work if both hxcpp m32/m64 defines are omitted, might be an issue with the HXCPP tools?


I got it running again.
I am writing down what I did and will run through it one more time from a fresh install of Raspbian.
( feel free to comment )

here is the preliminary gist link:

I am using dev versions from git. (except for format and the openfl-samples and lime-sample packages)
There are 4 files in the lime package that need to be replaced.

I had a problem where I had to copy the hxcpp/lib/linux/ dir and rename it to hxcpp/lib/RPi
I’m gonna see if that’s now still the case


I can confirm that for me the instructions on my Gist page are working.
at first I thought hxcpp wasn’t creating the ndll files in it’s lib directory, but I’ve tried it 3 times now and all seems well.

I’m able to compile the DisplayingABitmap example.
I can also compile the PiratePig example, but it’s reeeally slow.

unfortunately anything that uses a textfield (and is added to the stage) will just make the app crash on startup
with a segmentation fault, even the AddingText example
Built with openfl build linux -rpi -debug
gdb output:

Program received signal SIGSEGV, Segmentation fault.
0x7411d8c4 in INT_cairo_set_font_options (cr=0x0, options=0x71c46d48) at ./lib/cairo/src/cairo.c:2929
2929 if (unlikely (cr->status))


Is that using haxelib or dev OpenFL?


I was pretty sure that I had the latest git version.
But I threw away my dev openfl folder and did a new clone of the openfl master.

Now it’s working :smile: !! ( at 3FPS :disappointed: )
I’ll continue testing the other examples., and write about my findings.
Thanks again for all the help…

Edit: I now see there have been a bunch of text fixes in the repo the last two days, guess they fixed my problem too.
the revision I had was from 6 aug.


Which project is running at 3 FPS? Can you tell if it uses hardware, or software rendering?


I added the Openfl.display.fps to the stage on the DrawingABitmap Example and the AddingText Example they both ran at 3fps

Can you tell me how I would be able to see if it’s doing hardware-rendering or not?

I’m more than happy to do the testing.


I am not sure if a good way to tell if hardware is for sure working (perhaps trying an OpenGLView or HerokuShaders sample) but you can force software like openfl test linux --window-hardware=false