Skip to content

dylib-soname run-make test is not language independant #129362

@Urgau

Description

@Urgau
Member

On an non-English system the run-make tests/run-make/dylib-soname test fails because it searches a english "needle" but readelf may print it in another language.

--- stderr -------------------------------
=== HAYSTACK ===

La section dynamique à l'offset 0x156868 contient 29 entrées :
  Étiquettes Type                         Nom/Valeur
 0x0000000000000001 (NEEDED)             Bibliothèque partagée : [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Bibliothèque partagée : [libc.so.6]
 0x0000000000000001 (NEEDED)             Bibliothèque partagée : [ld-linux-x86-64.so.2]
 0x000000000000000e (SONAME)             Bibliothèque soname : [libfoo.so]
[..]

=== NEEDLE ===
Library soname: [libfoo.so]
thread 'main' panicked at [..]/rust/tests/run-make/dylib-soname/rmake.rs:17:14:
needle was not found in haystack
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Putting LC_ALL=C in my environment variable makes readelf use it's default (English) language.
We should probably do that for all the run-make tests.

Activity

added
A-testsuiteArea: The testsuite used to check the correctness of rustc
C-bugCategory: This is a bug.
A-compiletestArea: The compiletest test runner
on Aug 21, 2024
added
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on Aug 21, 2024
added
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
and removed
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on Aug 21, 2024
jieyouxu

jieyouxu commented on Aug 21, 2024

@jieyouxu
Member

... good catch. I love C locale.

petrochenkov

petrochenkov commented on Aug 21, 2024

@petrochenkov
Contributor

In the compiler we set LC_ALL=C and VSLANG=1033 before calling linker because we inspect linker output sometimes.

That said, isn't the plan to migrate operations like this from third-party tools to library calls to something like object?

jieyouxu

jieyouxu commented on Aug 21, 2024

@jieyouxu
Member

That said, isn't the plan to migrate operations like this from third-party tools to library calls to something like object?

It is. However, my current plan is to prioritize first getting rid of make and trimming down external bin tools and deps where possible (some of them are first moved to llvm bintools which are at least batched together with llvm). It's non-trivial to match readelf/readobj etc. when they have various combination of flags, and when reviewing I found out that libraries like object have differences in its interpretation of symbols (i.e. they don't match cleanly 1-to-1).

Getting rid of make first of all means that we can run the run-make tests outside of msys2 msys lol.

I'm going to do a second pass after first getting rid of make, and revisit things like:

  • External bin tools.
  • Tests that require bootstrap cargo and then internet connection to run the test (the target sanity check tests).

TL;DR: yes, eventually.

added a commit that references this issue on Aug 21, 2024
92f0b7e
added a commit that references this issue on Aug 21, 2024
84c20be
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-compiletestArea: The compiletest test runnerA-testsuiteArea: The testsuite used to check the correctness of rustcC-bugCategory: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @Urgau@petrochenkov@jieyouxu@rustbot

      Issue actions

        `dylib-soname` run-make test is not language independant · Issue #129362 · rust-lang/rust