Pass --enable-new-dtags to GNU ld

[geofft]

This causes the linker to emit DT_RUNPATH instead of DT_RPATH, which fixes #30378. See that bug for rationale.

[rust-highfive]

r? @Aatch

(rust_highfive has picked a reviewer for you, use r? to override)

[geofft]

r? @alexcrichton probably.

[alexcrichton]

I'm not currently too savvy on the difference between these two options, so before I dive too much into it do you know the answers to these questions?

• It looks like linker_is_gnu is turned on for many BSD platforms as well, do you know if this typically works over there?
• Is this a new-enough option that a rustc-generated binary would no longer run on a super-ancient system? (e.g. the Rust compiler we're shipping, would it not run on systems like CentOS 5.5?)
• Do you know when this option was added to the linker?

Thanks for the patch regardless! Seems like a good thing to tighten up

[Aatch]

@alexcrichton looking at linked issue, it's fairly old. It says that glibc has supported it since 1999, so the flag is likely similarly old.

[geofft]

It looks like linker_is_gnu is turned on for many BSD platforms as well, do you know if this typically works over there?

Not authoritatively, but the interwebs are showing me man pages for GNU ld when I look for NetBSD, OpenBSD, or Dragonfly ld manpages, and all those manpages mention --enable-new-dtags. I'm less easily finding info on bitrig (they're using clang, I think, but probably not lld?). The only other linker_is_gnu target is le32-unknown-nacl, which I believe is also a GNU toolchain.

Is this a new-enough option that a rustc-generated binary would no longer run on a super-ancient system? (e.g. the Rust compiler we're shipping, would it not run on systems like CentOS 5.5?)

As @Aatch mentioned, yeah, the flag was added to glibc in 1999. So it's fine for every CentOS ever. Also, even if the dynamic linker doesn't support it, the effect is that rpaths don't work but the binary is otherwise fine; it doesn't create an un-runnable binary. (That said, GNU ld used to emit both DT_RPATH and DT_RUNPATH for compatibility until 2.24, which is recent enough to be in Ubuntu 14.04. In turn, ld.so ignores DT_RPATH if DT_RUNPATH is around.)

Do you know when this option was added to the linker?

July 2000, probably binutils 2.11 if I'm guessing right.

The trouble with naming a feature "new" is that it's going to continue to be named "new" for decades. :)

[alexcrichton]

OK cool, that all sounds good to me! I agree that 2000 is pretty ancient at this point :)

@bors: r+ cec2d14

[bors]

⌛ Testing commit cec2d14 with merge ef9a4df...

[bors]

💔 Test failed - auto-mac-64-opt

[alexcrichton]

@bors: retry

On Fri, Dec 18, 2015 at 10:14 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-mac-64-opt
http://buildbot.rust-lang.org/builders/auto-mac-64-opt/builds/7448

—
Reply to this email directly or view it on GitHub
#30394 (comment).

[bors]

⌛ Testing commit cec2d14 with merge 712ecce...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt