Fix armel cross build of native part of libraries

[gbalykov]

This fixes build breaks after #31659

cc @alpencolt

[sdmaclea]

These lines shouldn't be needed. Line 190 below should be sufficient. Any reason this is duplicated here?

[gbalykov]

I've updated my commit, this would be a better solution. Problem was that we ended up with

CLR_CMAKE_HOST_UNIX_ARM 1
CLR_CMAKE_HOST_UNIX_ARMV7L 1
CLR_CMAKE_HOST_ARCH_ARM 1
CLR_CMAKE_HOST_ARCH "arm"
CLR_CMAKE_HOST_ARCH_ARMV7L 1

which lead to

CLR_CMAKE_TARGET_ARCH "arm"
CLR_CMAKE_TARGET_ARCH_ARM 1

Now, CLR_CMAKE_HOST_ARCH "armel" and target will be set correctly.

[sdmaclea]

Do you need set(ARM_SOFTFP 1) here to? From your previous discussion, I assume Line 191 below will not be reached.

Or

set(CLR_CMAKE_TARGET_ARCH "armel")

And let the code below set the variables.
OR

set(CLR_CMAKE_HOST_ARCH "armel")

in 141 above. If this would work it seems the cleanest.

[gbalykov]

ARM_SOFTFP=1 is passed from outside for this case (see ./eng/native/gen-buildsys.sh), so it is not needed here.
We can't set neither CLR_CMAKE_TARGET_ARCH to "armel", nor CLR_CMAKE_HOST_ARCH, because we actually can't distinguish armel from arm here (CLR_CMAKE_HOST_ARCH_ARMV7L=1, CLR_CMAKE_HOST_UNIX_ARMV7L=1 for both).

[sdmaclea]

The patch looks good to me.

However the arm build is currently failing with

[  0%] Building CXX object src/pal/src/CMakeFiles/tracepointprovider.dir/misc/tracepointprovider.cpp.o

In file included from /__w/1/s/src/coreclr/src/pal/src/misc/tracepointprovider.cpp:19:

In file included from /__w/1/s/src/coreclr/src/pal/src/include/pal/palinternal.h:159:

In file included from /crossrootfs/arm/usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../../include/c++/4.8/type_traits:38:

In file included from In file included from /__w/1/s/src/libraries/Native/Unix/System.Globalization.Native/pal_calendarData.c:5:

In file included from /crossrootfs/arm/usr/include/assert.h:35:

In file included from /crossrootfs/arm/usr/include/features.h:398:

/crossrootfs/arm/usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-soft.h' file not found

# include <gnu/stubs-soft.h>

          ^~~~~~~~~~~~~~~~~~


/crossrootfs/arm/usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../../include/arm-linux-gnueabihf/c++/4.8/bits/c++config.h:426:

In file included from /crossrootfs/arm/usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../../include/arm-linux-gnueabihf/c++/4.8/bits/os_defines.h:39:

In file included from /crossrootfs/arm/usr/include/features.h:398:

/crossrootfs/arm/usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-soft.h' file not found

# include <gnu/stubs-soft.h>

          ^~~~~~~~~~~~~~~~~~

Scanning dependencies of target libunwind

Perhaps we need an updated crossrootfs?

[gbalykov]

@sdmaclea where is the rootfs created in azure? This patch shouldn't affect arm builds, this seems strange

[sdmaclea]

@sdmaclea where is the rootfs created in azure? This patch shouldn't affect arm builds, this seems strange

The Linux arm builds are built in a docker container that has a rootfs. See eng/pipelines/common/platform-matrix.yml. Linux arm is currently using the ubuntu-16.04-cross-14.04-23cacb0-20200121150126 container. Last I knew these came from https://github.com/dotnet/dotnet-buildtools-prereqs-docker builds.

It is a bit strange. I assume when the tracepointprovider.cpp code was added, armel was broken. So it wasn't properly tested for armel. I am guessing we either need a new rootfs to add the missing development include files and libraries, or we need to disable part of tracepointprovider.cpp for armel.

[gbalykov]

With current setup in master there are some problems. For arm build next variables are setup

CMAKE_SYSTEM_PROCESSOR armv7l

CLR_CMAKE_HOST_UNIX_ARM 1
CLR_CMAKE_HOST_UNIX_ARMV7L 1

CLR_CMAKE_HOST_ARCH_ARM 1
CLR_CMAKE_HOST_ARCH "arm"

CLR_CMAKE_TARGET_ARCH "arm"
CLR_CMAKE_TARGET_ARCH_ARM 1

However, it seems that there is a typo and next vars should be setup as well:

CLR_CMAKE_HOST_ARCH_ARMV7L 1

But CLR_CMAKE_TARGET_ARCH_ARMV7L will never be setup, however, it is required and compilation flags set up under it were used prior to changes in #31659.

So, for HOST we have two different states:

1. CLR_CMAKE_HOST_ARCH="arm", CLR_CMAKE_HOST_UNIX_ARM=1, CLR_CMAKE_HOST_UNIX_ARMV7L=1
2. CLR_CMAKE_HOST_ARCH="arm", CLR_CMAKE_HOST_UNIX_ARM=1, CLR_CMAKE_HOST_UNIX_ARMV7L=0

But these two become indistinguishable for TARGET when we check just CLR_CMAKE_TARGET_ARCH=CLR_CMAKE_HOST_ARCH.

So, either all target flags should be setup when CLR_CMAKE_TARGET_ARCH is copied from host, or additional CLR_CMAKE_TARGET_ARCH="armv7l" should be added (it will include arm soft-fp builds too).

What do you think?

[sdmaclea]

So, either all target flags should be setup when CLR_CMAKE_TARGET_ARCH is copied from host, or additional CLR_CMAKE_TARGET_ARCH="armv7l" should be added (it will include arm soft-fp builds too).

What do you think?

We seem to be missing a mechanism to set armel as the target architecture from the command line. It seems the only way to configure armel is from the HOST processor.

Therefore I am OK with setting this in the HOST section if needed. A comment explaining why would be nice.

Either approach would be acceptable. I am not certain where CLR_CMAKE_HOST_ARCH or CLR_CMAKE_TARGET_ARCH are used precisely, but it seems rational to use armel or armv7l for both host and target for the soft fp case.

[gbalykov]

I've made the changes the same way as in the first version of this PR. armel and arm builds should work now