When compiling =dev-lang/spidermonkey-1.8.5-r6 on arm it fails at two points.
First one: if there's no "-mthumb" in the CFLAGS, GCC does not define "__thumb2__" and the configure script fails here.
(Defining __thumb2__ by hand makes it compile, but fail at linking stage, complaining that the selected processor does not support <a lot of instructions here> in ARM mode). Only enabling "-marm" makes it compile happy.
I've enabled "-marm" via package.env and it works like a charm, until running into the next issue.
Second one: if there's no "-fpermissive" in the CFLAGS, it fails complaining about a const char being cast to an integer.
This is a really stupid crash, because all it complains about is that a define is being set to a literal.
From file njcpudetect.h:
#define NJ_COMPILER_ARM_ARCH "Unable to determine valid NJ_COMPILER_ARM_ARCH (nanojit only supports ARMv4T or later)"
Changing the line to read #define NJ_COMPILER_ARM_ARCH 0
makes it happy again. or applying "-fpermissive" to the CFLAGS.
Created attachment 523510 [details]
It's throwing errors due to __thumb2__ or __thumb__ not being defined.
Created attachment 523514 [details]
GCC defines without -marm
gcc -dM -E - < /dev/null gives me this on a Raspberry Pi3.
Note the missing __thumb__ and __thumb2__ defines.
Created attachment 523516 [details]
GCC defines with -marm
gcc -marm -dM -E - < /dev/null gives me this on a Raspberry Pi3.
Note the defined __thumb__ and __thumb2__ macros.
strangely I cannot reproduce the second issue of breaking the compile due to the define being set to a string literal.
The first one is reproducable and is fixed by compiling with -mthumb.
However, I do not know if this is desirable, as the source has code to swtich between ARM and THUMB mode for compilation.
AFAIK ARM mode is faster than THUMB, but I could not get spidermonkey to compile in any other way than using -marm.