This should solve the PATH issue, and we don't need to test cross-lang
LTO working on all OS-es.
+# ignore windows due to libLLVM being present in PATH and the PATH and library path being the same
+# (so fixing it is harder). See #57765 for context
+ifndef IS_WINDOWS
+
# This test makes sure that we don't loose upstream object files when compiling
# staticlibs with -Zcross-lang-lto
# This test makes sure that we don't loose upstream object files when compiling
# staticlibs with -Zcross-lang-lto
$(RUSTC) staticlib.rs -Z cross-lang-lto -Ccodegen-units=1 -Clto=thin -L. -o $(TMPDIR)/staticlib.a
(cd $(TMPDIR); $(LD_LIB_PATH_ENVVAR)=$(REAL_LD_LIBRARY_PATH) llvm-ar x ./staticlib.a)
ls $(TMPDIR)/upstream.*.rcgu.o
$(RUSTC) staticlib.rs -Z cross-lang-lto -Ccodegen-units=1 -Clto=thin -L. -o $(TMPDIR)/staticlib.a
(cd $(TMPDIR); $(LD_LIB_PATH_ENVVAR)=$(REAL_LD_LIBRARY_PATH) llvm-ar x ./staticlib.a)
ls $(TMPDIR)/upstream.*.rcgu.o
+# ignore windows due to libLLVM being present in PATH and the PATH and library path being the same
+# (so fixing it is harder). See #57765 for context
+ifndef IS_WINDOWS
+
# This test makes sure that the object files we generate are actually
# LLVM bitcode files (as used by linker LTO plugins) when compiling with
# -Z cross-lang-lto.
# This test makes sure that the object files we generate are actually
# LLVM bitcode files (as used by linker LTO plugins) when compiling with
# -Z cross-lang-lto.
exe: lib.rs
$(BUILD_EXE) -o $(TMPDIR)/exe.o
$(call ASSERT_IS_BITCODE_OBJ, $(TMPDIR)/exe.o)
exe: lib.rs
$(BUILD_EXE) -o $(TMPDIR)/exe.o
$(call ASSERT_IS_BITCODE_OBJ, $(TMPDIR)/exe.o)