Add QNX support

[szclsya]

• getrandom supports QNX, so we can just use that (see getrandom's readme)
• QNX uses ELF just like *BSD and Linux (see QNX doc on shared objects), thus add it to the LINUX_ABI list so that we won't have missing symbols defined in ASMs during linking

QNX is currently a tier 3 target (see rustc - nto-qnx).

[briansmith]

Is there any way to test this on a Linux machine? Is there any way you could update mk/cargo.sh (and mk/install-build-tools.sh?) to enable local testing of it, at least? Especially if we want to enable the assembly language.

[szclsya]

For testing builds we will need:

• compile a rustc for it, since it's tier 3 and rustup doesn't have a prebuilt one
• a qnx sdk license in CI secrets (since it will still need to be linked with their compiler, see rustc's platform support page for qnx). It's free for non commercial but the process is kinda tedious

Does that sound okay for you? Since I know it's quite a burden to jump through their licensing hoops. If it's okay I can add the sdk setup and rustc compilation steps in mk/.

[briansmith]

If it's okay I can add the sdk setup and rustc compilation steps in mk/.

As much documentation, especially executable documentation, we can add, the better.

I think we should add a note to BUILDING.md about this platform, noting we don't/can't test it in CI.

[szclsya]

I think we should add a note to BUILDING.md about this platform, noting we don't/can't test it in CI.

My bad, I meant it is possible to run the build in CI, but it will require registering a qnx account, get a license and store credentials in this repo's ci secrets so we can install qnx's sdk. And then we can do the rustc compilation and test building rings with them.

Or if this is too much we can just add some documentations, since it's only tier-3 right now it should be good enough.

[briansmith]

If you can do all those steps and get it to work in your fork's GitHub Actions, that would be great.

My use of QNX for this purpose wouldn't be "non-commercial," probably.

[briansmith]

In other words, if you can submit the PR so that it will work if/when I get a QNX license, then we can decide whether to keep the CI enabled in the main fork (this one) or not, or to comment it out but with everything ready to go if the license situation changes.

[szclsya]

Gotcha. I'll try to make it work on my fork first then.

[SebastianSchildt]

@mikehaller this may be of interest for you

[briansmith]

Gotcha. I'll try to make it work on my fork first then.

I think I worded my comment badly. What I mean is that, if you update the PR so that it contains the install-build-tools.sh/cargo.sh changes, then we can merge them, without testing QNX in CI.

If you can post the changes, then the other interested parties mentioned above might be able to test them out.

[szclsya]

Ah gotcha. I'm quite occupied rn but I will try something once I have time.

It should be just a matter of downloading their SDK. The difficult part would be build rustc as it's tier 3 target right now.