dylib-soname run-make test is not language independant

[Urgau]

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.

[jieyouxu]

... good catch. I love C locale.

[petrochenkov]

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]

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.