fix(sys): link to iphlpapi unconditionally

[weihanglo]

Upstream has done that so we follow:

1. windows: reduce/stop loading DLLs at runtime curl/curl#17413 preloads iphlpapi conditioned on HAVE_IF_NAMETOINDEX
2. curl/curl@b17ef873 HAVE_IF_NAMETOINDEX is defined unconditionally

See rust-lang/rust#154482 which failed without and succeeded with link to iphlpai dll.

This also bumps curl-sys to 0.4.87 to help unblock rust-lang/rust#154482, (of course, if curl-rust maintainers can help release 🙏🏾)

[weihanglo]

cc @ehuss

[ehuss]

Do you know how to reproduce this? I'm curious why this didn't fail in any other CI builds.

[weihanglo]

I thought it was something related to gc-section, but I was wrong. It passed 🥲 #644

[weihanglo]

cargo with all-static under release profile also failed to reproduce

weihanglo/cargo#89

I am still trying to figure out anything special in rust-lang/rust CI

[weihanglo]

weihanglo/cargo#89 is now failing when raw-dylib is in use.

I still need to double check whether bootstrap builds Cargo with raw-dylib though

[weihanglo]

If I understand correctly, raw-dylib is very likely the culprit.

• https://github.com/rust-lang/rust/blob/80ad55752e5ae6c2d1bc143b819eb8d1c00167d1/src/bootstrap/src/core/build_steps/tool.rs#L844 — Cargo is built under Mode::ToolTarget
• https://github.com/rust-lang/rust/blob/80ad55752e5ae6c2d1bc143b819eb8d1c00167d1/src/bootstrap/src/core/builder/cargo.rs#L694-L701 — Under Mode::ToolTarget the execution of cargo will have rustflags --cfg=windows_raw_dylib.

[ehuss]

Ok, thanks! It's a little strange, but I think I gather this is due to behavior in the windows-sys and windows-link crates, and those crates no longer including everything with the windows_raw_dylib cfg.