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

[jchecahi]

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:

=== STDERR ===
error: failed to process C static library `foo`: LTO object in C static library is not supported
error: aborting due to 1 previous error

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 (see #150992).

Fix by manually compiling the C code passing -fno-lto to cc() 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.

[rustbot]

r? @jdonszelmann

rustbot has assigned @jdonszelmann.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 20 candidates

[cezarbbb]

Hi @jchecahi! Thanks for fixing this LTO issue on RHEL/Fedora/CentOS systems, I wasn't aware that system CFLAGS could include LTO flags by default.

I have an open PR #155535 that also modifies this same test file to add Windows/macOS support for the +export-symbols feature. Our PRs will conflict since we're both changing rmake.rs.

I think it makes sense to incorporate your -fno-lto fix into my PR since I'm already rewriting most of that test file anyway. Would you be okay with that? I'll add you as co-author in the commit message. Otherwise if you prefer to keep this separate, I can rebase #155535 on top of yours once it merges.

[jchecahi]

Hi @jchecahi! Thanks for fixing this LTO issue on RHEL/Fedora/CentOS systems, I wasn't aware that system CFLAGS could include LTO flags by default.

I have an open PR #155535 that also modifies this same test file to add Windows/macOS support for the +export-symbols feature. Our PRs will conflict since we're both changing rmake.rs.

I think it makes sense to incorporate your -fno-lto fix into my PR since I'm already rewriting most of that test file anyway. Would you be okay with that? I'll add you as co-author in the commit message. Otherwise if you prefer to keep this separate, I can rebase #155535 on top of yours once it merges.

Hi @cezarbbb! Absolutely, I have no problem incorporating this PR into #155535 if that makes your life any easier :)

[cezarbbb]

I have updated PR #155535, please check :>

[jchecahi]

@cezarbbb thank you! Should I close this PR already?

[cezarbbb]

I think we should wait for the assignee's reply first?