Skip using int_util.c on UEFI targets

[nicholasbishop]

int_util.c includes stdlib.h if _WIN32 is defined. When compiling the UEFI targets with clang they are treated as Windows targets (e.g. if the Rust target is x86_64-unknown-uefi, the clang target is x86_64-unknown-windows-gnu). So stdlib.h gets included, even though we are compilling with -ffreestanding and don't want stdlib.h to be used. That file may not be present, or an incompatible version might be installed leading to typedef redefinition errors.

Fix by not using int_util.c if target_os == uefi.

This is a partial fix for rust-lang/rust#104326.

[Amanieu]

Are you sure this actually works? This file defines __compilerrt_abort_impl which is used by many other files in compiler-rt. Could we fix the clang target instead so it doesn't define _WIN32?

[nicholasbishop]

Are you sure this actually works? This file defines __compilerrt_abort_impl which is used by many other files in compiler-rt.

Ah, you're right. I didn't see an error but it's just that my test case didn't call anything that depends on that function.

Could we fix the clang target instead so it doesn't define _WIN32

That target we're passing into clang is x86_64-unknown-windows-gnu (or similar for the other UEFI targets), so it's not doing anything wrong by defining _WIN32. The best long-term solution would probably be to add real UEFI targets to clang. For now, maybe it would be best to just add UEFI to the list of targets that shouldn't use the C code?

[nicholasbishop]

Closing in favor of #506