set proper triplets for Windows

[cocoa-xu]

This PR should partially address the issue reported in #8767.

As described in #8767, ideally the following should return a triple like x86_64-pc-windows.

1> erlang:system_info(system_architecture).
"x86_64-pc-windows"

As this is what's described in the official docs:

system_architecture
 Returns a string containing the processor and OS architecture the emulator is built for.

But changing this from win32 to x86_64-pc-windows for AMD64 Windows and i686-pc-windows for 32-bit Windows could lead to a large blast radius -- I can imagine that many libraries would have to update their code.

However, it's still fixable for ARM64 Windows as there isn't an official build/release of Erlang/OTP for ARM64 Windows yet, so newer and existing libraries can adapt to this if they decide to support ARM64 Windows.

[github-actions]

CT Test Results

    3 files    141 suites   49m 23s ⏱️
1 597 tests 1 548 ✅ 49 💤 0 ❌
2 306 runs  2 237 ✅ 69 💤 0 ❌

Results for commit cea3638.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

[garazdawi]

A missing makefile dependency made CI use the cache when it should not, so this error was not detected by github actions. The fault caused all system_architectures to becomes aarch64-pc-windows :)

[cocoa-xu]

Actually... although it won't cause issues for x86/x64 Windows but if I'm not mistaken, some files produced during compile-time are put in directories like $(PRIVDIR)/lib/$(TARGET) and their paths are dynamically generated using erlang:system_info(system_architecture), for example: lib/asn1/src/asn1rt_nif.erl

     Status = case erlang:load_nif(Lib, ?ASN1_NIF_VSN) of
          ok -> ok;
          {error, {load_failed, _}}=Error1 ->
               ArchLibDir =
               filename:join([PrivDir, "lib",
                    erlang:system_info(system_architecture)]),
               Candidate =
               filelib:wildcard(
                    filename:join([ArchLibDir,LibName ++ "*" ]),
                    erl_prim_loader),
               case Candidate of
               [] -> Error1;
               _ ->
                    ArchLib = filename:join([ArchLibDir, LibName]),
                    erlang:load_nif(ArchLib, ?ASN1_NIF_VSN)
               end;
          Error1 -> Error1
          end,

A better solution is to change the value of OVERRIDE_TARGET in otp_build:

    if [ X"$X64" = X"true" ]; then
        echo_setenv OVERRIDE_TARGET win32 ';'
        echo_setenv CONFIG_SUBTYPE win64 ';'
    elif [ X"$ARM64" = X"arm64" -o X"$ARM64" = X"x64_arm64" ]; then
        echo_setenv OVERRIDE_TARGET aarch64-pc-windows ';'
        echo_setenv CONFIG_SUBTYPE "$ARM64" ';'
	else
        echo_setenv OVERRIDE_TARGET win32 ';'
    fi

Yet there're also quite a few places are using the hard-coded win32... for example, erts/emulator/openssl/openssl.mk

ifeq ($(TARGET), win32)
OPENSSL_LIB = $(OPENSSL_OBJDIR)/$(OPENSSL_LIB_NAME).lib

It won't be too hard to find all these cases and make corresponding changes, but I'm not quite sure if I should go this route...

[jhogberg]

Thanks for the PR!

Unless we shove ARM64 Windows under "win32" as well, I don't think there's much we can do about needing to make changes throughout the build system. There doesn't appear to be that many places though, and they ought to check $OPSYS rather than $TARGET since they apply Windows-specific yet architecture-agnostic tweaks.

I don't expect having erlang:system_info(system_architecture) return something like "x86_64-pc-windows" to be very problematic either, as it returns a string and not more structured data: I'd expect most people to use os:type() or similar for checking these things in code.

We'd have to discuss it though. :-)

[wojtekmach]

I'm looking forward to this change!

One change I recently did in https://github.com/erlef/otp_builds was to exactly standardize on the target triple, these macOS builds now report erlang:system_info(system_architecture) as x86_64|aarch64-apple-darwin and it exactly matches the URL of these builds too: https://github.com/erlef/otp_builds/releases/download/OTP-27.1.2/otp-aarch64-apple-darwin.tar.gz.

