Using include_directories(SYSTEM... for openssl and curl breaks cross compilation for Yocto Linux

[Tragetaschen]

While taming the build process to run in a Yocto Linux cross compile environment, one road block was the explicit inclusion of the curl and openssl include directories here and here.

The effect of these statements is (with clang 3.9.1) that the ${SYSROOT}/usr/include folder (where curl and openssl headers reside in a Yocto build environment) becomes an -isystem parameter to clang and this reorders that folder above the C++ include folders. When clang now tries to resolve C++ header files, it fails on an #include_next <stdlib.h>, because that file isn't found in a folder that comes after the C++ header folders.

Blaming the two CMakeLists points to build issues for OSX and BSD, but I cannot build for those targets. Otherwise I would check if the entire include_directories statement is actually necessary, or if removing the SYSTEM argument still makes the build succeed (it should).

See also dotnet/core-setup#1598

[karelz]

@Tragetaschen what is the issue tracking? A bug? Ask for enhancement? Or a question? (sorry, I didn't get it from your description)

[Tragetaschen]

I would argue for "Bug", because it breaks "my" cross-compile build.

The "SYSTEM" option is meant for "special" cases, not for just regular include directories: https://cmake.org/cmake/help/v3.0/command/include_directories.html

[wtgodbe]

@Tragetaschen is this still causing you issues?

[karelz]

cc @wfurt

[wfurt]

do you have recipe one can try @Tragetaschen? Better Yocto support was discussed before but right now it is not supported platform so it is hard to keep everything in good shape.

[Tragetaschen]

@wfurt There's a recipe for .NET Core 2.1 on linux-arm in my layer: https://github.com/Tragetaschen/meta-aspnet/tree/master/recipes-dotnet/dotnet-source-build
The layer currently only supports Yocto pyro. Newer versions (sumo or thud at least) fail with the included version of lttng-ust (https://github.com/dotnet/coreclr/issues/19025).

I'm planning on updating to 2.2 "soon" when my current project has calmed down.

[Tragetaschen]

I have updated the recipe to use the 2.2.3 source-build git tag.

The relevant patch is this: https://github.com/Tragetaschen/meta-aspnet/blob/5438f4c3dbabb4d0f23f11066a8c5e5aac385721/recipes-dotnet/dotnet-source-build/files/0001-corefx-CMake-adaptions.patch#L63-L75

The error during build without that patch

  [ 55%] Building C object System.IO.Compression.Native/CMakeFiles/System.IO.Compression.Native-Static.dir/[…]/src/corefx/src/Native/AnyOS/brotli/dec/state.c.o
  In file included from /[…]/src/Native/Unix/System.Security.Cryptography.Native/openssl.cpp:18:
  In file included from /[…]/recipe-sysroot/usr/lib//arm-target-linux-gnueabi/8.2.0/../../../include/c++/8.2.0/memory:80:
  In file included from /[…]/recipe-sysroot/usr/lib//arm-target-linux-gnueabi/8.2.0/../../../include/c++/8.2.0/bits/unique_ptr.h:37:
  In file included from /[…]/recipe-sysroot/usr/lib//arm-target-linux-gnueabi/8.2.0/../../../include/c++/8.2.0/tuple:39:
  In file included from /[…]/recipe-sysroot/usr/lib//arm-target-linux-gnueabi/8.2.0/../../../include/c++/8.2.0/array:39:
  In file included from /[…]/recipe-sysroot/usr/lib//arm-target-linux-gnueabi/8.2.0/../../../include/c++/8.2.0/stdexcept:39:
  In file included from /[…]/recipe-sysroot/usr/lib//arm-target-linux-gnueabi/8.2.0/../../../include/c++/8.2.0/string:52:
  In file included from /[…]/recipe-sysroot/usr/lib//arm-target-linux-gnueabi/8.2.0/../../../include/c++/8.2.0/bits/basic_string.h:6391:
  In file included from /[…]/recipe-sysroot/usr/lib//arm-target-linux-gnueabi/8.2.0/../../../include/c++/8.2.0/ext/string_conversions.h:41:
  /[…]/recipe-sysroot/usr/lib//arm-target-linux-gnueabi/8.2.0/../../../include/c++/8.2.0/cstdlib:75:15: fatal error: 'stdlib.h' file not found
  #include_next <stdlib.h>
                ^~~~~~~~~~
  1 error generated.

[ViktorHofer]

Any suggestions how to continue with this? @Tragetaschen if you think something is broken in our scripts would you mind to submit a PR? Even though the OS isn't officially supported, if the fix is straightforward, we can take it.

[Tragetaschen]

When I last looked, the git blame mentioned macOS as the reason to introduce these include directories where I cannot build. I will migrate the Yocto recipe to .NET Core 3 once it's released and then check what's necessary and create a pull request using its CI to see if macOS actually needs SYSTEM include or if a regular one is sufficient.

Hopefully by that time the migration to one repository is already finished :)

[ViktorHofer]

@Tragetaschen do you have time to verify if this is still broken? Thanks.

[Tragetaschen]

Upon reviewing, 47d738a should have fixed this issue here as well