mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
81d7069e34
rust/tests/run-make/cross-lang-lto/Makefile

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

58 lines
2.0 KiB
Makefile
Raw Normal View History

Ignore cross-lang-lto test for LLVM versions without ThinLTO.
2018-04-17 06:38:19 -05:00
Diagnose missing includes in run-make tests
2022-08-22 19:00:00 -05:00
include ../tools.mk
Ignore cross-lang-lto test for LLVM versions without ThinLTO.
2018-04-17 06:38:19 -05:00
Ignore LLVM-dependent run-make tests on Windows This should solve the PATH issue, and we don't need to test cross-lang LTO working on all OS-es.
2019-01-24 13:17:02 -06:00
# 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
When doing linker-plugin based LTO, write LLVM bitcode obj-files instead of embedding the bitcode into the regular object file.
2018-07-06 06:58:25 -05:00
# This test makes sure that the object files we generate are actually
# LLVM bitcode files (as used by linker LTO plugins) when compiling with
Stabilize linker-plugin based LTO.
2019-02-01 08:15:43 -06:00
# -Clinker-plugin-lto.
Add tests for -Z cross-lang-lto.
2018-04-16 09:26:40 -05:00
Workaround presence of LLVM library in stage0/lib This commit works around the newly-introduced LLVM shared library. This is needed such that llvm-config run from librustc_llvm's build script can correctly locate it's own LLVM, not the one in stage0/lib. The LLVM build system uses the DT_RUNPATH/RUNPATH header within the llvm-config binary, which we want to use, but because Cargo always adds the host compiler's "libdir" (stage0/lib in our case) to the dynamic linker's search path, we weren't properly finding the freshly-built LLVM in llvm/lib. By restoring the environment variable setting the search path to what bootstrap sees, the problem is resolved and librustc_llvm correctly links and finds the appropriate LLVM. Several run-make-fulldeps tests are also updated with similar handling.
2019-01-21 18:47:57 -06:00
# this only succeeds for bitcode files
bootstrap: Don't add LLVM's bin directory to the PATH for tool invocations.
2019-04-29 07:40:07 -05:00
ASSERT_IS_BITCODE_OBJ=("$(LLVM_BIN_DIR)"/llvm-bcanalyzer $(1))
EXTRACT_OBJS=(cd $(TMPDIR); rm -f ./*.o; "$(LLVM_BIN_DIR)"/llvm-ar x $(1))
Add tests for -Z cross-lang-lto.
2018-04-16 09:26:40 -05:00
Stabilize linker-plugin based LTO.
2019-02-01 08:15:43 -06:00
BUILD_LIB=$(RUSTC) lib.rs -Copt-level=2 -Clinker-plugin-lto -Ccodegen-units=1
BUILD_EXE=$(RUSTC) main.rs -Copt-level=2 -Clinker-plugin-lto -Ccodegen-units=1 --emit=obj
Add tests for -Z cross-lang-lto.
2018-04-16 09:26:40 -05:00
all: staticlib staticlib-fat-lto staticlib-thin-lto rlib exe cdylib rdylib
staticlib: lib.rs
run-make/cross-lang-lto: Make output artifact names consistent across platforms.
2018-04-23 04:48:51 -05:00
$(BUILD_LIB) --crate-type=staticlib -o $(TMPDIR)/liblib.a
When doing linker-plugin based LTO, write LLVM bitcode obj-files instead of embedding the bitcode into the regular object file.
2018-07-06 06:58:25 -05:00
$(call EXTRACT_OBJS, liblib.a)
Workaround presence of LLVM library in stage0/lib This commit works around the newly-introduced LLVM shared library. This is needed such that llvm-config run from librustc_llvm's build script can correctly locate it's own LLVM, not the one in stage0/lib. The LLVM build system uses the DT_RUNPATH/RUNPATH header within the llvm-config binary, which we want to use, but because Cargo always adds the host compiler's "libdir" (stage0/lib in our case) to the dynamic linker's search path, we weren't properly finding the freshly-built LLVM in llvm/lib. By restoring the environment variable setting the search path to what bootstrap sees, the problem is resolved and librustc_llvm correctly links and finds the appropriate LLVM. Several run-make-fulldeps tests are also updated with similar handling.
2019-01-21 18:47:57 -06:00
for file in $(TMPDIR)/liblib.*.rcgu.o; do $(call ASSERT_IS_BITCODE_OBJ, $$file); done
Add tests for -Z cross-lang-lto.
2018-04-16 09:26:40 -05:00
staticlib-fat-lto: lib.rs
$(BUILD_LIB) --crate-type=staticlib -o $(TMPDIR)/liblib-fat-lto.a -Clto=fat
When doing linker-plugin based LTO, write LLVM bitcode obj-files instead of embedding the bitcode into the regular object file.
2018-07-06 06:58:25 -05:00
$(call EXTRACT_OBJS, liblib-fat-lto.a)
Workaround presence of LLVM library in stage0/lib This commit works around the newly-introduced LLVM shared library. This is needed such that llvm-config run from librustc_llvm's build script can correctly locate it's own LLVM, not the one in stage0/lib. The LLVM build system uses the DT_RUNPATH/RUNPATH header within the llvm-config binary, which we want to use, but because Cargo always adds the host compiler's "libdir" (stage0/lib in our case) to the dynamic linker's search path, we weren't properly finding the freshly-built LLVM in llvm/lib. By restoring the environment variable setting the search path to what bootstrap sees, the problem is resolved and librustc_llvm correctly links and finds the appropriate LLVM. Several run-make-fulldeps tests are also updated with similar handling.
2019-01-21 18:47:57 -06:00
for file in $(TMPDIR)/liblib-fat-lto.*.rcgu.o; do $(call ASSERT_IS_BITCODE_OBJ, $$file); done
Add tests for -Z cross-lang-lto.
2018-04-16 09:26:40 -05:00
staticlib-thin-lto: lib.rs
$(BUILD_LIB) --crate-type=staticlib -o $(TMPDIR)/liblib-thin-lto.a -Clto=thin
When doing linker-plugin based LTO, write LLVM bitcode obj-files instead of embedding the bitcode into the regular object file.
2018-07-06 06:58:25 -05:00
$(call EXTRACT_OBJS, liblib-thin-lto.a)
Workaround presence of LLVM library in stage0/lib This commit works around the newly-introduced LLVM shared library. This is needed such that llvm-config run from librustc_llvm's build script can correctly locate it's own LLVM, not the one in stage0/lib. The LLVM build system uses the DT_RUNPATH/RUNPATH header within the llvm-config binary, which we want to use, but because Cargo always adds the host compiler's "libdir" (stage0/lib in our case) to the dynamic linker's search path, we weren't properly finding the freshly-built LLVM in llvm/lib. By restoring the environment variable setting the search path to what bootstrap sees, the problem is resolved and librustc_llvm correctly links and finds the appropriate LLVM. Several run-make-fulldeps tests are also updated with similar handling.
2019-01-21 18:47:57 -06:00
for file in $(TMPDIR)/liblib-thin-lto.*.rcgu.o; do $(call ASSERT_IS_BITCODE_OBJ, $$file); done
Add tests for -Z cross-lang-lto.
2018-04-16 09:26:40 -05:00
rlib: lib.rs
run-make/cross-lang-lto: Make output artifact names consistent across platforms.
2018-04-23 04:48:51 -05:00
$(BUILD_LIB) --crate-type=rlib -o $(TMPDIR)/liblib.rlib
When doing linker-plugin based LTO, write LLVM bitcode obj-files instead of embedding the bitcode into the regular object file.
2018-07-06 06:58:25 -05:00
$(call EXTRACT_OBJS, liblib.rlib)
Workaround presence of LLVM library in stage0/lib This commit works around the newly-introduced LLVM shared library. This is needed such that llvm-config run from librustc_llvm's build script can correctly locate it's own LLVM, not the one in stage0/lib. The LLVM build system uses the DT_RUNPATH/RUNPATH header within the llvm-config binary, which we want to use, but because Cargo always adds the host compiler's "libdir" (stage0/lib in our case) to the dynamic linker's search path, we weren't properly finding the freshly-built LLVM in llvm/lib. By restoring the environment variable setting the search path to what bootstrap sees, the problem is resolved and librustc_llvm correctly links and finds the appropriate LLVM. Several run-make-fulldeps tests are also updated with similar handling.
2019-01-21 18:47:57 -06:00
for file in $(TMPDIR)/liblib.*.rcgu.o; do $(call ASSERT_IS_BITCODE_OBJ, $$file); done
Add tests for -Z cross-lang-lto.
2018-04-16 09:26:40 -05:00
cdylib: lib.rs
$(BUILD_LIB) --crate-type=cdylib --emit=obj -o $(TMPDIR)/cdylib.o
Workaround presence of LLVM library in stage0/lib This commit works around the newly-introduced LLVM shared library. This is needed such that llvm-config run from librustc_llvm's build script can correctly locate it's own LLVM, not the one in stage0/lib. The LLVM build system uses the DT_RUNPATH/RUNPATH header within the llvm-config binary, which we want to use, but because Cargo always adds the host compiler's "libdir" (stage0/lib in our case) to the dynamic linker's search path, we weren't properly finding the freshly-built LLVM in llvm/lib. By restoring the environment variable setting the search path to what bootstrap sees, the problem is resolved and librustc_llvm correctly links and finds the appropriate LLVM. Several run-make-fulldeps tests are also updated with similar handling.
2019-01-21 18:47:57 -06:00
$(call ASSERT_IS_BITCODE_OBJ, $(TMPDIR)/cdylib.o)
Add tests for -Z cross-lang-lto.
2018-04-16 09:26:40 -05:00
rdylib: lib.rs
$(BUILD_LIB) --crate-type=dylib --emit=obj -o $(TMPDIR)/rdylib.o
Workaround presence of LLVM library in stage0/lib This commit works around the newly-introduced LLVM shared library. This is needed such that llvm-config run from librustc_llvm's build script can correctly locate it's own LLVM, not the one in stage0/lib. The LLVM build system uses the DT_RUNPATH/RUNPATH header within the llvm-config binary, which we want to use, but because Cargo always adds the host compiler's "libdir" (stage0/lib in our case) to the dynamic linker's search path, we weren't properly finding the freshly-built LLVM in llvm/lib. By restoring the environment variable setting the search path to what bootstrap sees, the problem is resolved and librustc_llvm correctly links and finds the appropriate LLVM. Several run-make-fulldeps tests are also updated with similar handling.
2019-01-21 18:47:57 -06:00
$(call ASSERT_IS_BITCODE_OBJ, $(TMPDIR)/rdylib.o)
Add tests for -Z cross-lang-lto.
2018-04-16 09:26:40 -05:00
exe: lib.rs
$(BUILD_EXE) -o $(TMPDIR)/exe.o
Workaround presence of LLVM library in stage0/lib This commit works around the newly-introduced LLVM shared library. This is needed such that llvm-config run from librustc_llvm's build script can correctly locate it's own LLVM, not the one in stage0/lib. The LLVM build system uses the DT_RUNPATH/RUNPATH header within the llvm-config binary, which we want to use, but because Cargo always adds the host compiler's "libdir" (stage0/lib in our case) to the dynamic linker's search path, we weren't properly finding the freshly-built LLVM in llvm/lib. By restoring the environment variable setting the search path to what bootstrap sees, the problem is resolved and librustc_llvm correctly links and finds the appropriate LLVM. Several run-make-fulldeps tests are also updated with similar handling.
2019-01-21 18:47:57 -06:00
$(call ASSERT_IS_BITCODE_OBJ, $(TMPDIR)/exe.o)
Ignore LLVM-dependent run-make tests on Windows This should solve the PATH issue, and we don't need to test cross-lang LTO working on all OS-es.
2019-01-24 13:17:02 -06:00
else
all:
endif
Reference in New Issue Copy Permalink