(TECH) [SOLVED] preparing proper arm-none-eabi toolchain

seeed86 · February 21, 2016, 2:16pm

NB: Problem is solved. Look here.
Hi there!
When I’m trying to build some RePhone project from source (using Makefile from LinkIt SDK, as I understand situation), I experiencing some issues:
First of all, original MTK LinkIt SDK is only for windows. So, users on another platforms going to make SDK themselves.
So, I installed arm-none-eabi toolchain (actually, built it with “crossdev” tool, since I’m using Gentoo), which by default comes with “newlib” libc (because of “none eabi”) or without any libc at all.
If I trying to run make with toolchain, built without any libc at all, I’m getting error that stdio.h is not found.
If I run make on toolchain with libc (newlib) — I’m getting following build failure:

arm-none-eabi-gcc -mcpu=arm7tdmi-s -mthumb -mlittle-endian -O2 -Wl,--gc-sections --specs=nosys.specs -fpic -pie -Wl,-Map=lua.map -Wl,--entry=gcc_entry -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-unresolved-symbols -Tlinkit/lib/LINKIT10/armgcc/scat.ld -Llinkit/lib -o lua.elf -Wl,--start-group src/main.o src/retarget.o src/shell.o src/lcd_sitronix_st7789s.o src/tp_goodix_gt9xx.o src/tp_i2c.o lua/lapi.o lua/lcode.o lua/ldebug.o lua/ldo.o lua/ldump.o lua/lfunc.o lua/lgc.o lua/llex.o lua/lmem.o lua/lobject.o lua/lopcodes.o lua/lparser.o lua/lstate.o lua/lstring.o lua/ltable.o lua/ltm.o lua/lundump.o lua/lvm.o lua/lzio.o lua/lrotable.o lua/lauxlib.o lua/lbaselib.o lua/ldblib.o lua/liolib.o lua/lmathlib.o lua/loslib.o lua/ltablib.o lua/lstrlib.o lua/loadlib.o lua/linit.o lua/print.o lua/linenoise.o bindings/audio.o bindings/gsm.o bindings/gpio.o bindings/i2c.o bindings/timer.o bindings/tcp.o bindings/screen.o bindings/https.o bindings/bluetooth.o linkit/lib/LINKIT10/src/gccmain.o linkit/lib/LINKIT10/armgcc/percommon.a -lm -Wl,--end-group /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-syscalls.o): In function `_lseek': /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0.20160104/newlib/libc/sys/arm/syscalls.c:282: multiple definition of `_lseek' linkit/lib/LINKIT10/src/gccmain.o:gccmain.c:(.text+0x16c): first defined here /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-syscalls.o): In function `_open': /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0.20160104/newlib/libc/sys/arm/syscalls.c:391: multiple definition of `_open' linkit/lib/LINKIT10/src/gccmain.o:gccmain.c:(.text+0xcc): first defined here /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-syscalls.o): In function `_close': /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0.20160104/newlib/libc/sys/arm/syscalls.c:413: multiple definition of `_close' linkit/lib/LINKIT10/src/gccmain.o:gccmain.c:(.text+0x120): first defined here /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-syscalls.o): In function `_kill': /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0.20160104/newlib/libc/sys/arm/syscalls.c:419: multiple definition of `_kill' linkit/lib/LINKIT10/src/gccmain.o:gccmain.c:(.text+0x200): first defined here /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-syscalls.o): In function `_exit': /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0.20160104/newlib/libc/sys/arm/syscalls.c:438: multiple definition of `_exit' linkit/lib/LINKIT10/src/gccmain.o:gccmain.c:(.text+0x1fc): first defined here /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-syscalls.o): In function `_getpid': /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0.20160104/newlib/libc/sys/arm/syscalls.c:452: multiple definition of `_getpid' linkit/lib/LINKIT10/src/gccmain.o:gccmain.c:(.text+0x204): first defined here /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-syscalls.o): In function `_fstat': /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0.20160104/newlib/libc/sys/arm/syscalls.c:491: multiple definition of `_fstat' linkit/lib/LINKIT10/src/gccmain.o:gccmain.c:(.text+0x130): first defined here /usr/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/lib/thumb/libc.a(lib_a-syscalls.o): In function `_isatty': /var/tmp/portage/cross-arm-none-eabi/newlib-2.3.0.20160104/work/newlib-2.3.0.20160104/newlib/libc/sys/arm/syscalls.c:595: multiple definition of `_isatty' linkit/lib/LINKIT10/src/gccmain.o:gccmain.c:(.text+0x15c): first defined here collect2: error: ld returned 1 exit status Makefile:66: recipe for target 'lua.elf' failed make: *** [lua.elf] Error 1
I even tried to comment out inclusion of linkit/src/gccmain.o in Makefile, but got a warning about missed gcc_entry.
And, looking at the code in gccmain.c, it defines functions, which exists in newlib’s syscalls.c in a bit another way (maybe, more related to RePhone or MTK?)
So, I don’t know what to do now, to fix the build (except marking all mentioned definitions with a attribute ((weak)), which, I think, anyway will made compiler to prefer newlib’s implementations, and not linkit’s, which maybe bad idea…
Any ideas? Maybe, there should be used some another libc?

dbelam · February 21, 2016, 4:37pm

Just to be sure: you want to use native code instead of the RTOS? Or you just want to make MediaTek’s job and make a proper toolchain for Linux/Mac?

seeed86 · February 21, 2016, 5:15pm

Uhm… Actually, I’m not sure about RTOS part, but anyway: I just want to use toolchain, locally compiled from the source code, and not something semi-proprietary (and use GCC-5+).

And, yes, I just want to compile vxp-sketches myself, without ArduinoStudios and so on

And, actually, I almost get it working: if I taking libc.a from precompiled SDK from some project like github.com/robarago/ArduinoGNUL … e-eabi/lib then all builds just fine. But I can’t figure out, what exactly libc was used. And, looking into newlib sourcecode shows, that things, in which it conflicts with gccmain.o was there for all the time of existence.

So, probably, it is some another libc (and I’d like to know which one).

dbelam · February 21, 2016, 9:39pm

Just because if you want to generate VXP, arm-none-eabi sounds not too good for me: I’m not 100% sure, but it should be some arm-whateverRTOSisrephoneusing-eabi toolchain, because no-OS target will just skip the RTOS and its whole API, I hope you don’t want to rewrite everything from scratch
I never digged deep inside the current toolchain, but I assume the needed libc is either packed, or it’s coming from the RTOS part.

seeed86 · February 21, 2016, 10:33pm

Talking about “none” EABI:
github.com/robarago/ArduinoGNUL … -none-eabi
This is a part of RePhone’s ArduinoIDE. And even in Windows-only SDK from MTK site, there is “arm-none-eabi” toolchain target.
AFAIK, “arm-none-eabi” is special target for “embedded” Cortex-M/R SoCs. And mostly it used without libc at all (for compiling RTOS, yes). Say, for TI Stellaris and such things.

But, as far as I digged into RePhone’s MTK SDK in it’s variations, here is libc. And, moreover, it looks like SDK’s toolchain is just launchpad.net/gcc-arm-embedded/ (not sure, if patched or vanilla). And, as I tested, it is all okay with stdlib headers from vanilla “newlib” (which is also a part of the source tarrball of official arm toolchain from above) and with libc.a from precompiled version of that official ARM toolchain).

So, TL;DR: it seems, it is newlib used even in “right” toolchain, but, it seems, it is kinda patched.

seeed86 · February 22, 2016, 8:35am

SOLVED: I’ve solved a problem by adding extra “configure” arguments for newlib: “–enable-newlib-io-long-long --enable-newlib-register-fini --disable-newlib-supplied-syscalls”. Actually, only last one makes deal, and first two is just “usefull” things for that toolchain.