New release

[am11]

The Sysroot Release 20181213 Version 1 is using older kernel, which is breaking us ingesting SmartOS packages (such as zlib) in .NET, ever since we made this change: dotnet/arcade@4900886 (download dependencies from trunk instead of 2020Q1 repository). Luckily, we have older docker images persisisting in container repository for cross-building so it is not a blocker. :)

It would be nice if we get the new release with updated kernel and toolchain, so we don't run into errors like:

# bash on linux-x64

$ git clone https://github.com/dotnet/runtime --single-branch --depth 1; cd runtime

$ URN=mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-18.04-cross-illumos-20220813234406-f13d79e
$ docker run -v$(pwd):/runtime -e ROOTFS_DIR=/crossrootfs/x64 $URN \
    /runtime/build.sh clr -cross -os illumos -gcc

...
  [100%] Building CXX object Corehost.Static/CMakeFiles/singlefilehost.dir/runtime/src/native/corehost/corehost.cpp.o
  [100%] Linking CXX executable singlefilehost
  /crossrootfs/x64/bin/../lib/gcc/x86_64-sun-solaris2.10/8.4.0/../../../../x86_64-sun-solaris2.10/bin/ld: /crossrootfs/x64/lib/libz.so: undefined reference to `__stack_chk_fail@ILLUMOS_0.37'
  /crossrootfs/x64/bin/../lib/gcc/x86_64-sun-solaris2.10/8.4.0/../../../../x86_64-sun-solaris2.10/bin/ld: /crossrootfs/x64/lib/libz.so: undefined reference to `__stack_chk_guard@ILLUMOS_0.37'
  collect2: error: ld returned 1 exit status
  Corehost.Static/CMakeFiles/singlefilehost.dir/build.make:1858: recipe for target 'Corehost.Static/singlefilehost' failed
  make[2]: *** [Corehost.Static/singlefilehost] Error 1

(with older image; URN=mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-18.04-cross-illumos-20220531132048-f13d79e which was created using older zlib and mit-krb5 packages, the build succeeds)

[jclulow]

Do you know what version of illumos the trunk packages are built against? cc @jperkin

[am11]

v0.37 I think; going by the error log __stack_chk_fail@ILLUMOS_0.37'.

[jclulow]

That's a symbol version in a specific library, but not enough to identify the whole OS image. From what I recall, pkgsrc trunk binaries are built on a particular SmartOS platform which will have a release datestamp.

[jperkin]

Hi, they're built on joyent_20210826T002459Z.

[am11]

Thank you. For .NET's purposes, we do not need compatibility older than illumos 2021.

Toolchain: (non-mandatory) if possible, would be nice to have newer compiler toolchain (preferably the latest, gcc-12) in sysroot release, as newer ones come with improved code analyzers.

[am11]

Hey guys, I hope this message finds you well. I just wanted to follow-up since @gwr is looking to continue on the dotnet/runtime port effort; if we could get the new'ish sysroot build, we would be be able to utilize the newer versions dependencies (like libz) as those are stuck in time. 🥲

[jclulow]

Toolchain: (non-mandatory) if possible, would be nice to have newer compiler toolchain (preferably the latest, gcc-12) in sysroot release, as newer ones come with improved code analyzers.

The compiler you're using doesn't come from the sysroot. It must be built as part of your docker image, right?

[am11]

Yup, I can use the v14. I was wondering if there are any known issues with the bleeding edge version (last time you confirmed v8.4 is what Rust is using and we can trust it). But I guess we will find out. 😅

[gwr]

Using gcc 14 might expose compatibility problems with target system headers. How about gcc 10.4 for now?

…

On Fri, Jun 28, 2024 at 2:28 AM Adeel Mujahid ***@***.***> wrote: Yup, I can use the v14. I was wondering if there are any known issues with the bleeding edge version (last time you confirmed v8.4 is what Rust is using and we can trust it). But I guess we will find out. 😅 — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG33HBXKYD7WASXUV75F7DZJT67XAVCNFSM6AAAAABJ7XG5XOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJWGIZTAOBZGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[am11]

gcc-10 with latest (or new enough) kernel sounds good. 👍

[gwr]

The question of "what gcc version does the target use" is a little complex.

The base OS uses gcc 10.4 (with patches to allow system tools to see all function calls with args and return values etc, even in production code). Some details about those OS-specific patches for gcc are in IPD-7 if you're curious.
Those features are very helpful for tracking down problems.

Most user-level applications and libraries are built with a later version of gcc as chosen by the distribution.
OmniOS/CE r151046 (and r151048) is using gcc 12.2.0 (with OS-specific patches as described above)

$ gcc --version
gcc (OmniOS 151046/12.2.0-il-0) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc. ...

OpenIndiana ("hipster 2024") is using gcc 13.3.0:

$ gcc --version
gcc (OpenIndiana 13.3.0-oi-0) 13.3.0
Copyright (C) 2023 Free Software Foundation, Inc. ...

I'd suggest being a bit conservative, and go with gcc 12.2 or 12.3 with the illumos patches
as described in IPD-7
OmniOS offers a fairly light-weight method of building that (with patches) in omnios-build...gcc12
Similarly gcc-10.x (with patches) is also in omnios-build...gcc10

Let me know if I can help with that in any way.
Thanks.

[am11]

I think we are fine with whichever compiler version is available, just need the new build of sysroot with kernel version supporting the symbols error.

side note: on other community-supported targets (freebsd, linux-s390x etc.), we are using clang from host with --gcc-toolchain set to $ROOTFS_DIR/usr and -sysroot set to $ROOTFS_DIR to enable cross-compilation. clang provides multi-target so host clang 18 works for many targets. However, this is not a requirement just a good-thing-to-have.