Make newlib libc the default c library

[zephyrbot]

Reported by Anas Nashif:

Set zephyr to build with newlib by default, not minimal libc.

See https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-January/007017.html and the tread started with this message.

(Imported from Jira ZEP-1646)

[zephyrbot]

by Mark Linkmeyer:

Hi Kumar Gala , I see you were assigned this high-priority story yesterday. Just a reminder that per our defined Release Criteria, the goal is to have all high-priority stories in Code Review by next week's M2 milestone.

[zephyrbot]

by Anas Nashif:

The whole discussion around this jira can be found here: https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-January/007017.html

[zephyrbot]

by Kumar Gala:

Made changes to base types to use u{8,16,32,64}_t and s{8,16,32,64}_t, but need to resolve issues when external libs that use C99 types.

[zephyrbot]

by Nirmala Devi M:

Hi Anas Nashif , Can you please provide us with little more information on this jira. Do we need to add any new test case to test this feature? If so can you provide some information.

[zephyrbot]

by Mark Linkmeyer:

Anas Nashif , please see Nirmala Devi M 's question to you above.
Kumar Gala , this story has been sitting in "In Progress" since April when Anas moved it there. is this story on track to be implemented before the merge window closes in two weeks?
Thx.

[pfalcon]

Making newlib the default library leads to various concerns, see e.g. #5822 and #5570 (review) .

Instead of making newlib the default, we could concentrate on supporting 2 polar configuration (well, we could support more, but that's the burden of development and maintenance, and usually application optimize for one or another thing either):

1. Have the very minimal library, optimizing for code size - that's the current minimal libc.
2. Have an as compliant to ANSI C and POSIX libs as possible - that's newlib, with tweaks like libc: Make printf() work out of the box with Newlib #5822.

2. is going to bring overhead (it already does), so 1) can stay the default. The point is that if people enable "real" libs, it works like a real libc, not require to haunt bunch of other options to make it work like so. (But we can support options to disable extra options, to let people optimize for e.g. final product.)

[pfalcon]

(it already does)

E.g. #5854 (comment) :

+~3.5K due to newlib vs minimal libc.

[pkral78]

Regarding newlib as default library.

The problem is that newlib in some default preconfigured/compiled form is included with toolchain (as ABI dependency). That default configuration should not be sufficient because:
1.) it may differ version/vendor to version/vendor of toolchain
2.) doesn't support reentrancy by default

So I suggest that newlib should be preconfigured/precompiled for Zephyr projects that want to use it, which means:

1.) Implement various newlib hooks aka struct _reent *_getreent(); using thread local impure_ptr.
2.) Configure newlib build using --enable-newlib-multithread, --enable-newlib-reent-small, -D__DYNAMIC_REENT or maybe -DMALLOC_PROVIDED
3.) build newlib (debug and release version)
4,) supply it to toolchain using --sysroot flag

[pkral78]

I've already done something similar for company's RTOS using cmake's ExternalProject_Add.
The tricky part was how to substitute libraries it produces to toolchain's linker with cmake.
It is neccessary to use plain ld, not gcc frontend as it already preconfigure lib dirs to toolchain itself.

I end up with something like this for gcc:
`
execute_process(
COMMAND ${CMAKE_C_COMPILER} ${CMD_ARCH_FLAGS} -print-libgcc-file-name
OUTPUT_VARIABLE GCC_LIB_FILE)

execute_process(
COMMAND ${CMAKE_C_COMPILER} ${CMD_ARCH_FLAGS} --print-multi-directory
OUTPUT_VARIABLE VAR_LIB_DIR)

get_filename_component(GCC_LIB_FILE ${GCC_LIB_FILE} ABSOLUTE)
get_filename_component(GCC_LIB_DIR ${GCC_LIB_FILE} DIRECTORY)
set(NEWLIB_LINK_DIR ${GCC_LIB_DIR} ${NEWLIB_TARGET_DIR}/arm-none-eabi/lib/${VAR_LIB_DIR})

link_directories(${NEWLIB_LINK_DIR})
`
However it should be noted, that I have done it only for armv7m & co. and only for gcc toolchain (not even tried it with llvm/clang).

[pkral78]

@nashif @pfalcon There was some discussion about it on IRC. So just to be mentioned. My PoV is to have newlib configurable from application perspective. Now this configuration is hardcoded in a SDK recipe.

[nashif]

not going to happen