Cross-compiler binary distribution configure script requires --target flag

Currently when one attempts to install a cross-compiler bindist, one must pass --target=... to the bindist configure. Ideally the configure script would already know the target platform.

added Pnormal Tbug configure script cross-compilation packaging labels

Bizarrely, it is actually necessary to pass both --target=$triple and --host=$triple to the bindist configure script. The latter seems to be necessary to get configure to find CC while the former is needed to find ar.

mentioned in issue #22058

Passing --target is also necessary to get the configure script to correctly detect whether we are trying to install an x86 or aarch64 compiler on darwin (and shouldn't be necessary for the same reason).

changed milestone to %9.6.1

added Phigh label and removed Pnormal label

assigned to @mpickering

In the distrib/configure.ac.in script we already set the bootstrap_target varible, which precisely records what the target for the compiler we are going to install is. It seems we should just set target = bootstrap_target and be done with it.

It seems this logic should already work via FPTOOLS_SET_PLATFORM_VARS and FPTOOLS_OVERRIDE_PLATFORM_FROM_BOOTSTRAP.

I try this locally on a darwin machine, and it seems to select the right platform even though it would otherwise think the system was aarch64.

checking build system type... aarch64-apple-darwin22.1.0
checking host system type... aarch64-apple-darwin22.1.0
checking target system type... aarch64-apple-darwin22.1.0
build platform inferred as: x86_64-apple-darwin
host platform inferred as: x86_64-apple-darwin
target platform inferred as: x86_64-apple-darwin
configure: GHC build : x86_64-apple-darwin
configure: GHC host : x86_64-apple-darwin
configure: GHC target : x86_64-apple-darwin

Probably the issue is that we don't pass --target to the linker.

make show VALUE=SettingsCCompilerLinkFlags 
SettingsCCompilerLinkFlags="-Wl,-no_fixup_chains"

Well the issue is that we still decide --target=aarch64-darwin which is then passed as a C compiler flag.

 ,("C compiler flags","--target=aarch64-apple-darwin ")

The issue appears to be that $LlvmTarget is set to aarch64-.. rather than the correct x86..

And the problem here is that GHC_LLVM_TARGET_SET_VAR has incorrect values for $target_cpu, $target_vendor and $target_os.

checking x86_64-apple-darwin aarch64 apple darwin22.1.0

I think the correct fix is to use $TargetCPU, $TargetOS and $TargerVendor which are all set by FPTOOLS_SET_PLATFORM_VARS via FPTOOLS_OVERRIDE_PLATFORM_FROM_BOOTSTRAP.

This then means we don't ever use a raw $target_* in our configure script.

For cross-compiling it seems incorrect that FPTOOLS_OVERRIDE_PLATFORM_FROM_BOOTSTRAP sets variables like HostOS from $bootstrap_target, but I restrict my scope now for the darwin issues which seem related but not the end of the matter.

But using TargetPlatform rather than target_platform seems incorrect as $LlvmTarget is calculated from the canonical gnu triple rather than the TargetPlatform GHC triple.

It would seem to me that we should calculate the LlvmTarget from the GHC naming of platforms rather than the canonical version. That way we don't have bugs like this where we don't respect the value of bootstrap_target.

There are special cases in GHC_LLVM_TARGET which I don;t feel comfortable changing. It seems the most direct fix is to add a special case for whether bootstrap_target is set and use that instead of $target_cpu etc

I think the easiest thing to do for an immediate fix is to add bootstrap_llvm_target and use that conditionally when trying to set LlvmTarget.

mentioned in commit 5ad22a80

mentioned in commit 490caaea