Raspberry Pi 2 anyone?

gepatto · July 29, 2015, 8:55am

got the dev version from git, but neko build.n goes into an endless loop:

Usage : neko build.n [clean] [link-]target[-arch][-arch] …] [-debug] [-verbose] [-D…]
target : ios, android, windows, linux, mac, mingw
default (=current system)
link : ndll- or static-
(none specified = both link types, mingw static only
arch : -armv5 -armv6 -armv7 -arm64 -x86 -x86_64 -m32 -m64
(none specified = all valid architectures
-D… : defines passed to hxcpp build system
eg: neko build.n clean ndll-mac-m32-m64 = rebuild both mac ndlls
Specify target or ‘default’ to remove this message

Using default = linux
neko run.n Build.xml -Dlinux -DHXCPP_M64 /home/pi/software/hxcpp/project/
This version of hxcpp (/home/pi/software/hxcpp/) appears to be a source/developement version.
Before this can be used, you need to:

Rebuild the main command-line tool, this can be done with:
cd tools/hxcpp
haxe compile.hxml

Build the binaries appropriate to your system(s), this can be done with:
cd project
neko build.n

Would you like to do this now [y/n]y
Compiling hxcpp tool…
Standard library not found
Building binaries…

after this it repeats itself

ibilon · July 29, 2015, 9:14am

If you do cd tools/hxcpp && haxe compile.hxml manually you get Standard library not found?

Maybe it’s having trouble find haxe, there’s the HAXEPATH environment variable you could use to specify where is your haxe folder, worth a try.

gepatto · July 29, 2015, 9:26am

Hehe I was just typing this , it looks like I didn’t install Haxe properly on this SD-card (got too many) …
I have been trying to find a proper installation guide for haxe on rpi2 but no luck so far.
I just got the binaries and copied them over to /usr/local/bin/ .
Is there a default path for the std directory that Haxe looks for, or should I add a variable to my .profile ?
i.e.: export HAXE_STD_PATH=/SOME/PATH

ibilon · July 29, 2015, 9:34am

By default it’ll look into /usr/lib/haxe/std/, /usr/share/haxe/std/ and /usr/local/lib/haxe/std/.
But HAXE_STD_PATH does exists.

gepatto · July 29, 2015, 11:28am

Ok, it finds the standard library now.

neko build.n

tries to run neko run.n Build.xml -Dlinux -DHXCPP_M64
so it’s not finding the architecture ( looks like it thinks it’s 64bit)

neko build.n ndll-linux-armv7

does nothing: no errors, no output, it just returns to the prompt

neko build.n ndll-linux-m32

does start compiling (without errors), but I don’t know if this will build anything useful

singmajesty · July 30, 2015, 7:32pm

Try:

lime rebuild hxcpp linux -rpi

and:

lime rebuild hxcpp linux -rpi -static

gepatto · August 1, 2015, 2:42pm

Ok Joshua, they both compile.

I can now even do: haxelib run lime rebuild linux -rpi without errors
but I still don’t know how to tie it all together.

I now have hxcpp and lime in a subdirectory in my home dir and I can see the lime ndlls and the libcompat.a from hxcpp.
When I just run lime I get:

Uncaught exception - load.c(237) : Failed to load library : lime.ndll (lime.ndll: cannot open shared object file: No such file or directory)

Do I need to copy some files or run an extra command?

By the way thanks for helping guys!

ibilon · August 1, 2015, 2:56pm

What is the folder where the ndll is located?

Looking at some code it seems the tools want you to specify -rpi for every commands.

So I guess retry with lime -rpi.

github.com

openfl/lime/blob/master/tools/CommandLineTools.hx#L455


				}
				
				publishProject ();
			
			case "installer", "copy-if-newer":
				
				// deprecated?
			
			default:
				
				LogHelper.error ("'" + command + "' is not a valid command");
			
		}
		
	}
	
	
	#if (neko && (haxe_210 || haxe3))
	public static function __init__ ():Void {
		
		var args = Sys.args ();

gepatto · August 1, 2015, 3:02pm

Hi Valentin,

At the moment it’s in /home/pi/software/lime/ndll/RPi/

and you’r right lime -rpi does run!

I was now able to do haxelib run openfl setup -rpi

Feels like we’re getting close

singmajesty · August 1, 2015, 3:03pm

You can also try lime -nocffi if you want, so the tools don’t look for the RPi binary, only projects would.

gepatto · August 1, 2015, 3:44pm

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

ibilon · August 1, 2015, 5:34pm

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,

gepatto · August 2, 2015, 11:47am

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
and

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?

gepatto · August 2, 2015, 12:09pm

if it helps: this is the contents of final.hxml that is created in my projectfolder
/home/pi/openfl/DisplayingABitmap/Export/linux64-rpi/neko/haxe/

-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

ibilon · August 3, 2015, 4:06pm

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.

gepatto · August 3, 2015, 9:02pm

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…

singmajesty · August 4, 2015, 2:48pm

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

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

gepatto · August 4, 2015, 4:00pm

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

https://gist.github.com/gepatto/7fc95043c63b66cf58c2

gepatto · August 4, 2015, 7:14pm

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.

gepatto · August 4, 2015, 8:30pm

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
and
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