briansmith
Add QNX support
-
getrandomsupports 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).
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.
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/.
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.
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.
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.
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.
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.
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.
Can this PR be merged ? I have ran the tests on qnx 8.0 and all the tests are passing. test_output.txt I do not think it's possible to have the SDK download steps in the CI as its based on a registration on the QNX portal.
Can this PR be merged ? I have ran the tests on qnx 8.0 and all the tests are passing. test_output.txt I do not think it's possible to have the SDK download steps in the CI as its based on a registration on the QNX portal.
Please see PR #2684, which removes LINUX_ABI from build.rs since this seems to trip people up. I plan to merge that PR and then if people want to add QNX support, they can add it to the appropriate lists where they think the QNX ABI exactly matches the Linux ABI. In particular, it would be good to see test results for AArch64, 32-bit ARM, 32-bit x86, and/or x86-64 depending on which lists we add QNX to. It seems there's no hope for having CI for QNX so we'll just have to hope it works, I guess.