Building on Odroid XU4 fails

[Tillman-Z]

Building current master on Odroid XU4 fails.
See attached log.

Any idea how to fix this?

https://pastebin.com/2mEuHyhA

[hrydgard]

Looks like both our ES headers and desktop gl headers are getting included, strange...

[Tillman-Z]

Should I try a build with the desktop gl headers removed? Where would I need to change the Makefile?

And thanks for being so super fast in your response btw!!

[hrydgard]

No wait, that's not it. It's your gl2ext headers that defining stuff that we already also define in gl3stub.h, we should avoid getting that included. Just to test, open ext/native/gfx/gl_common.h and remove the line that includes gl3stub.h and see if that helps.

[Tillman-Z]

Building again - will know more in about 8-10mins :)

[Tillman-Z]

And this is what we get now:

https://pastebin.com/dficFx4B

I would assume there's no Vulkan support on the XU4, is there?

[hrydgard]

That was just a silly mistake from my side, I've fixed it now. It should still be able to build the Vulkan code, even if it's not using it.

[Tillman-Z]

Ok - pulled again and rebuilding now. :)

[Tillman-Z]

After a new pull this what I am getting now:
https://pastebin.com/tqH6Njz4
Still looks like Vulkan is in.

[hrydgard]

Vulkan should be in even if not used, don't worry about that. This is a GL header problem. Seems like your gl2ext has some gl3 stuff, but not all of it so now something's missing :(

We should really move to use our own gl headers...

Might want to try to hack the CMakeLists.txt to make it not have USING_GLES2 defined and see if desktop gl works on your device?

[Tillman-Z]

The retropie build script is using a cmake file called "generic.armv7.cmake" on the Odroid XU4.
I have modified it to set USING_GLES2 to off.
This is how it looks like:
set(ARMV7 ON)

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -march=armv7-a -mfpu=neon -mcpu=cortex-a9")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=armv7-a -mfpu=neon -mcpu=cortex-a9")
set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -march=armv7-a -mfpu=neon -mcpu=cortex-a9")
set(USING_GLES2 OFF)

However still no joy:

https://pastebin.com/s8Wk0sES

[Tillman-Z]

If you have any further ideas I am happy to try them. :)

[mrvanes]

Looking at the same problem, but building in an arm chroot env (tuned for XU4)

[mrvanes]

I've managed to compile ppsspp in an odroid flavoured arm chroot by patching /usr/include/GLES2/gl2ext.h
I changed the #ifdefs to fail by adding a nonsense _FAIL to the check:

279:#ifdef GL_GLEXT_PROTOTYPES_FAIL
1088:#ifdef GL_GLEXT_PROTOTYPES_FAIL

Then I ran into this problem:
https://forum.odroid.com/viewtopic.php?f=91&t=26822

Which I solved by supplying __ARM_PCS_VFP to the asm, c and cxx flags like suggested in the forum.

[unknownbrackets]

Is this still a problem?

If __ARM_PCS_VFP needs to manually be defined, that seems concerning. We use that currently to detect hard float:

ppsspp/Core/MIPS/ARM/ArmCompVFPU.cpp

Lines 2223 to 2230 in aa927e0

	#if defined(__ARM_PCS_VFP) // Hardfp
	VMOV(S0, fpr.V(sreg));
	#else // Softfp
	VMOV(R0, fpr.V(sreg));
	#endif
	// FlushBeforeCall saves R1.
	QuickCallFunction(R1, negSin1 ? (void *)&SinCosNegSin : (void *)&SinCos);
	#if !defined(__ARM_PCS_VFP)

-[Unknown]

[mrvanes]

It's not a problem in the sense that I stopped trying to cross-compile ppsspp. But if you think cross-compiling ppsspp is worthwile (e.g. speed, Travis test building) this will come up again.

[unknownbrackets]

I think we've fixed the ARM problem. Since this is an older issue and hasn't gotten feedback recently, I'm going to close it in favor of #13840 which has more detail by now on the GL header issue.

-[Unknown]