Urho on a Tinkerboard (Like a raspberry pi)

I’m currently trying to get urho working on my Tinkerboard running the official ASUS image of TiinkerOS.

I have tried the rasperry pi .deb’s found on the sourceforge as well as a few others and the only ones that do anything after a successful installation are the 1.7 ARM STATIC A9, and ARM SHARED A9.

I don’t actually know if those two have any impactful differences.

They both produce this output (the last line also shows up in a popup box, so it kinda works)

ERROR: Could not create window, root cause: ‘Could not initialize EGL’

https://hastebin.com/raw/ehufinugaf --01HelloWorld output

https://github.com/urho3d/Urho3D/blob/master/Source/ThirdParty/SDL/src/video/SDL_egl.c#L272 --line showing me the error

http://m.uploadedit.com/bbtc/1512498083388.txt --strace output

I’d try the experimental arm build process but that’s a single paragraph that’s clearly written for more intermediate users. I have no idea what half the stuff it refers to, so i can’t even attempt to build that just yet.

But is this issue with the .debs workaroundable do you think?

1 Like

You already off for a good start. RPI prebuilt package should only be used for Raspberry-Pi. Use the ARM package for the rest of the generic ARM board running on Linux kernel or better yet build from source directly. This is because those prebuilt packages are just build artifact from out ARM-CI. The build settings there may or may not matches the ARM processor you have on your board.

If you don’t know how to cross-compile in general, you can search for it using google. Basically you need to tell the build system where is your compiler toolchain is and where is your sysroot (device system root). You can just download the sysroot repo provided by Urho to your host/build system or just connect your device to your host and mount the system root of your device to you host file system (obviously you need Linux host for that). Alternatively, the easier route would be learn how to build Urho from a desktop Linux host. Once you graduate from that then connect a keyboard and monitor to your board (assuming it can do that), boot it up and build Urho directly on the device itself. Slow no doubt.

As for your problem, I think it means it missed some of the required dependency packages. We have the list documented in our online documentation. Good luck.

where is your compiler toolchain is and where is your sysroot (device system root).

What do you mean by this. I am a novice in the linux side of things so I don’t have the context to know what that means exactly.

Also for reasons that are irrelevant, this is my desktop pc. The Tinkerboard is my daily driver and there’s no backup/2nd computer.

You can just download the sysroot repo provided by Urho

I’ve got the source downloaded from git, is it that?

What was all that stuff about little endians on the page listing the experimental arm build process?

Excuse the double post, but I’ve gotten somewhere else with this.

this is the output i get after doing ./cmake_arm.sh and then doing 'make’
https://pastebin.com/te04dfeB

./cmake_generic.sh and then ‘make’ also didn’t work. failing at the same point

Like I said earlier, if this is your first time doing cross-compiling then do some research on Google first. Come back here again when you have understood what I meant by cross-compiler toolchain and system root. I will wait :slight_smile: .

If you take the easier route though by building directly on the device/board itself then you just have to make sure you have all the prerequisite dependency dev packages installed before starting building anything. Again good luck.

I am building it ON my tinkerboard and am still getting the errors in my “excuse the double post” hastebin log. There is no 2nd pc, so there’s no need for cross compilation. I’m trying to get this to work ON a tinkerboard FOR a tinkerboard.

We had spent some hours looking into this before posting. What I was thinking is that SDL’s eglInitialize() was failing on this configuration, and there seems to be some precedent (and in the first result thread, did I see a patch?). https://www.google.com/search?q=eglInitialize+tinkerboard

i might be getting different results bc it’s redirecting me to the .co.uk, or I just don’t know what i’m supposed to be looking for in that first link |:

My apology. Sometime my English fails me, expecially before my morning coffee. Now I understood perfectly what you meant by not having 2nd computer. Earlier I thought you wanted to say you have a primary PC (implying Windows) and don’t have another one on Linux for cross-compiling. In which case it should not be a showstopper to learn cross-compiling still.

Anyway, your errors are compilation error. It looks different than runtime errror pointed out by @jmiller (I could be wrong though). Your compilation errors were more probably caused by missing GL header file. And that’s the reason why I asked you to ensure you have installed all the required dev packages. I could not be more specific here to tell you what exactly is the missing package name because I don’t have that device and I also don’t know whether Asus’s package repository is based on Debian or not.

Okay, i’ve just gone through this list https://urho3d.github.io/documentation/HEAD/_building.html#Building_Prerequisites and double checked, i think there might have been one or two that i missed (or assumed i already had)

I hope it was just a small mistake like that and that it gets past 56% this time

E;

Nope same failure at 56%. it is debian based I think, btw

What I found it strange is that your output actually didn’t complain about missing header, but the GL functions that would have been declared by the GL.h. It could be a wrong or incomplete header file is installed in your system (only a wild guess).

Are you referring to the output of the example, or output of compiling it?

Output from your paste bin. Unless, of course, if you didn’t paste all the errors then it would explain it.

From that I take it you didn’t see the 2nd paste bin link, the first one has everything that was given. The log from the 2nd pastebin link is the output from my compiling attempt. I ommited logs from the 50-55% steps because those had completed without fail.

If so, then it is strange as I first put it. You have the header file and yet your header file didn’t do what it supposed to do.

Is that a header file in the source i downloaded? do you think if i get a working one and try compiling that it would get a little bit further along?

No, that header file comes from the dev package, not part of Urho source code. Look for it somewhere in your /usr/include or its subdirs. This is normally where dev headers get installed.

I’ve just gone through the prerequisite list again and reinstalled stuff i already had just in case those downloaded wrong. But which header file are you referencing exactly?

The only thing i can see from the compiler output is a .cpp file: Urho3D/Source/Urho3D/Graphics/OpenGL/OGLGraphics.cpp

Everything you’ve said sounds reasonable, but I have no idea what to do with any of that information… I’m a novice thrown in at the deep end because of the platform this tinkerboard runs on.

I might have to call it quits soon because this is just infuriating

e:

Here’s another log after messing around with some libraries, it failed at 50% instead of 56% so i’m just posting it here in case i need to reference it https://pastebin.com/wSPHnw3K

I have already answered that. The name of the problematic header is “GL.h”. Compare the content of that file in your host system to Urho prepared ARM sysroot to see if there is anything wrong. I have highlighted one of the line.

What do you mean by ‘to urho prepared arm sysroot’?

also I found these files;

linaro@linaro-alip:~$ sudo find / -name “gl.h”
/usr/include/GL/gl.h
/usr/include/GLES/gl.h

And the GLES one has this

GL_API void GL_APIENTRY glGetBufferParameteriv (GLenum target, GLenum pname, GLint *params);
GL_API void GL_APIENTRY glGetClipPlanex (GLenum pname, GLfixed eqn[4]);
GL_API void GL_APIENTRY glGenBuffers (GLsizei n, GLuint *buffers);
GL_API void GL_APIENTRY glGenTextures (GLsizei n, GLuint *textures);
GL_API GLenum GL_APIENTRY glGetError (void);
GL_API void GL_APIENTRY glGetFixedv (GLenum pname, GLfixed *params);
GL_API void GL_APIENTRY glGetIntegerv (GLenum pname, GLint *params);
GL_API void GL_APIENTRY glGetLightxv (GLenum light, GLenum pname, GLfixed *params);
GL_API void GL_APIENTRY glGetMaterialxv (GLenum face, GLenum pname, GLfixed *params);
GL_API void GL_APIENTRY glGetPointerv (GLenum pname, GLvoid **params);
GL_API const GLubyte * GL_APIENTRY glGetString (GLenum name);
GL_API void GL_APIENTRY glGetTexEnviv (GLenum env, GLenum pname, GLint *params);
GL_API void GL_APIENTRY glGetTexEnvxv (GLenum env, GLenum pname, GLfixed *params);
GL_API void GL_APIENTRY glGetTexParameteriv (GLenum target, GLenum pname, GLint *params);
GL_API void GL_APIENTRY glGetTexParameterxv (GLenum target, GLenum pname, GLfixed *params);
GL_API void GL_APIENTRY glHint (GLenum target, GLenum mode);
GL_API GLboolean GL_APIENTRY glIsBuffer (GLuint buffer);
GL_API GLboolean GL_APIENTRY glIsEnabled (GLenum cap);
GL_API GLboolean GL_APIENTRY glIsTexture (GLuint texture);
GL_API void GL_APIENTRY glLightModelx (GLenum pname, GLfixed param);
GL_API void GL_APIENTRY glLightModelxv (GLenum pname, const GLfixed *params);

That’s the same spread of lines as the embed preview on your link. Again, I don’t understand what I’m supposed to be looking for. There’s nothing standing out and i fear I may be a bit out of my depth because it’s not obvious nor intuitive for me.

So sorry if the answer is right in front of me, I’m just a little bit blind in experience