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] dev-lang:spidermonkey-1.8.5-r6:20180311-150425.log 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.
spidermonkey <78 is no longer in tree. The codebase has changed substantially since then, so closing.
