Skip to content

Stop forwarding -L "" to compiler drivers; reject or ignore instead #23303

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

Closed
rprichard opened this issue Mar 12, 2015 · 1 comment · Fixed by #23358
Closed

Stop forwarding -L "" to compiler drivers; reject or ignore instead #23303

rprichard opened this issue Mar 12, 2015 · 1 comment · Fixed by #23358

Comments

@rprichard
Copy link
Contributor

The current Rust build system passes -L "" to rustc when LLVM_STDCPP_LOCATION_<XXX> is blank (which seems to be the default situation). -L "" does not appear to do anything useful. rustc forwards -L "" to the compiler driver correctly, but both the gcc and clang compiler drivers forward it to ld in a way that breaks the subsequent ld command-line option. (They convert -L "" to just -L.)

Perhaps the rustc driver should reject -L "" instead. It already rejects -l "".

Alternatively, it could quietly ignore -L "". Another alternative is to fix gcc and clang.

I discovered this issue while investigating a FreeBSD build failure (#23287).

@rprichard
Copy link
Contributor Author

Copying-and-pasting the example I posted in the FreeBSD issue:

mkdir subdir
echo "void dummy(void){}" > subdir/dummy.c
gcc -shared subdir/dummy.c -o subdir/libdummy.so
echo  >main.rs '#[link(name = "dummy", kind = "dylib")]'
echo >>main.rs 'extern { fn dummy(); }'
echo >>main.rs 'fn main() { unsafe { dummy(); } }'
rustc main.rs -L "" -Lsubdir

Produces:

error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-m64" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "./main" "./main.o" "-Wl,--whole-archive" "-lmorestack" "-Wl,--no-whole-archive" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-4e7c5e5c.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-4e7c5e5c.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunicode-4e7c5e5c.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-4e7c5e5c.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-4e7c5e5c.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-4e7c5e5c.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-4e7c5e5c.rlib" "-L" "" "-L" "subdir" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-L" "/home/rprichard/mess/dyncrate/.rust/lib/x86_64-unknown-linux-gnu" "-L" "/home/rprichard/mess/dyncrate/lib/x86_64-unknown-linux-gnu" "-Wl,--whole-archive" "-Wl,-Bstatic" "-Wl,--no-whole-archive" "-Wl,-Bdynamic" "-ldummy" "-ldl" "-lpthread" "-lrt" "-lgcc_s" "-lpthread" "-lc" "-lm" "-lcompiler-rt"
note: /usr/bin/ld: cannot find -ldummy
collect2: error: ld returned 1 exit status

Remove the -L "", or move it to the end of the command-line, and it works. ld is seeing -L -Lsubdir, so it adds the non-existent -Lsubdir directory to the search path, and it doesn't search inside subdir.

Manishearth added a commit to Manishearth/rust that referenced this issue Mar 15, 2015
…chton

 This change closes rust-lang#23303 by rejecting an empty search path.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant