Skip to content
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

"Renaming of the library C was specified" error only on nightly #38850

Closed
dylanede opened this issue Jan 5, 2017 · 9 comments
Closed

"Renaming of the library C was specified" error only on nightly #38850

dylanede opened this issue Jan 5, 2017 · 9 comments
Labels
regression-from-stable-to-beta Performance or correctness regression from stable to beta.

Comments

@dylanede
Copy link
Contributor

dylanede commented Jan 5, 2017

This appears to be caused by a change in #37403.

This appears to be causing a breaking change on nightly from stable. I'm compiling an (unreleased) FFI library that handles the linking to certain static libraries in a build script (so the extern "C" block is unannotated). It depends on the libc crate. Other than that it does nothing out of the ordinary. I'm compiling using the windows msvc x64 toolchain. On nightly, but not on stable, I get the error message:

error: renaming of the library `C` was specified, however this crate contains no #[link(...)] attributes referencing this library.

Is this library C referring to libc? My crate has an entirely unrelated name.

@dylanede
Copy link
Contributor Author

dylanede commented Jan 5, 2017

cc @vadimcn

@vadimcn
Copy link
Contributor

vadimcn commented Jan 5, 2017

@dylanede, are you putting the full library path behind -l by any chance?
(i.e. -l C:\foo\bar\baz.lib)

@dylanede
Copy link
Contributor Author

dylanede commented Jan 9, 2017

Ah, yes I am. The path is constructed using the CARGO_MANIFEST_DIR environment variable. The lib is stored in a crate subdirectory.

@vadimcn
Copy link
Contributor

vadimcn commented Jan 10, 2017

Hmm, I was under impression that -l takes just the library name.
@alexcrichton, how is -l supposed to work?

@alexcrichton
Copy link
Member

@vadimcn that was the intention, yes, but it looks like it works with paths as well I guess?

@alexcrichton
Copy link
Member

I believe the relevant PR (#37973) is on beta, so I'm going to tag this as a stable-to-beta regression.

@alexcrichton alexcrichton added regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-tools labels Jan 10, 2017
@vadimcn
Copy link
Contributor

vadimcn commented Jan 10, 2017

@alexcrichton: We have code in rustc that assumes that it's given just the library name. If you invoke ld -l/foo/libbar.a, it won't find the library. The proper way is this: ld -L/foo -lbar.

The full path works with MSVC (if you omit the .lib extension), but only by accident.

@alexcrichton
Copy link
Member

The tools team discussed this during triage today and the conclusion was that this interpretation of -l was an unintended consequence and the current interpretation is working as intended. As a result I'm going to close this, but @dylanede if you need help updating your code please just let me know and I'd be more than willing to help out!

@hone
Copy link

hone commented Aug 9, 2017

I'm not sure if this is related, but I'm seeing the same error message while playing around with neon. This only happens on Windows. I'm on rust 1.19.0. This is the error message I'm seeing.

renaming of the library `C` was specified, however this crate contains no #[link(...)]

Just running cargo build on this sample repo triggers it. Here's a link to an Appveyor build demonstrating it. I'm not sure how to work around the issue. Thanks for any help.

hone added a commit to hone/neon that referenced this issue Aug 9, 2017
-l is only intended to communicate the names of libraries

See rust-lang/rust#38850 for more details.
hone added a commit to hone/neon that referenced this issue Aug 9, 2017
-l is only intended to communicate the names of libraries

See rust-lang/rust#38850 for more details.
hone added a commit to hone/neon that referenced this issue Aug 9, 2017
-l is only intended to communicate the names of libraries

See rust-lang/rust#38850 for more details.
hone added a commit to hone/neon that referenced this issue Aug 9, 2017
-l is only intended to communicate the names of libraries

See rust-lang/rust#38850 for more details.
hone added a commit to hone/neon that referenced this issue Aug 9, 2017
-l is only intended to communicate the names of libraries

See rust-lang/rust#38850 for more details.
hone added a commit to hone/neon that referenced this issue Aug 9, 2017
-l is only intended to communicate the names of libraries

See rust-lang/rust#38850 for more details.
hone added a commit to hone/neon that referenced this issue Aug 10, 2017
-l is only intended to communicate the names of libraries

See rust-lang/rust#38850 for more details.
hone added a commit to hone/neon that referenced this issue Aug 11, 2017
-l is only intended to communicate the names of libraries

See rust-lang/rust#38850 for more details.
hone added a commit to hone/neon that referenced this issue Aug 11, 2017
-l is only intended to communicate the names of libraries

See rust-lang/rust#38850 for more details.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
regression-from-stable-to-beta Performance or correctness regression from stable to beta.
Projects
None yet
Development

No branches or pull requests

4 participants