Remove now-unnecessary Rust linking workaround

We've got the following stanza in our configure.ac:

  dnl This is a workaround for #46797                                                                           
  dnl (a.k.a https://github.com/rust-lang/rust/issues/46797 ).  Once the                                        
  dnl upstream bug is fixed, we can remove this workaround.                                                     
  case "$host_os" in                                                                                            
      darwin*)                                                                                                  
        TOR_RUST_EXTRA_LIBS="-lresolv"                                                                          
    ;;                                                                                                          
  esac

It looks like https://github.com/rust-lang/rust/issues/46797 has been resolved as of 22 January 2018, so we can probably remove this workaround now! (Someone who is on MacOS should probably test this, I don't have access to any Macs right now.)

changed milestone to %Tor: 0.4.0.x-final

added 034-triage-20180328 035-triaged-in-20180711 autoconf component::core tor/tor fast-fix merge-deferred milestone::Tor: 0.4.0.x-final points::.1 priority::medium resolution::implemented review-group-34 reviewer::catalyst rust severity::normal status::closed tor-build type::enhancement version::tor 0.3.2.2-alpha labels

Trac:
Keywords: N/A deleted, rust, tor-build, autoconf added

Patch in my bug25341 branch. Someone with a Mac, please test! :)

Trac:
Status: new to needs_review

Trac:
Description: We've got the following stanza in our configure.ac:

  dnl This is a workaround for #46797                                                                           
  dnl (a.k.a https://github.com/rust-lang/rust/issues/46797 ).  Once the                                        
  dnl upstream bug is fixed, we can remove this workaround.                                                     
  case "$host_os" in                                                                                            
      darwin*)                                                                                                  
        TOR_RUST_EXTRA_LIBS="-lresolv"                                                                          
    ;;                                                                                                          
  esac

It looks like https://github.com/rust-lang/rust/issues/46797 has been resolved as of 18 December 2017, so we can probably remove this workaround now! (Someone who is on MacOS should probably test this, I don't have access to any Macs right now.)

to

We've got the following stanza in our configure.ac:

  dnl This is a workaround for #46797                                                                           
  dnl (a.k.a https://github.com/rust-lang/rust/issues/46797 ).  Once the                                        
  dnl upstream bug is fixed, we can remove this workaround.                                                     
  case "$host_os" in                                                                                            
      darwin*)                                                                                                  
        TOR_RUST_EXTRA_LIBS="-lresolv"                                                                          
    ;;                                                                                                          
  esac

It looks like https://github.com/rust-lang/rust/issues/46797 has been resolved as of 22 January 2018, so we can probably remove this workaround now! (Someone who is on MacOS should probably test this, I don't have access to any Macs right now.)

We can't remove this workaround until we stop supporting old rustc versions without the fix.

Replying to teor:

We can't remove this workaround until we stop supporting old rustc versions without the fix.

Okay! I made #25379 (moved) for figuring out more clearly which rustc(s) we support.

Trac:
Keywords: N/A deleted, review-group-34 added

Reviewer week 03/19th

Trac:
Reviewer: N/A to catalyst

MacOS 10.12.6, with rust from homebrew:

  CCLD     src/or/tor
Undefined symbols for architecture x86_64:
  "_res_9_init", referenced from:
      std::sys::unix::net::res_init_if_glibc_before_2_26::he8c674397a656892 in libtor_rust.a(std-b11ab8f1585f119d.std15-94ef799fc274932c8f7e09df8e855996.rs.rcgu.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [src/or/tor] Error 1
make: *** [all] Error 2
mirkwood:tor tlyu$ rustc --version
rustc 1.24.1

I haven't tracked down any further yet.

Maybe the fix didn't make it into rust 1.24? It seems to work with nightly or whatever travis uses: https://travis-ci.org/tlyu/tor/jobs/356676338

If I'm reading this correctly, it's not in stable yet? I'm not familiar with the rust release engineering processes.

https://github.com/rust-lang/rust/blob/stable/src/libstd/sys/unix/net.rs https://github.com/rust-lang/rust/pull/47334 https://github.com/rust-lang/rust/commit/090a968fe7680cce0d3aa8fde25a5dc48948e43e

I'm not sure whether we want to defer this until that fix hits rust stable, or do something else.

Trac:
Status: needs_review to needs_revision

catalyst is totally right, I just checked in my copy of the rust repo and it's in the current beta, which I think means we have to defer this until 1.25 is stable (2018-03-29 according to https://github.com/rust-lang/rust/blob/master/RELEASES.md).

Trac:
Keywords: N/A deleted, 034-triage-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

Trac:
Keywords: N/A deleted, 034-removed-20180328 added

Trac:
Keywords: 034-removed-20180328 deleted, fast-fix added

Looks like 1.25 is out, at least according to my Homebrew install. I'll give this another try once I upgrade.

Trac:
Status: needs_revision to needs_review

Just tried with Rust 1.25 on macOS. Works now.

Trac:
Status: needs_review to merge_ready

Thank you! Out of selfishness and for my personal convenience, I am going to defer this merge until Fedora updates to 1.25.

Update: Fedora is on 1.25 now, but it seems that sid is still on 1.24.

Pessimisticly assuming we don't get to merge these until 0.3.5, and hoping I'll be wrong.

Trac:
Milestone: Tor: 0.3.4.x-final to Tor: 0.3.5.x-final

Trac:
Keywords: N/A deleted, merge-deferred added

Trac:
Keywords: N/A deleted, 035-triaged-in-20180711 added

Debian sid has had rustc 1.25 since May 18th. https://tracker.debian.org/news/958316/accepted-rustc-1250dfsg1-1-source-into-unstable/ Was that the last thing blocking merge?

Trac:
Cc: N/A to chelseakomlo

Trac:
Milestone: Tor: 0.3.5.x-final to Tor: 0.3.6.x-final

Our CI has rustc 1.29, so it is safe to merge this branch in 0.3.6.

Tor 0.3.6.x has been renamed to 0.4.0.x.

Trac:
Milestone: Tor: 0.3.6.x-final to Tor: 0.4.0.x-final

okay, picking this back up. I've made a PR at https://github.com/torproject/tor/pull/524 to make sure I handled the merge conflict correctly.

looks like I messed up that merge. Trying another.

https://github.com/torproject/tor/pull/526

Okay, that one succeeded. Merged it to master.

Trac:
Resolution: N/A to implemented
Status: merge_ready to closed

closed

changed time estimate to 48m

mentioned in issue #25379 (moved)

moved to tpo/core/tor#25341 (closed)

mentioned in issue tpo/core/tor#25379 (closed)