Page History

Integrating with Newlib

Built-In C Library

NuttX has its own, tiny, built-in C library. Along with that C library are all of the headers files with the definitions specific to that built-in C library. The definitions in those header files are not compatible with the definitions that you will find in the header files that come with any other C library and trying to mix these with header files from other C libraries is bound to cause you problems.

...

There are many C libraries available: glibc and uClibc are commonly used with Linux tools. These should be avoided. Most embedded toolchains will be built against newlib. So if you are not using the NuttX buildroot toolchain, you will most likely be using a toolchain that has newlib built into it. Because of this, you may see issues if you include newlib header files into your NuttX code.

Header File Issues

math.h

Nuttx includes a built-in math library that can be selected with CONFIG_LIBM=y. There are reasons to use an external math library, however: The NuttX math library is written in C and will not be as performant as a custom math library tuned for your processor architecture. There some addition issues with the NuttX math libraries as documented in the top-level TODO list.

...

• The PX4 team uses these patches to cwhar and math.h to solve the issue. But note the comments in that code:

    /* N.B. The following definitions are enabled at this time to allow the PX4 
 * development to continue until there is a SAFE  solution to foreign

...

 
 * (non-nuttx) header file inclusion. There is a potential of a binary

...

 
 * incompatibility and runtime errors, memory overwrites or corruption

...

 
 * VVVVVVVVVVVVVVVVVVVVVVVVVV Begin Warning VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV

...

 
 */ 

• Some people have suggested adding the type definition of wint_t to nuttx/include/sys/types.h merely because that header file will then be included into the newlib math.h. This inclusion, of course, also very dangerous since the types in the NuttX sys/types.h header file may not agree with the types in the pre-compiled newlib math library. This solution is not recommended, in any case. The type wint_t is already correctly defined in nuttx/include/sys/wchar.h which is the one and only correct location per OpenGroup.org. It is a mystery to my why the newlib math.h header file uses wint_t without including wchar.h. If it did, then there would then this compilation issue would not exist (there could still be subtle binary compatibility issues).

...

  commit 894ca622e6a408e5fa858a3fee46fb16f32cf86c
  Author: Xiang Xiao <xiaoxiang@xiaomi.com>
  Date:   Mon Aug 27 06:26:37 2018 -0600

    include/sys/types:  Move wint_t and wctype_t from wchar.h to
    types.h.  This change is compatible as before since wchar.h
    include types.h indirectly.  This fixes a compilation error with
    newlib's math.h:  'unknown type name wint_t'

cmath

This error has been reported:

...

If you plan to use the newlib math.h and the NuttX cmath, then you probably have to modify cmath as well.

alloca.h

If your imported application includes alloca.h, then you will run into the same kinds of issues. Nuttx does not provide this header file an so you will probably end up including the newlib version of alloca.h which has similar disastrous results.

...

  #ifndef _ALLOCA_H
  #define _ALLOCA_H

  #define alloca __builtin_alloca

  #endif /* _ALLOCA_H */

And add the path to this alloca.h to your CFLAG include path arguments. The path can specified by adding -system or -I to the CFLAGS. The path to this alloca.h must be defined last so that it has precedence.

...

  #ifndef _MYMATH_H
  #define _MYMATH_H
  #ifndef _ALLOCA_H
  #define _ALLOCA_H

  #define alloca __builtin_alloca

  #endif /* _ALLOCA_H */

  #include_next <math.h>

  #endif /* _MYMATH_H */

This will provide the alloca() definition, then continue to include the default version of math.h. This works because the idempotence pre-processor variable _ALLOC_H matches the same idempotence variable used in the newlib alloca.h. Thus, any sneak inclusion of alloca.h with have not effect.

C++ Issues

Most of the C++ issues that have not so much to do with header files as with C++ name mangling and strict typing.

new Operator

The prototype for the C++ new operator is:

...

This C++ name mangling issue has been around for years and varies from GCC compiler to GCC compiler, apparently due to some newlib configuration difference.

uint32_t

Similarly, you may find that the definition of uint32_t in NuttX may be incompatible with your toolchain's libraries. You may, perhaps, see errors like:

...

But this now may result in additional problems, now there may be incompatibilities between definition of size_t uses in NuttX and the definition of size_t used in the libraries.

size_t

size_t should be an integer type wide enough to hold the size of the largest memory object. So size_t really depends on the size of the underlying pointer type. For CPUs with 16-bit addressing, for example, the width of size_t should be 16-bits; for CPUs with 32-bit addressing, the width should be 32-bits.

...