tests/ui/codegen/duplicated-path-in-error: Fails on musl libc due to ldso error message difference

[awilfox]

I tried this code:

python3 x.py test -j 64 tests/ui

I expected to see this happen: all tests passing

Instead, this happened:

failures:
    [ui] tests/ui/codegen/duplicated-path-in-error.rs

diff of stderr:

-	error: couldn't load codegen backend /non-existing-one.so: cannot open shared object file: No such file or directory
+	error: couldn't load codegen backend /non-existing-one.so: Error loading shared library /non-existing-one.so: No such file or directory

Meta

rustc --version --verbose:

rustc 1.82.0-nightly (249cf71f1 2024-07-30) (Adélie 1.82.0 EXPERIMENTAL)
binary: rustc
commit-hash: 249cf71f11a29b3fb68e8a35969569d8bb7958ee
commit-date: 2024-07-30
host: powerpc64-foxkit-linux-musl
release: 1.82.0-nightly
LLVM version: 18.1.8

I'm not familiar enough yet with the machinery around Rust's test suites to know how to change this to a pattern match, but I think ensuring the output is error: couldn't load codegen backend /non-existing-one.so: (.*): No such file or directory would be sufficient. It'd likely help other libcs like llvm-libc in the future, as well.

[saethlin]

I think ensuring the output is error: couldn't load codegen backend /non-existing-one.so: (.*): No such file or directory would be sufficient.

Based on my reading of the comment in the test, that would actually be wrong. On musl, the path of the dylib is duplicated. But... why?

[awilfox]

That's the format used by dlopen on musl. The path being duplicated isn't the issue, either (that could probably be worked around easily) - the problem is that the error message itself is different.

On glibc, the error is cannot open shared object file while on musl the error is Error loading shared library %s. Rust is not duplicating the path, musl is.

[saethlin]

🤔 So it would be good to rewrite the comment in the test to explain how the musl output is not the bug that the test is looking for.

If you want to make the test behave differently on musl, I think the better thing to do is use revisions, like tests/debuginfo/thread-names.rs, where your revisions bring in only-x86_64-unknown-linux-gnu and only-x86_64-unknown-linux-musl annotations.

If you're bent on doing a pattern, you can kind of imitate that with normalization: //@ normalize-stderr-test:. There are lots of those in the test suite already.