If you'd consider publishing windows aarch64 builds, given we already have files like otp_win64_27.1.2.zip, I'm curious if it'd be something like otp_win64_aarch64_{vsn}.zip? If at this point you'd have to invent a new pattern anyway, perhaps it's worth considering similar idea to above, otp-{target}.zip, i.e. otp-aarch64-pc-windows.zip and ideally backfilled to previous releases. (It would be wasteful, keeping two identical files with just different names and in hindsight, #8787 could have been a perfect opportunity to introduce the new pattern.) Btw, an advantage of removing the version from the filename is the following, GitHub gives us two URLs to download artifacts one with the release name and one for latest release:

• https://github.com/erlang/otp/releases/download/OTP-27.1.2/otp_win64_27.1.2.zip
• https://github.com/erlang/otp/releases/latest/download/otp_win64_27.1.2.zip

so in this hypothetical new pattern, https://github.com/erlang/otp/releases/latest/download/otp-aarch64-pc-windows.zip would just work (without first knowing what is the latest version) which would be a really nice-to-have for tools like http://elixir-install.org and https://github.com/tsloughter/beamup.

This is all fairly niche so it's probably not worth it to break the existing pattern but I thought I'd mention this on an off chance that it doesn't really matter one way or another so might as well.

[jhogberg]

Thanks for the PR!

Unless we shove ARM64 Windows under "win32" as well, I don't think there's much we can do about needing to make changes throughout the build system. There doesn't appear to be that many places though, and they ought to check $OPSYS rather than $TARGET since they apply Windows-specific yet architecture-agnostic tweaks.

I don't expect having erlang:system_info(system_architecture) return something like "x86_64-pc-windows" to be very problematic either, as it returns a string and not more structured data: I'd expect most people to use os:type() or similar for checking these things in code.

We'd have to discuss it though. :-)

An update: we'd like to have proper triplets for all architectures on Windows too, with $OPSYS instead of $TARGET checked for Windows-specific stuff where applicable. Can you update the various parts of the build system so that it continues to work?

[cocoa-xu]

we'd like to have proper triplets for all architectures on Windows too, with $OPSYS instead of $TARGET checked for Windows-specific stuff where applicable. Can you update the various parts of the build system so that it continues to work?

Absolutely no problem! I was worried that maybe Erlang/OTP would prefer to keep the old conventions for 64bit Windows so I haven't changed anything. I'll update the PR during the weekend or next week!

[cocoa-xu]

Actually fixing this by using $OPSYS instead of $TARGET is much trickier than I originally thought...I wonder if the following fix is acceptable for now while I spend more time fixing all the relevant parts (in another PR)

if ($architecture eq "win32") {
  if (%ENV{"CONFIG_SUBTYPE"} eq "arm64" || %ENV{"CONFIG_SUBTYPE"} eq "x64_arm64") {
    $architecture = "aarch64-pc-windows";
  } elsif (%ENV{"CONFIG_SUBTYPE"} eq "win64") {
    $architecture = "x86_64-pc-windows";
  } elsif (%ENV{"CONFIG_SUBTYPE"} eq "win32") {
    $architecture = "i686-pc-windows";
  }
}

The attempt to use $OPSYS instead of $TARGET is on my cx-win-test branch, but there're a few issues to be addressed.

[jhogberg]

We're not in any rush, OTP 28 is over half a year away so you can take as much time as you need. Otherwise, if this is blocking other work, that minimal fix looks alright for now. :-)

[cocoa-xu]

that minimal fix looks alright for now. :-)

Okay, maybe we can merge one for now if the name of these standardized triplets looks good to you! I'll squash the commits into a single one and change the PR title in a minute.

I'll list the issues/questions I had when I was attempting to using $OPSYS in a new PR soon!

[jhogberg]

Great, I'll add it to our nightly builds tomorrow :)