[NativeAOT-LLVM] [Question]: why is c++ 11 not installed in the root fs on the linux distros?

[yowl]

When using the docker image mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-cross-amd64-net9.0 there is:

root [ /runtime ]# ls /crossrootfs/x64/usr/include/c++
5  5.4.0  v1
root [ /runtime ]# ls /usr/include/c++
13.2.0

This means that for example the stdc++ header <optional> is not available in the ROOTFS_DIR. We need it to compile the LLVM headers. Is it simply the case that up till now nothing has required c++ headers from a later version of c++, and if so any suggestions about the way forward?

Thanks.

[dicej]

FYI, I believe the directory names under e.g. /usr/include/c++ correspond to the compiler version (e.g. GCC 13.2.0 in the listing you provided above), which doesn't correspond to the C++ standard version (e.g. c++11, 14, 17, etc.). You'd need to cross-reference the compiler vendor and version with the C++ standard(s) it supports to get a complete picture.

[yowl]

Thanks, there is an optional under v1 but clang-18 is going for the /usr/include/c++/5/ directory, must be a way to make it use v1.

[yowl]

-isystem might be enough I guess.

[jkotas]

This cross-complication image is setup to target libraries (including standard C++ library) from Ubuntu 16. It looks like that standard C++ library is too old to compile LLVM.

@jkoritzinsky have been looking into options for how we can use the new standard C++ library for these cross-compilation images using static linking. @jkoritzinsky Do you have any suggestions here? (Note that this is experimental project, so it is ok to cut some corners here to make things work.)

[jkoritzinsky]

I think due to the issues we found when trying to consume libc++, I think we need a slightly different solution. The best solution would be to make a new image that contains a statically-linkable libc++ as we talked about for dotnet/runtime.

For now, I'd recommend using the "-sanitizer" image and passing the CxxStandardLibrary=libc++ property to the native components build. This would depend on LLVM being built with the same standard library.

Another alternative would be to manually link against the dotnet/llvm-project libc++ (if that's where llvm is coming from) with the same options that Mono uses.

[yowl]

Thanks, and I would need to install and build LLVM under the cross root (ROOTFS_DIR) ?

[jkoritzinsky]

You'd need to build LLVM against the rootfs, yes.

[yowl]

Thanks, bit of a follow up , _libc_fpstate is defined

struct _libc_fpstate
{
  unsigned long int __ctx(cw);
  unsigned long int __ctx(sw);
  unsigned long int __ctx(tag);
  unsigned long int __ctx(ipoff);
  unsigned long int __ctx(cssel);
  unsigned long int __ctx(dataoff);
  unsigned long int __ctx(datasel);
  struct _libc_fpreg _st[8];
  unsigned long int __ctx(status);
};

which doesnt have padding nor __glibc_reserved1 which

https://github.com/dotnet/runtimelab/blob/53342bee4b89a6c066d6eb3c7549028ca479c451/src/coreclr/pal/src/include/pal/context.h#L356-L360

doesn't like.

[yowl]

i.e.

In file included from /runtime/src/coreclr/pal/src/debug/debug.cpp:32:
  /runtime/src/coreclr/pal/src/include/pal/context.h:419:66: error: no member named 'padding' in '_libc_fpstate'
    419 |     return reinterpret_cast<_fpx_sw_bytes *>(&FPREG_Fpstate(uc)->FPSTATE_RESERVED[12]);
        |                                               ~~~~~~~~~~~~~~~~~  ^
  /runtime/src/coreclr/pal/src/include/pal/context.h:359:26: note: expanded from macro 'FPSTATE_RESERVED'
    359 | #define FPSTATE_RESERVED padding
        |                          ^
  1 error generated.

[jkotas]

As a quick workaround, you can try disabling XSTATE_SUPPORTED in src\coreclr\pal\src\CMakeLists.txt.

[yowl]

As a quick workaround, you can try disabling XSTATE_SUPPORTED in src\coreclr\pal\src\CMakeLists.txt.

Thanks, that works

[yowl]

Can I go to the "host" root, to get libraries, e.g. for

../../../bin/llvm-min-tblgen: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

This lib is not in the sysroot, can I assume the host arch is the same as the sysroot?