ARM64-to-ARM32 cross build is broken due to missing OPENSSL_gmtime

[kg]

On some hosts, the rootfs generated for an ARM cross build does not have OPENSSL_gmtime. I've reproduced this on both debian and ubuntu. For me on a brand new ubuntu arm64 vm in Azure, the following steps will repro it:

1. Clone the runtime
2. Install dependencies (clang, cmake, debootstrap) via apt
3. sudo ./eng/common/cross/build-rootfs.sh arm
4. ./build.sh --cross --os linux --arch arm

I also tried an arm64 debian vm but I'm not sure if the failure there was identical, it just didn't work either.

The failure looks like this:

  [  3%] Building C object libs-native/System.Native/CMakeFiles/System.Native-Static.dir/entrypoints.c.o
  In file included from /home/kg/runtime/src/native/libs/System.Security.Cryptography.Native/apibridge.c:4:
  /home/kg/runtime/src/native/libs/System.Security.Cryptography.Native/opensslshim.h:768:15: error: use of undeclared identifier 'OPENSSL_gmtime'; did you mean 'OPENSSL_init'?
    768 | extern TYPEOF(OPENSSL_gmtime)* OPENSSL_gmtime_ptr;
        |               ^~~~~~~~~~~~~~
        |               OPENSSL_init
  /home/kg/runtime/.tools/rootfs/arm/usr/include/openssl/crypto.h:600:6: note: 'OPENSSL_init' declared here
    600 | void OPENSSL_init(void);
        |      ^

Looking through the rootfs, there are no symbols resembling OPENSSL_gmtime anywhere in it. I can't figure out why it's not there - according to openssl documentation this function dates back to 1.0.0 and both OpenSSL and BoringSSL should include it, though it looks like BoringSSL moves it to a different header.

The reference to this missing function is scoped to arm32-on-linux:

#if defined(TARGET_ARM) && defined(TARGET_LINUX)
TYPEOF(OPENSSL_gmtime) OPENSSL_gmtime_ptr;

which is probably why it hasn't caused grief for anyone yet. I think since we typically don't build for arm32 from an arm64 host, we're not hitting it - I guess somehow building an arm32 rootfs from an x64 host gets different headers? debootstrap-in-general seems like a total nightmare I'm struggling to understand (on my debian host debootstrap doesn't even work without manually creating symlinks), so I figure it's worth filing an issue about this.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[kg]

Removing the references to it manually fails the build later:

  [  9%] Building C object /home/kg/runtime/artifacts/obj/external/libunwind/CMakeFiles/libunwind.dir/home/kg/runtime/src/native/external/libunwind/src/mi/Gput_dynamic_unwind_info.c.o
  /home/kg/runtime/src/native/libs/System.Security.Cryptography.Native/opensslshim.c:230:25: error: static assertion failed due to requirement 'sizeof(long) == 8': Build requires 64-bit time_t.
    230 |     c_static_assert_msg(sizeof(time_t) == 8, "Build requires 64-bit time_t.");
        |                         ^~~~~~~~~~~~~~~~~~~
  /home/kg/runtime/src/native/libs/Common/pal_compiler.h:20:52: note: expanded from macro 'c_static_assert_msg'
     20 | #define c_static_assert_msg(e, msg) static_assert((e), msg)

So it seems like the default rootfs for arm32-on-arm64 has 32-bit time_t for some reason.

[kg]

The rootfs appears to ignore _TIME_BITS entirely, so even though we set _TIME_BITS=64 in our build it doesn't do anything. The rootfs I have here has:

#define __TIME_T_TYPE		__SLONGWORD_TYPE

in typesizes.h unconditionally, and

__STD_TYPE __TIME_T_TYPE __time_t;	/* Seconds since the Epoch.  */

typedef __time_t time_t;

[filipnavara]

The reference to this missing function is scoped to arm32-on-linux:

That's specifically because recent distributions started compiling with 64-bit time_t and this makes some things difficult for the portable builds which have to rely on ABI tricks to work on all distributions.

It makes me wonder what is the default distribution for build-rootfs.sh arm since it seems to have picked something ancient or broken.

[kg]

Grepping around led me to sudo ./eng/common/cross/build-rootfs.sh arm jammy no-lldb which appears to fix this, but I still don't have a successful cross build so I can't confirm that's the actual solution.

EDIT: This appears to fix it. So I think we need to change the default for build-rootfs when targeting arm.

[am11]

sudo ./eng/common/cross/build-rootfs.sh arm

should be sudo ./eng/common/cross/build-rootfs.sh arm jammy per https://github.com/dotnet/dotnet-buildtools-prereqs-docker/blob/8bb52e2a2cc565f932ca7fb76abd9a64d0c78018/src/azurelinux/3.0/net9.0/cross/arm/Dockerfile#L8