tests: Fix cdylib-export-c-library-symbols to work with LTO-enabled CFLAGS

The test fails on systems where default CFLAGS include LTO flags
(e.g., `-flto=auto -ffat-lto-objects`), which is common in RHEL,
Fedora, and CentOS distributions.

The issue occurs because `build_native_static_lib()` recompiles the
C source using system CFLAGS, which may include LTO. When rustc tries
to process this static library with the `+export-symbols` modifier,
it correctly rejects it as LTO objects in C static libraries are not
supported.

Fix by manually compiling the C code with `-fno-lto` to override
system defaults, then using llvm-ar directly to create the static
library. This ensures the test validates the `+export-symbols`
feature rather than LTO compatibility.

Author: Jesus Checa Hidalgo

tests/run-make/cdylib-export-c-library-symbols/rmake.rs

@@ -7,11 +7,12 @@
 //@ ignore-apple
 // Reason: the compiled binary is executed
 
-use run_make_support::{build_native_static_lib, cc, dynamic_lib_name, is_darwin, llvm_nm, rustc};
+use run_make_support::{cc, dynamic_lib_name, is_darwin, llvm_ar, llvm_nm, rustc, static_lib_name};
 
 fn main() {
-    cc().input("foo.c").arg("-c").out_exe("foo.o").run();
-    build_native_static_lib("foo");
+    // Compile C code without LTO
+    cc().input("foo.c").arg("-c").arg("-fno-lto").out_exe("foo.o").run();
+    llvm_ar().obj_to_ar().output_input(&static_lib_name("foo"), "foo.o").run();
 
     rustc().input("foo.rs").arg("-lstatic=foo").crate_type("cdylib").run();