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.