Issues with Platform Support wiki page

[straight-shoota]

The Wiki page Platform Support was created a year ago and hasn't seen much change since then. It's still considered a draft. That doesn't need to be changed, but I noticed a few issues, mostly inconsistencies in target names between wiki page and src/lib_c.

• ✅ aarch64-linux-musl was added in Add support for target aarch64-linux-musl #5861. I suppose it should be listed in Tier 2.
• ✅ The wiki page lists x86_64-unknown-openbsd but that target is not available. There is a folder called amd64-unknown-openbsd which seems like the same target. LLVM doesn't know a amd64 architecture on my system (it's x68-64). I suppose the target should be renamed in the source code unless there is some explicit reason for this being amd64?
• ✅ The wiki page lists x86_64-apple-darwin, but the source folder is called x86_64-macosx-darwin
• ✅ The wiki page lists armv6-linux-gnueabihf and armv7-linux-gnueabihf but in the source there is only arm-linux-gnueabihf.
• ✅ x86_64-portbld-freebsd is missing from the wiki page (it's the same as x86_64-unknown-freebsd, though).
• ✅ The wiki page lists x86_64-pc-windows-msvc but the source folder is called x86_64-windows-msvc.

Additionally, since musl is the only way to reliably compile with statically linked libraries, I'd suggest to improve its support level. Mainly, automatic tests would be great.
This shouldn't be very difficult to integrate into CI. Both travis and circle support docker images and the specs can just be executed in an alpine image for i686-linux-musl and x86_64-linux-musl. #6943

For all other targets (at least on Tier 2), there could be a simple smoke test to ensure that the stdlib specs at least compile for that target. It would probably be enough to run this prior to a release (or on nightly), not on every PR.

for target in $(ls -1 src/lib_c/); do
  echo "Cross compiling for $target"
  make .build/std_spec clean FLAGS="--cross-compile --target $target"
done

BTW: I can't edit wiki any pages anymore. Has there been a change to access rights?

/cc @mverzilli @RX14 @bcardiff

[mverzilli]

Thanks for pointing all of these out! Unfortunately, we had to limit the wiki edit permissions due to the recent influx of trolls to our repos. The problem with this is that we're left with no editorial workflow for contributions coming from the community.

One possible follow up would be to delete this page and move the information to the Crystal book. It would sort of make sense because we already have a chapter about installation methods in different platforms.

[wmoxam]

$ uname -a
OpenBSD home.wmoxam.com 6.4 GENERIC.MP#341 amd64
$ llc --version
LLVM (http://llvm.org/):
  LLVM version 6.0.1
  Optimized build.
  Default target: amd64-unknown-openbsd6.4
  Host CPU: skylake

[j8r]

@mverzilli is it possible to limit the Wiki editions only to contributors? It would be nice!

[bcardiff]

It's either a) public or b) restricted to users in teams with push access only. It would be great option, definitely.

[straight-shoota]

@wmoxam That's interesting. It seems like LLVM itself isn't even sure if it's x86-64 or amd64...

LLVM 3.8 on Ubuntu xenial doesn't even know an amd64 architecture:

$ llc -march=amd64 -mattr=help
llc-3.8: error: invalid target 'amd64'.

But it can still compile an object file for that target. Although the Crystal compiler might be changing some things in between, I don't know.

[PanisSupraOmnia]

For the point about arm/armv6/armv7, #4167 is the relevant PR.

[RX14]

Oh, and most of the target triples are normalised wrong:

x86_64-linux-gnu is actually only a double, with the full triple being x86_64-unknown-linux-gnu, with the parts of the triple being x86_64, unknown and linux-gnu (cpu, vendor, OS).

There's an API for LLVM C++ to normalize target triples. I suggest we bind that and normalise all triples early on in the compiler.

[straight-shoota]

I've updated the target names on the wiki page according to #7282. So at least the issues with different naming between the source folder and wiki page are fixed.

Additional issues:

• The wiki page mentions a i686-apple-darwin target in Tier 3, but there is actually no support for 32-bit MacOS at all (see Old Mac OS #3859). I doubt that the compiler works on that target. So I think this should be removed / moved to Other section.
• Still left from the OP: There is support for aarch64-linux-musl target since Add support for target aarch64-linux-musl #5861, but it's not listed on the wiki page. I suppose it should go into Tier 2 like aarch64-linux-gnu?

[j8r]

Yes @straight-shoota , I confirm I can compile statically on the aarch64-linux-musl target. I check on my ARM board sometimes if the binary work.

[straight-shoota]

I removed i686-apple-darwin and added aarch64-linux-gnu to *Tier 2`.

Now the wiki page should be up to date.
There is still a notice at the top which declares this as a draft and refers to a related discussion which does not exist. IMHO we could just remove that paragraph. WDYT?

[KaneRoot]

I see another problem with this page: it is not self-sufficient. To understand how to compile for these architectures, you still have to get to the main documentation. Adding a reference to crystal build --cross-compile --target XXX could be a plus.

Also, this page relates to platform support, but the compiler itself cannot be compiled as easily.

[straight-shoota]

This page is intended as an overview of platform support. It's not a guide about cross compiling. But I suppose a link to https://crystal-lang.org/reference/syntax_and_semantics/cross-compilation.html should do? That page needs a refresh though, too.

Also, this page relates to platform support, but the compiler itself cannot be compiled as easily.

What do you mean by that? Compiler and stdlib are different stories, yes. That's why there are separate columns for them to indicate differences.

[straight-shoota]

The platform support page was transferred in crystal-lang/crystal-book#468 and I don't think there is anything open here anymore.