Hi,

at 27c3, I tested some toolchains with osmocom-bb and found a few build-problems, even with the recommended gnuarm-3.4.3. I want to document them here, so other people can find hints about it.

*** GNUARM 3.4.3 TOOLCHAIN

master branch =============

../../src/rate_ctr.c:24:22: inttypes.h: No such file or directory

Holger suggested to manually remove this line. It is fixed upstream in libosmocore and osmocom-bb needs to be synced to it. Please do :)

remotes/origin/steve-m/loader_sciphone ======================================

1) First problem is:

In file included from ../../include/osmocore/msgb.h:23, from ../../src/msgb.c:27: /home/wsa/Dev/osmocom-bb/src/target/firmware/include/stdint.h:13:25: stdint.h: No such file or directory

Cherry-picking e0a605819c39187a494e43cf591f2e79a9d9903f (stdint.h: Next attempt at making this work with various compilers) helps.

2) It then runs into the problem of the master branch.

3) After this is fixed, I get

../../../src/codec/gsm610.c:24:20: stdint.h: No such file or directory ../../../src/codec/gsm610.c:33: error: parse error before "gsm610_bitorder"

which needs 733c894c18c127ce5c023e39609b7d2b9e748e7e (build: Use absolute path in the CFLAGS for libosmocore target build) as a fix.

4) This then, leads to:

arm-elf-ld: address 0x400054d4 of board/mt62xx/loader.mtkram.elf section .text is not within region LRAM

which is sadly also present when you just cherry-pick the main patch

d04761d19c432201f7c0f10c72f788fb695d466a ([WIP] Modify loader for use as first stage bootloader on MT62xx devices)

on top of current master + its build fix. So, does it seem sensible to simply rebase this branch to master which would eliminate the first three problems? Or at least cherry-pick the above fixes?

Also, the workarounds for gcc3 do not look very sustainable (see custom stdint.h). Is it a mid-term option to remove that stuff if a reliable pre-built gcc4 is available? (I am working on that, see below).

BTW the linker error was not further worked on yet. I got a prebuilt binary now. It is possibly helpful to put it on the G2-wikipage, so people wanting to work on the Linux-support only are spared from the above hassle.

*** CUSTOM 4.3.2 TOOLCHAIN

every branch ============

The configure-stage of libosmocom already fails for the target with error 77. The config.log says in detail:

configure:3231: checking whether the C compiler works configure:3253: arm-elf-gcc -Os -ffunction-sections -I/home/wsa/Dev/osmocom-bb/src/target/firmware/include conftest.c >&5 /home/opt/OSELAS.Toolchain-1.99.3/arm-elf/gcc-4.3.2-newlib-1.16.0-binutils-2.18/bin/../lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/libc.a(lib_a-exit.o): In function `exit': /home/mkl/himalia-pengutronix/toolchain/releases/OSELAS.Toolchain-1.99.3.6/platform-arm-elf-gcc-4.3.2-newlib-1.16.0-binutils-2.18/build-target/newlib-1.16.0/newlib/libc/stdlib/exit.c:65: undefined reference to `_exit' /home/opt/OSELAS.Toolchain-1.99.3/arm-elf/gcc-4.3.2-newlib-1.16.0-binutils-2.18/bin/../lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r': /home/mkl/himalia-pengutronix/toolchain/releases/OSELAS.Toolchain-1.99.3.6/platform-arm-elf-gcc-4.3.2-newlib-1.16.0-binutils-2.18/build-target/newlib-1.16.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk'

27c3 was too interesting ;) so I haven't fixed this yet. The Mac-toolchains also throw this and I also have seen it on the list before, so I hope I can work on it the next days.

So much for now. It would be nice if someone with write-access to the repo could comment on my questions and/or fix the low-hanging fruits. I will hopefully be able to send some updates soon, too (famous last words).

It was great to meet you all in person!

All the best,

Wolfram