Add support for powerpc

[vorner]

Define the architecture-dependent syscall numbers (taken from the
corresponding powerpc's header file). This allows compiling and using
the crate for powerpc targets (like the builtin
powerpc-unknown-linux-gnu).

This should probably fix #534 (as well as my problem).

I'm a bit unsure about the correct way to update the changelog. It seems the entries contain the number of pull request, but how do I get it in advance before sending the pull request?

[Susurrus]

I saw some previous discussion on this and shouldn't these numbers be pulled from the libc crate even if they need to be declared as SysCall types in nix?

Re the changelog, you can guess the PR number as it's just the next available number of issues/PRs for the repo. But I've only ever added them after the fact, so that's a good point.

[vorner]

@Susurrus I don't know about any discussion. I basically just tried to cross-compile and got an error, looked into the file it complained about, saw how the other the platforms were handled and stuck with the rest. I'm certainly not the right person to rewrite the whole file as my first submission to this project, though it did strike me as somewhat fragile to hard-code the numbers by hand.

[Susurrus]

I'm referring to #341 which kind of talks about this. I guess we should push this and sort out how we want to address with the syscall constants. If you're interested, it'd be great if you wanted to look into how we might get these constants added to rust-lang/libc. I think they'd be okay with that, but I guess we should start that discussion.

[vorner]

I'd appreciate that approach (pushing this first, and then starting the discussion ‒ the discussion might take some time).

I might come up with an idea or comment, but again, I don't feel like being the right person to start the discussion ‒ basically, there's nearly no relation between me and either crate.

[kamalmarhubi]

I'd appreciate that approach (pushing this first, and then starting the discussion ‒ the discussion might take some time).

This makes sense to me. The syscall revamp is a lot of tedious work, and will probably be a while coming.

[Susurrus]

I'm going to close this in favor of already-existing work done in #553, which covers a few other additional cases as well. If you were willing to look that PR over as well and maybe give it a compilation test locally, @vorner, it'd be most appreciated! Thanks however for filing this PR @vorner!

[vorner]

OK, that's fine with me. I tested the other PR and it solves my problem with compilation. Thank you.