illumos: link against non-legacy getifaddrs

[luqmana]

Description

The libc crate links against the legacy version of getifaddrs on illumos which only returns AF_INET[6] entries.

As of illumos#11196, getifaddrs was updated to also return AF_LINK entries but was done in such a way to preserve existing binaries that only expected the old behaviour. That is, the symbol getifaddrs would refer to the legacy version but newly compiled C programs would get the new version by linking against __getifaddrs (via a redefine_extname pragma in ifaddrs.h).

fn main() {
    let mut addrs = std::mem::MaybeUninit::uninit();
    if unsafe { libc::getifaddrs(addrs.as_mut_ptr()) } != 0 {
        return;
    }
    let addrs = unsafe { addrs.assume_init() };
    let mut addr = addrs;
    while !addr.is_null() {
        let a = unsafe { &*addr };
        addr = a.ifa_next;
        let name = unsafe { std::ffi::CStr::from_ptr(a.ifa_name) };
        let name = name.to_string_lossy();
        if a.ifa_addr.is_null() {
            continue;
        }
        let fam = match unsafe { (*a.ifa_addr).sa_family } as libc::c_int {
            libc::AF_INET => "AF_INET",
            libc::AF_INET6 => "AF_INET6",
            libc::AF_LINK => "AF_LINK",
            _ => "<other>",
        };
        println!("{name}\t{fam}");
    }
    unsafe {
        libc::freeifaddrs(addrs);
    }
}

Before:

$  cargo r
   Compiling getifaddrs-test v0.1.0 (/home/luqman/tmp/getifaddrs-test)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.43s
     Running `target/debug/getifaddrs-test`
lo0     AF_INET
igb0    AF_INET
lo0     AF_INET6
igb0    AF_INET6

After:

$  cargo r
     Locking 1 package to latest Rust 1.88.0 compatible version
      Adding libc v1.0.0-alpha.1 (/home/luqman/src/libc)
   Compiling libc v1.0.0-alpha.1 (/home/luqman/src/libc)
   Compiling getifaddrs-test v0.1.0 (/home/luqman/tmp/getifaddrs-test)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.65s
     Running `target/debug/getifaddrs-test`
lo0     AF_INET
igb0    AF_INET
lo0     AF_INET6
igb0    AF_INET6
igb0    AF_LINK
igb1    AF_LINK

Sources

• https://www.illumos.org/issues/11196
• illumos/illumos-gate@3ee5924
• https://github.com/illumos/illumos-gate/blob/478476fe3be0c0f39128a0b711291b4cfc18cd7b/usr/src/head/ifaddrs.h#L69-L74
• https://illumos.org/man/3SOCKET/getifaddrs

Checklist

• Relevant tests in libc-test/semver have been updated (getifaddrs is excluded on illumos)
• No placeholder or unstable values like *LAST or *MAX are included (see #3131)
• Tested locally (See above test program demonstrating issue. But libc-test seems broken on illumos on main)

This is potentially a breaking change but it would be nice to get in 0.2. Unsure what the exact policy is there.

@rustbot label +stable-nominated

[rustbot]

Some changes occurred in solarish module

cc @jclulow, @pfmooney

[pfmooney]

I believe this will require an updated sysroot to avoid breaking the rust toolchain builds, as the current sysroot is from 2018: https://github.com/illumos/sysroot/releases/tag/20181213-de6af22ae73b-v1

[luqmana]

I believe this will require an updated sysroot to avoid breaking the rust toolchain builds, as the current sysroot is from 2018: https://github.com/illumos/sysroot/releases/tag/20181213-de6af22ae73b-v1

Hmmm, would it be possible to use the same sysroot base but v2 that adds a stub or alias for __getifaddrs -> getifaddrs? Or is bumping up the sysroot to something more modern just worth it at this point

[pfmooney]

I believe this will require an updated sysroot to avoid breaking the rust toolchain builds, as the current sysroot is from 2018: https://github.com/illumos/sysroot/releases/tag/20181213-de6af22ae73b-v1

Hmmm, would it be possible to use the same sysroot base but v2 that adds a stub or alias for __getifaddrs -> getifaddrs? Or is bumping up the sysroot to something more modern just worth it at this point

We should absolutely bump the sysroot. I believe the intention was to follow something like the rust editions model, and moving it up to 2021 at the very least would be warranted. Keeping compatibility with the oldest supported LTS release of OmniOSCE would probably be a good target.

[tgross35]

It would be good to have a more clear Illumos version support policy, I asked for that in rust-lang/rust#146312 (comment). Then of course rustc should be building against one of the versions we support.

In general, we can't upgrade versioned symbols until the new link name would be present in versions we support, to avoid breaking anyone who is using the existing symbol. We also prefer not to create v2 symbols or similar: in the cases where users need the new functionality and want to opt in, it is easy enough to define their own symbol.

Until the Rust support story gets clarified,
@rustbot blocked

[pfmooney]

We (illumos) are working on picking a date cut-off for the new sysroot, as well as clarifying our policies around versioning and support (as best we can, given that much of that is up to the downstream distros). We'll circle back here as soon as a decision has been made, a new sysroot has been cut, and it has been pulled into the rust-lang/rust build for illumos.