stddef.h: No such file or directory

[tavianator]

Since updating to r13, I get this:

$ cat bar.cpp
#include <cstddef>
$ /opt/android-ndk/build/tools/make_standalone_toolchain.py --arch=arm --api=21 --install-dir=/tmp/ndk-arm --stl=libc++ --force -v
INFO:__main__:Cleaning installation directory /tmp/ndk-arm
$ /tmp/ndk-arm/bin/arm-linux-androideabi-g++ -c bar.cpp
In file included from bar.cpp:1:0:
/tmp/ndk-arm/include/c++/4.9.x/cstddef:43:25: fatal error: stddef.h: No such file or directory
 #include_next <stddef.h>
                         ^
compilation terminated.

[DanAlbert]

I forgot to call this out in the known issues in the changelog: https://android.googlesource.com/platform/ndk/+/master/tests/build/standalone-toolchain/test_config.py#11

Unfortunately that refers to an internal bug (filed against our GCC folks), but I'll paste some of the relevant details here:

The default header ordering with g++ is (taken from g++ -v):

#include "..." search starts here:
#include <...> search starts here:
 /work/src/ndk/ndk/foo/bin/../lib/gcc/arm-linux-androideabi/4.9.x/include
 /work/src/ndk/ndk/foo/bin/../lib/gcc/arm-linux-androideabi/4.9.x/include-fixed
 /work/src/ndk/ndk/foo/bin/../lib/gcc/../../include/c++/4.9.x
 /work/src/ndk/ndk/foo/bin/../lib/gcc/../../include/c++/4.9.x/arm-linux-androideabi
 /work/src/ndk/ndk/foo/bin/../sysroot/usr/include

Note that the C++ headers come after the compiler headers. libc++ provides its own stddef.h that wraps the compiler's, but the ordering of the default headers prevents that from happening. is found in the middle path, which does an #include_next <stddef.h>, but since include_next only checks the paths that are after where the current header was found, we only search the sysroot and can't find the one in the compiler headers.

Trying to include libc++'s stddef.h instead of cstddef doesn't work either. It doesn't fail, but the compiler finds its own copy rather than the one in libc++.

Clang has the following search order (c++ headers first):

#include "..." search starts here:
#include <...> search starts here:
 /work/src/ndk/ndk/foo/bin/../lib/gcc/arm-linux-androideabi/4.9.x/../../../../include/c++/4.9.x
 /work/src/ndk/ndk/foo/bin/../lib/gcc/arm-linux-androideabi/4.9.x/../../../../include/c++/4.9.x/arm-linux-androideabi
 /work/src/ndk/ndk/foo/bin/../lib64/clang/3.8.256229/include
 foo/bin/../sysroot/usr/include

My system's g++ has the following search order (c++ headers first):

#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.8
 /usr/include/x86_64-linux-gnu/c++/4.8
 /usr/include/c++/4.8/backward
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include

It's a little strange to me that the compiler headers come between the c++ headers and the libc headers. I would think the correct ordering is c++ -> libc -> compiler (in case libc needs to override some compiler headers), but both clang and (non-android) g++ seem to agree on that.

[DanAlbert]

A workaround for this in case the above is tl;dr: Clang is unaffected by this, and GCC will work with the other STLs, and only standalone toolchains hit this. If you're stuck in a situation where you have to use GCC and libc++ and you need to use a standalone toolchain, the only workaround I can think of would be adding -nostdinc to your cflags and then manually specifying the default include paths in the correct order (as they are in the clang example above).

[DanAlbert]

(I'll add this to the known issues list in case anyone else stumbles on to it)

[tavianator]

I would think the correct ordering is c++ -> libc -> compiler (in case libc needs to override some compiler headers)

Well, gcc has a long history of wanting to override your libc's headers, c.f. fixincludes.

If you're stuck in a situation where you have to use GCC

Yep, due to #156. But with all the trouble I've had with thread_local, I'm probably going to migrate to a custom thread_specific_ptr type.

and libc++

Well, I don't have to but it sure is nicer. Better std::string implementation etc.

and you need to use a standalone toolchain

Indeed. But that workaround will work, yeah.

[DanAlbert]

Actually, I did include this in the known issues list: https://github.com/android-ndk/ndk/wiki/Changelog-r13

Standlone toolchains using libc++ and GCC do not work. This seems to be a bug in GCC. See the following commit message for more details: https://android-review.googlesource.com/#/c/247498

[tavianator]

Indeed, a simple -isystem .../ndk/foo/include/c++/4.9.x fixes everything.

Actually, I did include this in the known issues list: https://github.com/android-ndk/ndk/wiki/Changelog-r13

Oops, sorry! Should have read the release notes.

[DanAlbert]

Given GCC's deprecation, this has been moved to the "won't fix" list.

[wangdongxuking61]

change include/c++/4.9.x/cstddef line 44 from #include_next<stddef.h> to #include <stddef.h>

[zyp2014]

将include / c ++ / 4.9.x / cstddef第44行从#include_next<stddef.h>更改为#include <stddef.h>

great

[dq5070410]

great

[SavedByZero]

FYI this issue persists in ndk 21e with the same file -- I'm getting it when I try to compile an OpenCV 4.5.2 plugin using its llvm toolchain and gnu c++ 11. There's a bunch of other errors if I use the fix above (using ::signbit; using ::fpclassify; using ::isfinite, and a bounch of others like isgreater, islessthan, and other comparators are all throwing "no member named ----- in the global namespace")

[DanAlbert]

Gnu libstdc++ hasn't been included in the NDK since r17, so there's your problem.