cant build stmhal with Linaro toolchain

[miltmobley]

Hi, I made a first attempt to build stmhal on a Linux Mint system with a Linaro toolchain,
specifically gcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf,
and got some errors.

The definition of HUGE in micropython/lib/libm/fd_libm.h (~line 88) gets a 'redefined' error,
since HUGE was previously defined in arm-linux-gnueabihf/libc/usr/include/math.h,
which is included at the top of fd_libm.h.

I can hide this error by undefining HUGE in fd_libm.h just before it is declared there,
but is there a better solution? If all the other names that are defined in the same block
are also defined elsewhere, the entire block could be ifdef'd out, hopefully only when
the use of Linaro toolchains is detected.

I also get a number of errors like "unknown type name '__int32_t'" in various files. This and other names are defined in gcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/usr/include/bits/types.h,
but for some reason are not visible via math.h.

Are these problems toolchain specific? If so, what toolchain was used to build the original versions?
'arm-none-eabi-gcc' seems vague, since armhf.com, launchpad.net and others have been publishing arm toolchains
with similar names in recent years.

[pfalcon]

As its name suggests, Linaro toolchain targets building for Linux OS. For bare-metal targeting, https://launchpad.net/gcc-arm-embedded is recommended.

[miltmobley]

Thanks for your reply.True, Linaro has a Linux focus, but also provides a bare metal toolchain, the one I used.
I also tried the standard one provided by Linux Mint via Synaptic, which has different problems.
I will try the launchpad one next.

[dhylands]

The linaro toolchain assumes that it's using glibc and will have a bunch of builtin assumptions related to that.

The arm-none-eabi toolchains assume that you're using newlib (or something similar) and don't try to use the glibc headers when building.

[miltmobley]

Hi all, I downloaded the launchpad tool chain. Now all the files seem to compile,
but the link fails with a dozen or so messages like:
objcomplex.c:(.text.complex_print+0x52): undefined reference to `__isnanf'

Also not found were __finitef and sincosf.

I couldn't find any references to __isnanf in the micropython source, and in the ARM tool chain.
I downloaded the source for the tool chain, but much of the code is delivered in .gz and .bz2 archives,
which Linux find doesn't seem to be able to inspect.

My next step is to put the tool chain source into an Eclipse project in the hopes that Eclipse search tool will
be able to inspect the archives. Otherwise, I will have to unpack the archives to search their contents for the
definitions of __isnanf, etc., to figure out why the linker can't find them.

Is this a known problem, and is there a simple solution?

BTW, my reason for building micropython from source is to familiarize myself with the code while waiting for a
pyboard to arrive. I also guessed that it would be a necessary step to add new drivers, since there is no os.

[dhylands]

Did you remove the build drectory? (i.e. make clean or rm -rf build-PYBV10)

Otherwise it will contain objects built by the old toolchain which will cause issues with the new toolchain.

[miltmobley]

Thanks, that fixed the problem, now the build completes.