Investigate bindgen woes - "file not found" about cross HOT 9 OPEN

@tniessen short answer is no, cross wouldnt help with a more elegant solution, the solution would be equally applicable with or without cross. I dont think your specific example here is related to what this issue is about, but feel free to open a new issue with more information and maybe we can work something out

from cross.

Can we solve this problem in our images?

Should we add -I/usr/include in all our BINDGEN_EXTRA_CLANG_ARGS_<target>s maybe? One risk I see with this is that we introduce contamination, where the header files could potentially be different for the host architecture and the target architecture. How does clang prioritize the include dirs, right to left?

from cross.

BINDGEN_EXTRA_CLANG_ARGS_<target>=--sysroot=$CROSS_SYSROOT -I/usr/include -v

gives

#include <...> search starts here:
 /usr/include
 /usr/include/clang/10.0.0/include
 $CROSS_SYSROOT/include

clang says

For C++ inputs, if there are multiple -I options, these directories are searched in the order they are given before the standard system directories are searched.

BINDGEN_EXTRA_CLANG_ARGS_<target>=--sysroot=$CROSS_SYSROOT -nostdinc -I$CROSS_SYSROOT/include -I/usr/include works, but disables the std, there's no way to reenable it... we need -ibuiltininc (available on clang-11 and up) I think but that also doesn't to enable the clang includes

#include <...> search starts here:
 $CROSS_SYSROOT/include
 /usr/include

**edit

-idirafter/usr/include is exactly what we want

aarch64-unknown-linux-gnu example

# Cross.toml
[target.aarch64-unknown-linux-gnu.env]
passthrough = ["""BINDGEN_EXTRA_CLANG_ARGS_aarch64_unknown_linux_gnu=--sysroot=/usr/aarch64-linux-gnu -idirafter/usr/include"""]

gives

#include <...> search starts here:
 /usr/lib/llvm-11/lib/clang/10.0.0/include
 /usr/aarch64-linux-gnu/include
 /usr/include

I've updated the first post from using -I/usr/include to be -idirafter/usr/include

from cross.

Should we add -I/usr/include in all our BINDGEN_EXTRA_CLANG_ARGS_<target>s maybe? One risk I see with this is that we introduce contamination, where the header files could potentially be different for the host architecture and the target architecture. How does clang prioritize the include dirs, right to left?

I think -idirafter/usr/include is the way to do this, I don't see much hindering us from adding this to our images

from cross.

Some more investigating, pkg-config strips -I/usr/include as it's a system include path, setting PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 resolves this, I've modified the code to reflect this. I think this is wanted behaviour for the pkg_config crate

root@8f4378f92f97:/# PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config libssl --cflags --libs
-I/usr/include -L/usr/lib/aarch64-linux-gnu -lssl
root@8f4378f92f97:/# pkg-config libssl --cflags --libs
-L/usr/lib/aarch64-linux-gnu -lssl

from cross.

Another issue, should we really use PKG_CONFIG_PATH? From what I can gather, the expected thing to do is to use aarch64-linux-gnu-pkg-config, which discovers the path automatically. It also curiously omits -I/usr/include, very interesting...

from cross.

Some (if not most?) *-dev packages on ubuntu dist only include headers in /usr/include, this means that the BINDGEN_EXTRA_CLANG_ARGS_<target>=--sysroot=$CROSS_SYSROOT

I'm not entirely sure of the problem this issue is about, since not all containers use the same approach. Since you mention using Ubuntu's -dev packages, I assume you're talking about containers for targets using dpkg's foreign-architecture support, but then it seems to be the sysroot is just / so there should be no problem to start with. So I'm basically confused :)

from cross.

Maybe I'm the one that is confused, we set the env var in #707

I was under the impression that it was needed, but maybe it wasn't needed for every target, and only needed for android

from cross.

bindgen can't properly find these headers if the *-sys-crate doesn't use pkg-config probing

@Emilgardis In my case, I'm using bindgen with some C header files that do not belong to any pre-installed library, so as far as I know, I cannot reasonably use pkg-config. However, with default configuration only, this results in errors such as fatal error: 'stddef.h' file not found. (The reason is that the Rust crate needs to be aware of the memory layout of some C data structures, but it does not actually link against any C library.)

This works just fine with the default toolchain/target, but cross-compiling without cross requires manual modifications of the include path. Is there a more elegant solution now that I'm trying to use cross?

from cross.