Make changes needed to build on musl

[andrewliebenow]

No description provided.

[andrewliebenow]

I only checked that the project builds on "x86_64-unknown-linux-musl". This is pretty ugly, but maybe someone will want to use this as a starting point re: musl support.

[jgarzik]

Neat! I'll think a bit about the best way to merge this, specifically libc_aliases

Initial reaction: This PR serves to highlight the need to isolate libc functions in plib crate, and remove any need to touch individual utils with libc_aliases related changes directly.

[andrewliebenow]

👍🏻. Some of the hacky special casing for musl will be unnecessary when rust-lang/libc#3190 is resolved, so one option would be to just wait on that. I made a PR to add some missing constants (rust-lang/libc#3908), but I would assume it's not easy/quick to get things merged into the libc crate.

[jgarzik]

High level guidance thoughts:

• We do want to support platforms such as musl
• Our current set of unsafe libc calls in utils is distasteful... unwanted but sometimes necessary.
• Adding conditional compilation to utils due to this only compounds the ugliness
• The proper solution is to have a plib (posixutils' internal library crate) or another crate provide a nice, clean, safe wrapper for the class of libc library function. Example: tiny plib module for get/setpriority POSIX syscalls and constants
• restrict musl ifdefs to plib, unless there is an incredibly strong reason (c.f. getconf)

[jgarzik]

On-going comments:

• The platform:XXX direction is good. This removes libc references from non-plib code; an improvement.
• Dislike PPriorityWhichT -- it is better to promote xgetpriority and xsetpriority to a new plib/priority.rs module, remove the 'x' prefix, and bury all the glibc/musl/macos ifdefs in plib/priority.rs. Making the cast portable just extends the ugliness, which we would rather leave renice.rs altogether.
• Happy to entertain cleanups, as separate PRs, to keep this PR smaller and self-contained.

[andrewliebenow]

Closed in favor of #198