macOS executables unnecessarily depend on libresolv.dylib #46797
Labels
O-macos
Operating system: macOS
Comments
facebook-github-bot
pushed a commit
to facebook/buck
that referenced
this issue
Jan 9, 2018
Summary: Rust's libstd has a stray dependency on libresolv. Normally this is satisfied when rustc is doing the linking, but when generating standalone Rust libraries for use as a C++ dependency it still has the libresolv requirement. For now, just add `-lresolv` to the link line in the affected test. This is a bit of a hack; it shouldn't require libresolv at all. Upstream rust issue rust-lang/rust#46797 is tracking this. Test Plan: unit tests Reviewed By: styurin fbshipit-source-id: 734b1dc
tor-bot
pushed a commit
to torproject/tor
that referenced
this issue
Jan 16, 2018
This fixes issue #24652, and is a workaround for Rust issue rust-lang/rust#46797 .
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Jan 19, 2018
…nix, r=alexcrichton Only link res_init() on GNU/*nix To workaround a bug in glibc <= 2.26 lookup_host() calls res_init() based on the glibc version detected at runtime. While this avoids calling res_init() on platforms where it's not required we will still end up linking against the symbol. This causes an issue on macOS where res_init() is implemented in a separate library (libresolv.9.dylib) from the main libc. While this is harmless for standalone programs it becomes a problem if Rust code is statically linked against another program. If the linked program doesn't already specify -lresolv it will cause the link to fail. This is captured in issue rust-lang#46797 Fix this by hooking in to the glibc workaround in `cvt_gai` and only activating it for the "gnu" environment on Unix This should include all glibc platforms while excluding musl, windows-gnu, macOS, FreeBSD, etc. This has the side benefit of removing the #[cfg] in sys_common; only unix.rs has code related to the workaround now. Before this commit: ```shell > cat main.rs use std::net::ToSocketAddrs; #[no_mangle] pub extern "C" fn resolve_test() -> () { let addr_list = ("google.com.au", 0).to_socket_addrs().unwrap(); println!("{:?}", addr_list); } > rustc --crate-type=staticlib main.rs > clang libmain.a test.c -o combined Undefined symbols for architecture x86_64: "_res_9_init", referenced from: std::net::lookup_host::h93c17fe9ad38464a in libmain.a(std-826c8d3b356e180c.std0.rcgu.o) ld: symbol(s) not found for architecture x86_64 clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) ``` Afterwards: ```shell > rustc --crate-type=staticlib main.rs > clang libmain.a test.c -o combined > ./combined IntoIter([V4(172.217.25.131:0)]) ``` Fixes rust-lang#46797
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Jan 21, 2018
…nix, r=alexcrichton Only link res_init() on GNU/*nix To workaround a bug in glibc <= 2.26 lookup_host() calls res_init() based on the glibc version detected at runtime. While this avoids calling res_init() on platforms where it's not required we will still end up linking against the symbol. This causes an issue on macOS where res_init() is implemented in a separate library (libresolv.9.dylib) from the main libc. While this is harmless for standalone programs it becomes a problem if Rust code is statically linked against another program. If the linked program doesn't already specify -lresolv it will cause the link to fail. This is captured in issue rust-lang#46797 Fix this by hooking in to the glibc workaround in `cvt_gai` and only activating it for the "gnu" environment on Unix This should include all glibc platforms while excluding musl, windows-gnu, macOS, FreeBSD, etc. This has the side benefit of removing the #[cfg] in sys_common; only unix.rs has code related to the workaround now. Before this commit: ```shell > cat main.rs use std::net::ToSocketAddrs; #[no_mangle] pub extern "C" fn resolve_test() -> () { let addr_list = ("google.com.au", 0).to_socket_addrs().unwrap(); println!("{:?}", addr_list); } > rustc --crate-type=staticlib main.rs > clang libmain.a test.c -o combined Undefined symbols for architecture x86_64: "_res_9_init", referenced from: std::net::lookup_host::h93c17fe9ad38464a in libmain.a(std-826c8d3b356e180c.std0.rcgu.o) ld: symbol(s) not found for architecture x86_64 clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) ``` Afterwards: ```shell > rustc --crate-type=staticlib main.rs > clang libmain.a test.c -o combined > ./combined IntoIter([V4(172.217.25.131:0)]) ``` Fixes rust-lang#46797
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently Rust stdlib on macOS requires every executable to link to
libresolv.dylib. This is probably unnecessary and happens only becauseres_init_if_glibc_before_2_26is called on all#[cfg(unix)]platforms.On macOS
-lresolvis rarely used, so Rust static libraries cause linker errors in most C programs due to_res_9_initmissing.Can the
res_init_if_glibc_before_2_26hack be limited to#[cfg(linux)]or something withnot(target_os = "macos")?The text was updated successfully, but these errors were encountered: