I just got a linker error using cargo, should I report a bug?

[robin]

In C++, having linker errors is somewhat part of the game because of the compilation model. I just got my first linker error in Rust. Because of the saner compilation model of Rust, I didn't expect to ever find a linker error.

Should I report a bug (and to which project, cargo?), or is it "normal" (in C++ I wouldn't have reported a linker error to gcc/llvm).

My code is using thread_local variables, and I'm compiling natively on Linux.

[alice]

What crates are you using?

[zireael9797]

Yeah just show us your Cargo.toml

[robin]

(EDIT: I forgot the second part of the error message)

I just did a full rebuild, it was a incremental build issue So even worse to investigate. Since my code isn't open-source (it's for work), I can't share the repository.

I copied the error message, but not the cache before rebuilding. I had 10 errors like this one:

/usr/bin/ld: /home/rmoussu/dev/tour-generation/tour_generation/target/debug/deps/extract-3a1d393ac9958e4f.32iw0w1e50jm9c1r.rcgu.o: in function `std::thread::local::fast::Key<T>::get':
/home/rmoussu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/thread/local.rs:410: undefined reference to `_ZN3std6thread5local4fast12Key$LT$T$GT$14try_initialize17h7fb35e549d2434a7E.llvm.8723599205744786000'

followed by

/usr/bin/ld: /home/rmoussu/dev/tour-generation/tour_generation/target/debug/deps/extract-3a1d393ac9958e4f: hidden symbol `_ZN3std6thread5local4fast12Key$LT$T$GT$14try_initialize17h41f0bbc54c438c74E.llvm.8723599205744786000' isn't defined

I'm using the following dependencies:

[dependencies]
anyhow = "1.0.31"
thiserror = "1.0.20"
geo-types = "0.5"
proj = { version = "0.16.2", features = ["bundled_proj"] }
itertools = "0.9.0"
assert_approx_eq = "1.1.0"
ncollide2d = "0.23.2"
measurements = "0.10.3"
derive_more = "0.99.8"
petgraph = "0.5.1"
generator = "0.6"

The static variables are created with this macro:

macro_rules! declare_convertion {
    ($coordinates_A: ty, $coordinates_B: ty, $name_A_to_B: ident, $name_B_to_A: ident) => {
        thread_local! {
            static $name_A_to_B: Convert<$coordinates_A, $coordinates_B> = Convert::new();
            static $name_B_to_A: Convert<$coordinates_B, $coordinates_A> = Convert::new();
        }   

        impl From<$coordinates_A> for $coordinates_B {
            fn from(point: $coordinates_A) -> $coordinates_B {
                $name_A_to_B.with(|convertion| convertion.convert(point))
            }   
        }   

        impl From<$coordinates_B> for $coordinates_A {
            fn from(point: $coordinates_B) -> $coordinates_A {
                eprintln!("{} -> {}", stringify!($coordinates_B), stringify!($coordinates_A));
                $name_B_to_A.with(|convertion| convertion.convert(point))
            }
        }
    };  
}

That I'm using like so:

declare_convertion!(
    Gps,
    Mercator<Boulogne>,
    GPS_TO_MERCATOR_BOULOGNE,
    MERCATOR_BOULOGNE_TO_GPS
);

And the types are:

pub trait IsCity {}
impl IsCity for Boulogne {}

#[derive(Debug, Copy, Clone)]
pub struct Mercator<T: IsCity> {
    pub lat: f64,
    pub lon: f64,
    phantom: PhantomData<T>,
}

pub struct Gps {
    pub lat: f64,
    pub lon: f64,
}

I suspect that the issue comes from the use of static generic variables.

[robin]

My question was just "should I report that linker error? and where", not "how to solve it?" (and btw it's was solved by just rebuilding).

[alice]

The answer is that you should only report it if it is not your fault, and there are many crates for which linker errors are your fault. If you are not able to reproduce it, I would not report it.

[kornel]

I've seen such error a few times (*.rcgu.o missing some Rusty symbol that should be there), but it is transient. rm -rf target "fixes" it. It could be some race condition or cache corruption in rustc/Cargo.

[robin]

Given that it was transient and that I cleared the target directory (thus losing all hope of reproducing it), I guess it isn't useful to report it (since it will not be investigated), even if solving such kind of cache corruption / data race would be plus.