New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for `link_args` stabilization #29596

Open
aturon opened this Issue Nov 5, 2015 · 18 comments

Comments

Projects
None yet
@aturon
Member

aturon commented Nov 5, 2015

This issue tracks stabilization for the #[link_args] attribute.

@aturon

This comment has been minimized.

Member

aturon commented Nov 5, 2015

@alexcrichton (or anyone else), any ideas what the blockers are here?

@aturon

This comment has been minimized.

Member

aturon commented Nov 5, 2015

From the reference:

The compiler's usage of the system linker is not guaranteed to continue in the future, and if the system linker is not used then specifying custom flags doesn't have much meaning.

@alexcrichton

This comment has been minimized.

Member

alexcrichton commented Nov 5, 2015

Some thoughts of mine:

  • Right now we split arguments on spaces, so there's no way to specify an argument with a space in it
  • This is super non-cross-platform. Even within one platform there's no guarantee that we'll always call the same linker.
  • It's unclear what the "propagation semantics" of link args should be. For example if you build an rlib, should the arguments be passed to when that rlib is included in a linker invocation? Should it be passed upstream continuously after that is then later used in linker invocations?
@WiSaGaN

This comment has been minimized.

Contributor

WiSaGaN commented Jan 18, 2016

Since we do not have a good solution for now, but as a system language, it is sometimes necessary to specify args like this (even only for specific platforms), put it behind a feature gate and only letting nightly branch to use it seems to be a compromise to make.

@iwinux

This comment has been minimized.

iwinux commented Feb 18, 2016

Got hit by this issue when trying out https://gist.github.com/jansegre/043f5ab7f53e23890eed.

As LuaJIT requires, I need to link the binary with flags -pagezero_size 10000 -image_base 100000000, which seems only achievable via #[link_args = "..."].

Could this be done without using Rust nightly? Obviously link_args is not available as of Rust 1.6.0:

src/main.rs:1:1: 1:23 error: #[feature] may not be used on the stable release channel
src/main.rs:1 #![feature(link_args)]
@retep998

This comment has been minimized.

Member

retep998 commented Feb 18, 2016

You can use the command line flag -Clink-args="-pagezero_size 10000 -image_base 100000000" which does work fine (or cargo rustc -- -Clink-args="blah")

@comex

This comment has been minimized.

Contributor

comex commented Jun 6, 2016

It seems strange to allow -C link-args on the command line without -Z unstable-options, yet keep the source code equivalent unstable.

@retep998

This comment has been minimized.

Member

retep998 commented Jun 6, 2016

I'd rather we fix the issue with being unable to have spaces in the linker arguments before stabilizing either of them. Unfortunately -Clink-args being stable makes that difficult.

@retep998

This comment has been minimized.

Member

retep998 commented Jun 22, 2017

So uh, is it intentional that this became accidentally stable?

#![link_args = "-l bunny"]
fn main() {}
rustc 1.18.0 (03fc9d622 2017-06-06)
warning: unused attribute
 --> <anon>:2:1
  |
2 | #![link_args = "-l bunny"]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(unused_attributes)] on by default

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "./out.0.o" "-o" "./out" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-f4594d3e53dcb114.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-1efbcfd8938372b6.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-532a3dbf317eff86.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_unicode-cfbd6648f7db2ee5.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-a0157c0ca919c364.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-488b4ab4bd53a138.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-ca07b617414dd0fa.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-492d8ea7fa3384ff.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-88c194c15fdb6521.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-687e6a964d22cbb4.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-987729be881d4d32.rlib" "-Wl,-Bdynamic" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util" "-l" "bunny"
  = note: /usr/bin/ld: cannot find -lbunny
          collect2: error: ld returned 1 exit status
          

error: aborting due to previous error

Also it warns that the attribute is unused despite having a very obvious effect. Also we still don't have a superior #![link_arg] yet which is capable of handling arguments with spaces in them.

@est31

This comment has been minimized.

Contributor

est31 commented Jun 22, 2017

@retep998 I guess its a mistake, yes. There is a working feature gate, together with a gate test, but it seems to be only active on the foreign module declaration, so extern { .. } or extern C { .. }.

@retep998

This comment has been minimized.

Member

retep998 commented Jun 22, 2017

But there's no reason to even tie a link_args to an extern block. At least with link you can use the kind to infer whether to apply dllimport to those extern symbols, but for arbitrary linker arguments there's nothing you can do.

@est31

This comment has been minimized.

Contributor

est31 commented Jun 22, 2017

@retep998 I guess its simply a mistake. The bug in the feature gate is probably that way since the initial implementation e338a41 (no idea what ast::item_foreign_mod meant back then but it means probably exactly what extern { .. } means now).

IMO we should do one of these two things:

  • Emit warnings and fix the feature gate after a few cycles, or
  • Stabilize the feature right away, or with some previous thinking.
@aturon

This comment has been minimized.

Member

aturon commented Jul 3, 2017

cc @rust-lang/compiler, it appears that there was an unintended stabilization here; decision needed.

@joshtriplett

This comment has been minimized.

Member

joshtriplett commented Jul 6, 2017

Unless there's a sign of usage in the wild, I think the right answer here is to fix the broken feature gate and keep this unstable.

@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented Jul 6, 2017

triage: P-high

We decided to try and fix this. @pnkfelix will either prep a PR or write-up some mentoring instructions.

bors added a commit that referenced this issue Jul 10, 2017

Auto merge of #43109 - pnkfelix:fix-link_args-gate, r=nikomatsakis
Fix feature gate for `#[link_args(..)]` attribute

Fix feature gate for `#[link_args(..)]` attribute so that it will fire regardless of context of attribute.

See also #29596 and #43106
@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented Jul 27, 2017

Feature gate was fixed by #43109. Lowering priority.

triage: P-medium

@rust-highfive rust-highfive added P-medium and removed P-high labels Jul 27, 2017

@vext01

This comment has been minimized.

Contributor

vext01 commented Feb 23, 2018

It seems that link_args attributes always get reported as unused. This was also mentioned above. Am I missing something?

@pnkfelix

This comment has been minimized.

Member

pnkfelix commented Sep 12, 2018

@vext01 I'm guessing that just isn't high enough priority to get addressed (yet)...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment