hash collision on /usr/lib/rust/lib-1.84.1/librustc_driver-???.so

[clan]

https://bugs.gentoo.org/949374

We have users' report on unable to run rustc after build rust 1.84.0 and 1.84.1 (no report for earlier version), and it is high suspected the problem is on the collision on librustc_driver-???.so, two version (1.84.0 & 1.84.1) use the same filename (in different path), so rustc-1.84.1 will use librustc_driver in rust 1.84.0, then failed with error:

/usr/lib/rust/1.84.1/bin/rustc: symbol lookup error: /usr/lib/rust/1.84.1/bin/rustc: undefined symbol: _ZN3std2rt19lang_start_internal17h12de313c8fa04a78E

ldd confirm:

> demize@yveltal ~ $ lddtree /usr/bin/rustc-*
> rustc-1.84.0 => /usr/bin/rustc-1.84.0 (interpreter => /lib64/ld-linux-x86-64.so.2)
>     librustc_driver-6f6761e2f1b0d7ca.so => /usr/lib/rust/lib-1.84.0/librustc_driver-6f6761e2f1b0d7ca.so
>         libLLVM.so.19.1+libcxx => /usr/lib/llvm/19/lib64/libLLVM.so.19.1+libcxx
>             libffi.so.8 => /usr/lib64/libffi.so.8
>             libz.so.1 => /usr/lib64/libz.so.1
>             libzstd.so.1 => /usr/lib64/libzstd.so.1
>         libc++.so.1 => /usr/lib64/libc++.so.1
>         libc++abi.so.1 => /usr/lib64/libc++abi.so.1
>         libunwind.so.1 => /usr/lib64/libunwind.so.1
>         libm.so.6 => /usr/lib64/libm.so.6
>         ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
>     libc.so.6 => /usr/lib64/libc.so.6
> rustc-1.84.1 => /usr/bin/rustc-1.84.1 (interpreter => /lib64/ld-linux-x86-64.so.2)
>     librustc_driver-6f6761e2f1b0d7ca.so => /usr/lib/rust/lib-1.84.0/librustc_driver-6f6761e2f1b0d7ca.so
>         libLLVM.so.19.1+libcxx => /usr/lib/llvm/19/lib64/> libLLVM.so.19.1+libcxx
>             libffi.so.8 => /usr/lib64/libffi.so.8
>             libz.so.1 => /usr/lib64/libz.so.1
>             libzstd.so.1 => /usr/lib64/libzstd.so.1
>         libc++.so.1 => /usr/lib64/libc++.so.1
>         libc++abi.so.1 => /usr/lib64/libc++abi.so.1
>         libunwind.so.1 => /usr/lib64/libunwind.so.1
>         libm.so.6 => /usr/lib64/libm.so.6
>         ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
>     libc.so.6 => /usr/lib64/libc.so.6

both rustc 1.84.0 & 1.84.1 use librustc_driver.so with the same name 'librustc_driver-6f6761e2f1b0d7ca.so'

My question is:

1. is 6f6761e2f1b0d7ca a hash value?
2. if so, how it's calculated?
3. what's the probability of collsion?
4. howto avoid if it's collision?

thanks.

[jyn514]

that hash is a -C metadata value calculated by cargo (based on a bunch of things, one of which is the version number).

i would be extremely surprised to see a collision here. how did you install 1.84.0 and .1? are you sure they are actually different compilers?

[workingjubilee]

1.84.0:

        librustc_driver-7bea7fca18409d2b.so => /home/jubilee/.rustup/toolchains/1.84.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-7bea7fca18409d2b.so (0x00007479a6c00000)

1.84.1:

        librustc_driver-cbb5ad48aac6e327.so => /home/jubilee/.rustup/toolchains/1.84.1-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-cbb5ad48aac6e327.so (0x0000791fb9e00000)

@clan I believe the gentoo build system has a bug.

[jieyouxu]

Yeah I was about to say, they're both searching under 1.84.0 dir which is sus, but then it's the same driver...

[clan]

yes, it turns out the reason is 'channel = "nightly"' in config.toml
so the question is:

1. how it's calculated? where is the code?
2. what's the best method to make it unique non-unique between each release even with channel="nightly"? "-C metadata" is a option.

updated: i mean non-unique but write unique, :(

[clan]

that hash is a -C metadata value calculated by cargo (based on a bunch of things, one of which is the version number).

i would be extremely surprised to see a collision here. how did you install 1.84.0 and .1? are you sure they are actually different compilers?

it seems version is cut if channel="nightly"?

[clan]

1.84.0:

        librustc_driver-7bea7fca18409d2b.so => /home/jubilee/.rustup/toolchains/1.84.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-7bea7fca18409d2b.so (0x00007479a6c00000)

1.84.1:

        librustc_driver-cbb5ad48aac6e327.so => /home/jubilee/.rustup/toolchains/1.84.1-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-cbb5ad48aac6e327.so (0x0000791fb9e00000)

@clan I believe the gentoo build system has a bug.

it's probably the first time to have 1.X.0 and 1.X.1 in gentoo, so have this bug.

[jieyouxu]

Why is gentoo using a nightly channel when building stable versions? Can you trying building stable toolchains via the dist profile and avoid overriding the channel?

[clan]

Why is gentoo using a nightly channel when building stable versions? Can you trying building stable toolchains via the dist profile and avoid overriding the channel?

Gentoo is a source based distribution, user can control the feature themselves by the so called USE flag, that's why it took some time to find out the reason.

[workingjubilee]

@clan The last time I counseled someone about a bug they were having with Gentoo's build system, it became apparent Gentoo is doing some pretty... opinionated... things with how y'all are building our software.

In other words, it seems to me the default way you are building our things is not what I would do if I was configuring rustc for a source-based distribution.

I would not make it an option to build rustc with a different channel, I would simply make nightly rustc a separate package.

[jieyouxu]

If the user used (heh) a USE flag that overrides the channel of a dist build with nightly, then this will occur AFAIK.

It's possible that this might be a different issue. But without a repro that rules out the gentoo build system it's hard to say.