cmake: Don't use -nostdinc with CXX

[SebastianBoe]

It is observed that the C++ standard library headers can not be found
when -nostdinc is used. To fix this we omit -nostdinc when building
for C++.

To reproduce the issue use the latest zephyr master and add

#include <vector>

to the list of includes in samples/cpp_synchronization.

Without this fix the sample will not build for for gnuarmemb or the
Zephyr SDK.

This fixes #15603 and uses the fix suggested here: #15603 (comment)

[galak]

If we do this for C++ why wouldn't we do it for C?

[pabigot]

Generally when using C++ you need CONFIG_NEWLIB_LIBC=y to access the C++ standard headers. In that case this branch is already bypassed, so the fix doesn't work.

[SebastianBoe]

@pabigot : Would you kindly post steps to reproduce (where this fix doesn't work) with the latest Zephyr master and SDK/gnuarmemb versions?

[SebastianBoe]

If we do this for C++ why wouldn't we do it for C?

Using -nostdinc is inherited from the Linux kernel:
https://github.com/torvalds/linux/blob/8e61ea11c23b108c8ce062f791dfa737896da346/scripts/Makefile.lib#L162

Why the linux kernel does this I do not know. IIRC I attempted to get rid of it at some point but was unable to.

That being said, if there are some unwanted side-effects of dropping -nostdinc then I would rather find out in the C++ build than have it crop up in the more mainstream C build.

[pabigot]

Do exactly the case that works with this patch, but instead of #include <vector> use #include <array>.

Using this PR and gcc-arm-none-eabi-8-2019-q3-update the build fails even without adding CONFIG_NEWLIB_LIBC=y, though the cascade of errors is different. With CONFIG_NEWLIB_LIBC=y it fails to find the next stdlib.h as it does without this patch.

I've done some diagnostic builds and there's no difference in compiler/preprocessor invocation between the Zephyr toolchain and the ARM one except the path to the system include directory. There's no obvious difference in the contents of the system include directory, ignoring newlib version 3.1 vs 3.0. There must be a difference in the way gcc and newlib are configured in the Zephyr SDK that changes the behavior.

My setup is:

export ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
export GNUARMEMB_TOOLCHAIN_PATH=/usr/local/gcc-arm-none-eabi
cd /mnt/devel/external/zp/zephyr
. zephyr-env.sh

[pabigot]

I don't see --enable-languages=c,c++ in the SDK builds, which might explain it.

Nor --with-newlib, which could also explain it. There are actually a lot of differences in Zephyr SDK ARM builds from the ARM Embedded build script, including probably some patches to GCC and newlib.

[galak]

Please add a testcase as part of this for using stdlib C++ functionality. So that way we know if this breaks in the future.

Something like:

void test_main(void)
{
	/* Does nothing.  This is a compile only test. */
	vector v;
	std::vector<int> v;

	v.push_back(10);
}

[SebastianBoe]

Closing as this was not the correct approach.