2 Jan
2011
2 Jan
'11
12:19 p.m.
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