If my crate Cargo.toml specifies:
[lib]
crate_type = ["cdylib"]
then running cargo clippy produces the above linker error. cargo clippy --profile=test , cargo build , cargo test etc. are all fine however.
You can even reproduce on an empty/minimal project. All it needs is the above lib type mentioned in the toml.
Using clippy version 0.0.99 with nightly from 17th Nov 2016 was fine. After updating to 19th Dec 2016 nightly and clippy 0.0.104 this was a problem and ever since continued to this date (with lates nightly and latest clippy - v0.0.112 at the time of writing this).
Is this known and is there any resolution planned on this.
That was probably the move to serde in the code that parses the Hmm no, December is much earlier. I'll investigate.cargo metadata output.
So apparently it's our use of -Zno-trans, since cargo rustc -- -Zno-trans also fails with the same error.
I reported this upstream: https://github.com/rust-lang/rust/issues/39445
In case anyone's interested in working around this, here's a reduced version of the justfile task I use in one of my rust-cpython projects:
check:
#!/usr/bin/env python3
import os, re, subprocess, sys
filter_re = re.compile(b"\n?\n[^\n]*error.*: linking with `cc` failed: exit code: 1(.|\n)*syntax error in VERSION script(.|\n)*To learn more, run the command again with --verbose\.")
# Run clippy with filter and ignored return code
clippy = subprocess.Popen(
['cargo', '+nightly', 'clippy', '--color=always'],
stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
clippy_output = clippy.communicate()[0]
sys.stdout.buffer.write(filter_re.sub(b'', clippy_output))
# ...and let `cargo check` handle dying on failure instead
with open(os.devnull, 'wb') as devnull:
sys.exit(subprocess.call(['cargo', 'check'],
stdout=devnull, stderr=devnull))
# Use sys.exit() rather than check_call() to avoid traceback
# (no conditional since it's the last thing in the task anyway)
according to rustc this is fixed: https://github.com/rust-lang/rust/issues/39445#issuecomment-303425697
@ssokolow @ustulation can you confirm?
Still a problem here.
(I tested with a freshly-run rustup update and cargo +nightly install -f clippy about 5 hours ago and still got the error message, but got side-tracked before I could respond.)
I have run into this problem too. Is there any workaround?..
Apparently the "new" way to do this is to use --emit=metadata should be easy enough to change in cargo clippy
Has this fix been pushed to crates.io yet?
I just did a rustup update; cargo +nightly install -f clippy; cargo +nightly clippy run and I'm still getting this error.
As far as I can see, #1852 was merged just after version had been bumped to 0.0.142 (https://github.com/Manishearth/rust-clippy/commit/e56331f33daef5d369625200d355089e8c01b1b4). I'm waiting for the fix too. 馃槃
This has been published.
The delay happened because we mostly publish on rustups, and these can be a week or two apart.
I can confirm that the problem appears to be fixed now.