nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-23 07:14:28 +00:00
Code Issues Packages Projects Releases Wiki Activity
93ee07c756
rust/tests/run-make/tools.mk

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

210 lines
6.7 KiB
Makefile
Raw Normal View History

Refactoring: Introduce distinct host and target rpath var setters. Two line summary: Distinguish HOST_RPATH and TARGET_RPATH; added RPATH_LINK_SEARCH; skip tests broken in stage1; general cleanup. `HOST_RPATH_VAR$(1)_T_$(2)_H_$(3)` and `TARGET_RPATH_VAR$(1)_T_$(2)_H_$(3)` both match the format of the old `RPATH_VAR$(1)_T_$(2)_H_$(3)` (which is still being set the same way that it was before, to one of either HOST/TARGET depending on what stage we are building). Namely, the format is <XXX>_RPATH_VAR = "<LD_LIB_PATH_ENVVAR>=<COLON_SEP_PATH_ENTRIES>" What this commit does: * Pass both of the (newly introduced) HOST and TARGET rpath setup vars to `maketest.py` * Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself Instead, it passes along the HOST and TARGET rpath setup vars in environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV` * Also, pass the current stage number to maketest.py; it in turn passes it (via an env var) to run-make tests. This allows the run-make tests to selectively change behavior (e.g. turn themselves off) to deal with incompatibilities with e.g. stage1. * Cleanup: Distinguish in tools.mk between the command to run (`RUN`) and the file to generate to drive that command (`RUN_BINFILE`). The main thing this enables is that `RUN` can now setup the `TARGET_RPATH_ENV` without having to dirty up the runner code in each of the `run-make` Makefiles. * Cleanup: Factored out commands to delete dylib/rlib into REMOVE_DYLIBS/REMOVE_RLIBS. There were places where we were only calling `rm $(call DYLIB,foo)` even though we really needed to get rid of the whole glob (at least based on alex's findings on #13753 that removing the symlink does not suffice). Therefore rather than peppering the code with the awkward `rm $(TMPDIR)/$(call DYLIB_GLOB,foo)`, I instead introduced a common `REMOVE_DYLIBS` user function that expands into that when called. After I adding an analogous `REMOVE_RLIBS`, I changed all of the existing calls that rm dylibs or rlibs to use these routines instead. Note that the latter is not a true refactoring since I may have changed cases where it was our intent to only remove the sym-link. (But if that is the case, then we need to more deeply investigate alex's findings on #13753 where the system was still dynamically loading up the non-symlinked libraries that it finds on the load path.) * Added RPATH_LINK_SEARCH command and use it on Linux. On some platforms, namely Linux, when you have libboot.so that has its internal rpath set (to e.g. $(ORIGIN)/path/to/HOSTDIR), the linker still complains when you do the link step and it does not know where to find libraries that libboot.so depends upon that live in HOSTDIR (think e.g. librustuv.so). As far as I can tell, the GNU linker will consult the LD_LIBRARY_PATH as part of the linking process to find such libraries. But if you want to be more careful and not override LD_LIBRARY_PATH for the `gcc` invocation, then you need some other way to tell the linker where it can find the libraries that libboot.so needs. The solution to this on Linux is the `-Wl,-rpath-link` command line option. However, this command line option does not exist on Mac OS X, (which appears to be figuring out how to resolve the libboot.dylib dependency by some other means, perhaps by consulting the rpath setting within libboot.dylib). So, in order to abstract over this distinction, I added the RPATH_LINK_SEARCH macro to the run-make infrastructure and added calls to it where necessary to get Linux working. On architectures other than Linux, the macro expands to nothing. * Disable miscellaneous tests atop stage1. * An especially interesting instance of the previous bullet point: Excuse regex from doing rustdoc tests atop stage1. This was a (nearly-) final step to get `make check-stage1` working again. The use of a special-case check for regex here is ugly but is analogous other similar checks for regex such as the one that landed in PR #13844. The way this is written, the user will get a reminder that doc-crate-regex is being skipped whenever their rules attempt to do the crate documentation tests. This is deliberate: I want people running `make check-stage1` to be reminded about which cases are being skipped. (But if such echo noise is considered offensive, it can obviously be removed.) * Got windows working with the above changes. This portion of the commit is a cleanup revision of the (previously mentioned on try builds) re-architecting of how the LD_LIBRARY_PATH setup and extension is handled in order to accommodate Windows' (1.) use of `$PATH` for that purpose and (2.) use of spaces in `$PATH` entries (problematic for make and for interoperation with tools at the shell). * In addition, since the code has been rearchitected to pass the HOST_RPATH_DIR/TARGET_RPATH_DIR rather than a whole sh environment-variable setting command, there is no need to for the convert_path_spec calls in maketest.py, which in fact were put in place to placate Windows but were now causing the Windows builds to fail. Instead we just convert the paths to absolute paths just like all of the other path arguments. Also, note for makefile hackers: apparently you cannot quote operands to `ifeq` in Makefile (or at least, you need to be careful about adding them, e.g. to only one side).
2014-04-25 16:22:23 +00:00
# These deliberately use `=` and not `:=` so that client makefiles can
# augment HOST_RPATH_DIR / TARGET_RPATH_DIR.
HOST_RPATH_ENV = \
test: readd TMPDIR to LD_LIBRARY_PATH for run-make It was accidentally removed in #15006 and that somehow got past the build bots, causing `src/test/run-make/c-dynamic-dylib` to fail on at least my linux system. This resolves #15103 (thanks to @alexcrichton!).
2014-06-23 11:12:37 +00:00
$(LD_LIB_PATH_ENVVAR)="$(TMPDIR):$(HOST_RPATH_DIR):$($(LD_LIB_PATH_ENVVAR))"
Refactoring: Introduce distinct host and target rpath var setters. Two line summary: Distinguish HOST_RPATH and TARGET_RPATH; added RPATH_LINK_SEARCH; skip tests broken in stage1; general cleanup. `HOST_RPATH_VAR$(1)_T_$(2)_H_$(3)` and `TARGET_RPATH_VAR$(1)_T_$(2)_H_$(3)` both match the format of the old `RPATH_VAR$(1)_T_$(2)_H_$(3)` (which is still being set the same way that it was before, to one of either HOST/TARGET depending on what stage we are building). Namely, the format is <XXX>_RPATH_VAR = "<LD_LIB_PATH_ENVVAR>=<COLON_SEP_PATH_ENTRIES>" What this commit does: * Pass both of the (newly introduced) HOST and TARGET rpath setup vars to `maketest.py` * Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself Instead, it passes along the HOST and TARGET rpath setup vars in environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV` * Also, pass the current stage number to maketest.py; it in turn passes it (via an env var) to run-make tests. This allows the run-make tests to selectively change behavior (e.g. turn themselves off) to deal with incompatibilities with e.g. stage1. * Cleanup: Distinguish in tools.mk between the command to run (`RUN`) and the file to generate to drive that command (`RUN_BINFILE`). The main thing this enables is that `RUN` can now setup the `TARGET_RPATH_ENV` without having to dirty up the runner code in each of the `run-make` Makefiles. * Cleanup: Factored out commands to delete dylib/rlib into REMOVE_DYLIBS/REMOVE_RLIBS. There were places where we were only calling `rm $(call DYLIB,foo)` even though we really needed to get rid of the whole glob (at least based on alex's findings on #13753 that removing the symlink does not suffice). Therefore rather than peppering the code with the awkward `rm $(TMPDIR)/$(call DYLIB_GLOB,foo)`, I instead introduced a common `REMOVE_DYLIBS` user function that expands into that when called. After I adding an analogous `REMOVE_RLIBS`, I changed all of the existing calls that rm dylibs or rlibs to use these routines instead. Note that the latter is not a true refactoring since I may have changed cases where it was our intent to only remove the sym-link. (But if that is the case, then we need to more deeply investigate alex's findings on #13753 where the system was still dynamically loading up the non-symlinked libraries that it finds on the load path.) * Added RPATH_LINK_SEARCH command and use it on Linux. On some platforms, namely Linux, when you have libboot.so that has its internal rpath set (to e.g. $(ORIGIN)/path/to/HOSTDIR), the linker still complains when you do the link step and it does not know where to find libraries that libboot.so depends upon that live in HOSTDIR (think e.g. librustuv.so). As far as I can tell, the GNU linker will consult the LD_LIBRARY_PATH as part of the linking process to find such libraries. But if you want to be more careful and not override LD_LIBRARY_PATH for the `gcc` invocation, then you need some other way to tell the linker where it can find the libraries that libboot.so needs. The solution to this on Linux is the `-Wl,-rpath-link` command line option. However, this command line option does not exist on Mac OS X, (which appears to be figuring out how to resolve the libboot.dylib dependency by some other means, perhaps by consulting the rpath setting within libboot.dylib). So, in order to abstract over this distinction, I added the RPATH_LINK_SEARCH macro to the run-make infrastructure and added calls to it where necessary to get Linux working. On architectures other than Linux, the macro expands to nothing. * Disable miscellaneous tests atop stage1. * An especially interesting instance of the previous bullet point: Excuse regex from doing rustdoc tests atop stage1. This was a (nearly-) final step to get `make check-stage1` working again. The use of a special-case check for regex here is ugly but is analogous other similar checks for regex such as the one that landed in PR #13844. The way this is written, the user will get a reminder that doc-crate-regex is being skipped whenever their rules attempt to do the crate documentation tests. This is deliberate: I want people running `make check-stage1` to be reminded about which cases are being skipped. (But if such echo noise is considered offensive, it can obviously be removed.) * Got windows working with the above changes. This portion of the commit is a cleanup revision of the (previously mentioned on try builds) re-architecting of how the LD_LIBRARY_PATH setup and extension is handled in order to accommodate Windows' (1.) use of `$PATH` for that purpose and (2.) use of spaces in `$PATH` entries (problematic for make and for interoperation with tools at the shell). * In addition, since the code has been rearchitected to pass the HOST_RPATH_DIR/TARGET_RPATH_DIR rather than a whole sh environment-variable setting command, there is no need to for the convert_path_spec calls in maketest.py, which in fact were put in place to placate Windows but were now causing the Windows builds to fail. Instead we just convert the paths to absolute paths just like all of the other path arguments. Also, note for makefile hackers: apparently you cannot quote operands to `ifeq` in Makefile (or at least, you need to be careful about adding them, e.g. to only one side).
2014-04-25 16:22:23 +00:00
TARGET_RPATH_ENV = \
test: readd TMPDIR to LD_LIBRARY_PATH for run-make It was accidentally removed in #15006 and that somehow got past the build bots, causing `src/test/run-make/c-dynamic-dylib` to fail on at least my linux system. This resolves #15103 (thanks to @alexcrichton!).
2014-06-23 11:12:37 +00:00
$(LD_LIB_PATH_ENVVAR)="$(TMPDIR):$(TARGET_RPATH_DIR):$($(LD_LIB_PATH_ENVVAR))"
Fix --disable-rpath and tests This involved a few changes to the local build system: * Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH in order to support building rust with rust already installed. * The compiletest program was taught to correctly pass through the aux dir as a component of LD_LIBRARY_PATH in more situations. This change was spliced out of #14832 to consist of just the fixes to running tests without an rpath setting embedded in executables.
2014-06-11 21:52:38 +00:00
rustc: Attempt to handle super long linker invocations This commit adds logic to the compiler to attempt to handle super long linker invocations by falling back to the `@`-file syntax if the invoked command is too large. Each OS has a limit on how many arguments and how large the arguments can be when spawning a new process, and linkers tend to be one of those programs that can hit the limit! The logic implemented here is to unconditionally attempt to spawn a linker and then if it fails to spawn with an error from the OS that indicates the command line is too big we attempt a fallback. The fallback is roughly the same for all linkers where an argument pointing to a file, prepended with `@`, is passed. This file then contains all the various arguments that we want to pass to the linker. Closes #41190
2017-08-26 03:16:51 +00:00
RUSTC_ORIGINAL := $(RUSTC)
test: Move run-make tests into compiletest Forcing them to be embedded in makefiles precludes being able to run them in rustbuild, and adding them to compiletest gives us a great way to leverage future enhancements to our "all encompassing test suite runner" as well as just moving more things into Rust. All tests are still Makefile-based in the sense that they rely on `make` being available to run them, but there's no longer any Makefile-trickery to run them and rustbuild can now run them out of the box as well.
2016-04-14 22:51:03 +00:00
BARE_RUSTC := $(HOST_RPATH_ENV) '$(RUSTC)'
rustbuild: Support specifying archiver and linker explicitly
2017-10-10 20:06:22 +00:00
BARE_RUSTDOC := $(HOST_RPATH_ENV) '$(RUSTDOC)'
Add `internal_features` lint It lints against features that are inteded to be internal to the compiler and standard library. Implements MCP #596. We allow `internal_features` in the standard library and compiler as those use many features and this _is_ the standard library from the "internal to the compiler and standard library" after all. Marking some features as internal wasn't exactly the most scientific approach, I just marked some mostly obvious features. While there is a categorization in the macro, it's not very well upheld (should probably be fixed in another PR). We always pass `-Ainternal_features` in the testsuite About 400 UI tests and several other tests use internal features. Instead of throwing the attribute on each one, just always allow them. There's nothing wrong with testing internal features^^
2023-03-09 20:54:53 +00:00
RUSTC := $(BARE_RUSTC) --out-dir $(TMPDIR) -L $(TMPDIR) $(RUSTFLAGS) -Ainternal_features
Allow test target to pass without installing explicitly pass -L target-lib to rustdoc
2018-03-18 17:08:17 +00:00
RUSTDOC := $(BARE_RUSTDOC) -L $(TARGET_RPATH_DIR)
rustbuild: Support specifying archiver and linker explicitly
2017-10-10 20:06:22 +00:00
ifdef RUSTC_LINKER
rustbuild: Build tests with LLD if `use-lld = true` was passed
2020-09-04 17:54:07 +00:00
RUSTC := $(RUSTC) -Clinker='$(RUSTC_LINKER)'
RUSTDOC := $(RUSTDOC) -Clinker='$(RUSTC_LINKER)'
rustbuild: Support specifying archiver and linker explicitly
2017-10-10 20:06:22 +00:00
endif
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
#CC := $(CC) -L $(TMPDIR)
Fix Makefile themes check
2019-11-18 17:53:45 +00:00
HTMLDOCCK := '$(PYTHON)' '$(S)/src/etc/htmldocck.py'
Replace most call to grep in run-make by a script that cat the input. Introduced a new src/etc/cat-and-grep.sh script (called in run-make as $(CGREP)), which prints the input and do a grep simultaneously. This is mainly used to debug spurious failures in run-make, such as the sanitizer error in #45810, as well as real errors such as #46126.
2017-11-23 15:19:50 +00:00
CGREP := "$(S)/src/etc/cat-and-grep.sh"
Refactoring: Introduce distinct host and target rpath var setters. Two line summary: Distinguish HOST_RPATH and TARGET_RPATH; added RPATH_LINK_SEARCH; skip tests broken in stage1; general cleanup. `HOST_RPATH_VAR$(1)_T_$(2)_H_$(3)` and `TARGET_RPATH_VAR$(1)_T_$(2)_H_$(3)` both match the format of the old `RPATH_VAR$(1)_T_$(2)_H_$(3)` (which is still being set the same way that it was before, to one of either HOST/TARGET depending on what stage we are building). Namely, the format is <XXX>_RPATH_VAR = "<LD_LIB_PATH_ENVVAR>=<COLON_SEP_PATH_ENTRIES>" What this commit does: * Pass both of the (newly introduced) HOST and TARGET rpath setup vars to `maketest.py` * Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself Instead, it passes along the HOST and TARGET rpath setup vars in environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV` * Also, pass the current stage number to maketest.py; it in turn passes it (via an env var) to run-make tests. This allows the run-make tests to selectively change behavior (e.g. turn themselves off) to deal with incompatibilities with e.g. stage1. * Cleanup: Distinguish in tools.mk between the command to run (`RUN`) and the file to generate to drive that command (`RUN_BINFILE`). The main thing this enables is that `RUN` can now setup the `TARGET_RPATH_ENV` without having to dirty up the runner code in each of the `run-make` Makefiles. * Cleanup: Factored out commands to delete dylib/rlib into REMOVE_DYLIBS/REMOVE_RLIBS. There were places where we were only calling `rm $(call DYLIB,foo)` even though we really needed to get rid of the whole glob (at least based on alex's findings on #13753 that removing the symlink does not suffice). Therefore rather than peppering the code with the awkward `rm $(TMPDIR)/$(call DYLIB_GLOB,foo)`, I instead introduced a common `REMOVE_DYLIBS` user function that expands into that when called. After I adding an analogous `REMOVE_RLIBS`, I changed all of the existing calls that rm dylibs or rlibs to use these routines instead. Note that the latter is not a true refactoring since I may have changed cases where it was our intent to only remove the sym-link. (But if that is the case, then we need to more deeply investigate alex's findings on #13753 where the system was still dynamically loading up the non-symlinked libraries that it finds on the load path.) * Added RPATH_LINK_SEARCH command and use it on Linux. On some platforms, namely Linux, when you have libboot.so that has its internal rpath set (to e.g. $(ORIGIN)/path/to/HOSTDIR), the linker still complains when you do the link step and it does not know where to find libraries that libboot.so depends upon that live in HOSTDIR (think e.g. librustuv.so). As far as I can tell, the GNU linker will consult the LD_LIBRARY_PATH as part of the linking process to find such libraries. But if you want to be more careful and not override LD_LIBRARY_PATH for the `gcc` invocation, then you need some other way to tell the linker where it can find the libraries that libboot.so needs. The solution to this on Linux is the `-Wl,-rpath-link` command line option. However, this command line option does not exist on Mac OS X, (which appears to be figuring out how to resolve the libboot.dylib dependency by some other means, perhaps by consulting the rpath setting within libboot.dylib). So, in order to abstract over this distinction, I added the RPATH_LINK_SEARCH macro to the run-make infrastructure and added calls to it where necessary to get Linux working. On architectures other than Linux, the macro expands to nothing. * Disable miscellaneous tests atop stage1. * An especially interesting instance of the previous bullet point: Excuse regex from doing rustdoc tests atop stage1. This was a (nearly-) final step to get `make check-stage1` working again. The use of a special-case check for regex here is ugly but is analogous other similar checks for regex such as the one that landed in PR #13844. The way this is written, the user will get a reminder that doc-crate-regex is being skipped whenever their rules attempt to do the crate documentation tests. This is deliberate: I want people running `make check-stage1` to be reminded about which cases are being skipped. (But if such echo noise is considered offensive, it can obviously be removed.) * Got windows working with the above changes. This portion of the commit is a cleanup revision of the (previously mentioned on try builds) re-architecting of how the LD_LIBRARY_PATH setup and extension is handled in order to accommodate Windows' (1.) use of `$PATH` for that purpose and (2.) use of spaces in `$PATH` entries (problematic for make and for interoperation with tools at the shell). * In addition, since the code has been rearchitected to pass the HOST_RPATH_DIR/TARGET_RPATH_DIR rather than a whole sh environment-variable setting command, there is no need to for the convert_path_spec calls in maketest.py, which in fact were put in place to placate Windows but were now causing the Windows builds to fail. Instead we just convert the paths to absolute paths just like all of the other path arguments. Also, note for makefile hackers: apparently you cannot quote operands to `ifeq` in Makefile (or at least, you need to be careful about adding them, e.g. to only one side).
2014-04-25 16:22:23 +00:00
Generating the coverage map rustc now generates the coverage map and can support (limited) coverage report generation, at the function level. Example: $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE="main.profraw" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main 1| 1|pub fn will_be_called() { 2| 1| println!("called"); 3| 1|} 4| | 5| 0|pub fn will_not_be_called() { 6| 0| println!("should not have been called"); 7| 0|} 8| | 9| 1|fn main() { 10| 1| let less = 1; 11| 1| let more = 100; 12| 1| 13| 1| if less < more { 14| 1| will_be_called(); 15| 1| } else { 16| 1| will_not_be_called(); 17| 1| } 18| 1|}
2020-07-02 18:27:15 +00:00
# diff with common flags for multi-platform diffs against text output
DIFF := diff -u --strip-trailing-cr
tests/run-make: Move RUSTC_TEST_OP to tools.mk To reduce duplication. A follow-up commit will begin using it in even more places.
2023-10-07 06:14:38 +00:00
# With RUSTC_TEST_OP you can elegantly support blessing of run-make tests. Do
# like this in a Makefile recipe:
#
# "$(TMPDIR)"/your-test > "$(TMPDIR)"/your-test.run.stdout
# $(RUSTC_TEST_OP) "$(TMPDIR)"/your-test.run.stdout your-test.run.stdout
#
# When running the test normally with
#
# ./x test tests/run-make/your-test
#
# the actual output will be diffed against the expected output. When running in
# bless-mode with
#
# ./x test --bless tests/run-make/your-test
#
# the actual output will be blessed as the expected output.
ifdef RUSTC_BLESS_TEST
RUSTC_TEST_OP = cp
else
RUSTC_TEST_OP = $(DIFF)
endif
Set SHELL = /bin/dash only if it exists
2021-02-06 01:50:37 +00:00
# Some of the Rust CI platforms use `/bin/dash` to run `shell` script in
# Makefiles. Other platforms, including many developer platforms, default to
# `/bin/bash`. (In many cases, `make` is actually using `/bin/sh`, but `sh`
# is configured to execute one or the other shell binary). `dash` features
# support only a small subset of `bash` features, so `dash` can be thought of as
# the lowest common denominator, and tests should be validated against `dash`
# whenever possible. Most developer platforms include `/bin/dash`, but to ensure
# tests still work when `/bin/dash`, if not available, this `SHELL` override is
# conditional:
Disabled SHELL=dash on Windows due to invalid path backslash handling Calling an executable via full path with Windows backslashes fails in dash.
2021-02-13 08:14:50 +00:00
ifndef IS_WINDOWS # dash interprets backslashes in executable paths incorrectly
Set SHELL = /bin/dash only if it exists
2021-02-06 01:50:37 +00:00
ifneq (,$(wildcard /bin/dash))
Ensures `make` tests run under /bin/dash, like CI, and fixes a Makefile Updates `tools.mk` to explicitly require `SHELL := /bin/dash`, since CI uses `dash` but other environments (including developer local machines) may default to `bash`. Replaces bash-specific shell command in one Makefile with a dash-compatible alternative, and re-enables the affected Makefile test. Removes apparently redundant definition of `UNAME`.
2021-02-04 00:26:25 +00:00
SHELL := /bin/dash
Set SHELL = /bin/dash only if it exists
2021-02-06 01:50:37 +00:00
endif
Disabled SHELL=dash on Windows due to invalid path backslash handling Calling an executable via full path with Windows backslashes fails in dash.
2021-02-13 08:14:50 +00:00
endif
Ensures `make` tests run under /bin/dash, like CI, and fixes a Makefile Updates `tools.mk` to explicitly require `SHELL := /bin/dash`, since CI uses `dash` but other environments (including developer local machines) may default to `bash`. Replaces bash-specific shell command in one Makefile with a dash-compatible alternative, and re-enables the affected Makefile test. Removes apparently redundant definition of `UNAME`.
2021-02-04 00:26:25 +00:00
Refactoring: Introduce distinct host and target rpath var setters. Two line summary: Distinguish HOST_RPATH and TARGET_RPATH; added RPATH_LINK_SEARCH; skip tests broken in stage1; general cleanup. `HOST_RPATH_VAR$(1)_T_$(2)_H_$(3)` and `TARGET_RPATH_VAR$(1)_T_$(2)_H_$(3)` both match the format of the old `RPATH_VAR$(1)_T_$(2)_H_$(3)` (which is still being set the same way that it was before, to one of either HOST/TARGET depending on what stage we are building). Namely, the format is <XXX>_RPATH_VAR = "<LD_LIB_PATH_ENVVAR>=<COLON_SEP_PATH_ENTRIES>" What this commit does: * Pass both of the (newly introduced) HOST and TARGET rpath setup vars to `maketest.py` * Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself Instead, it passes along the HOST and TARGET rpath setup vars in environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV` * Also, pass the current stage number to maketest.py; it in turn passes it (via an env var) to run-make tests. This allows the run-make tests to selectively change behavior (e.g. turn themselves off) to deal with incompatibilities with e.g. stage1. * Cleanup: Distinguish in tools.mk between the command to run (`RUN`) and the file to generate to drive that command (`RUN_BINFILE`). The main thing this enables is that `RUN` can now setup the `TARGET_RPATH_ENV` without having to dirty up the runner code in each of the `run-make` Makefiles. * Cleanup: Factored out commands to delete dylib/rlib into REMOVE_DYLIBS/REMOVE_RLIBS. There were places where we were only calling `rm $(call DYLIB,foo)` even though we really needed to get rid of the whole glob (at least based on alex's findings on #13753 that removing the symlink does not suffice). Therefore rather than peppering the code with the awkward `rm $(TMPDIR)/$(call DYLIB_GLOB,foo)`, I instead introduced a common `REMOVE_DYLIBS` user function that expands into that when called. After I adding an analogous `REMOVE_RLIBS`, I changed all of the existing calls that rm dylibs or rlibs to use these routines instead. Note that the latter is not a true refactoring since I may have changed cases where it was our intent to only remove the sym-link. (But if that is the case, then we need to more deeply investigate alex's findings on #13753 where the system was still dynamically loading up the non-symlinked libraries that it finds on the load path.) * Added RPATH_LINK_SEARCH command and use it on Linux. On some platforms, namely Linux, when you have libboot.so that has its internal rpath set (to e.g. $(ORIGIN)/path/to/HOSTDIR), the linker still complains when you do the link step and it does not know where to find libraries that libboot.so depends upon that live in HOSTDIR (think e.g. librustuv.so). As far as I can tell, the GNU linker will consult the LD_LIBRARY_PATH as part of the linking process to find such libraries. But if you want to be more careful and not override LD_LIBRARY_PATH for the `gcc` invocation, then you need some other way to tell the linker where it can find the libraries that libboot.so needs. The solution to this on Linux is the `-Wl,-rpath-link` command line option. However, this command line option does not exist on Mac OS X, (which appears to be figuring out how to resolve the libboot.dylib dependency by some other means, perhaps by consulting the rpath setting within libboot.dylib). So, in order to abstract over this distinction, I added the RPATH_LINK_SEARCH macro to the run-make infrastructure and added calls to it where necessary to get Linux working. On architectures other than Linux, the macro expands to nothing. * Disable miscellaneous tests atop stage1. * An especially interesting instance of the previous bullet point: Excuse regex from doing rustdoc tests atop stage1. This was a (nearly-) final step to get `make check-stage1` working again. The use of a special-case check for regex here is ugly but is analogous other similar checks for regex such as the one that landed in PR #13844. The way this is written, the user will get a reminder that doc-crate-regex is being skipped whenever their rules attempt to do the crate documentation tests. This is deliberate: I want people running `make check-stage1` to be reminded about which cases are being skipped. (But if such echo noise is considered offensive, it can obviously be removed.) * Got windows working with the above changes. This portion of the commit is a cleanup revision of the (previously mentioned on try builds) re-architecting of how the LD_LIBRARY_PATH setup and extension is handled in order to accommodate Windows' (1.) use of `$PATH` for that purpose and (2.) use of spaces in `$PATH` entries (problematic for make and for interoperation with tools at the shell). * In addition, since the code has been rearchitected to pass the HOST_RPATH_DIR/TARGET_RPATH_DIR rather than a whole sh environment-variable setting command, there is no need to for the convert_path_spec calls in maketest.py, which in fact were put in place to placate Windows but were now causing the Windows builds to fail. Instead we just convert the paths to absolute paths just like all of the other path arguments. Also, note for makefile hackers: apparently you cannot quote operands to `ifeq` in Makefile (or at least, you need to be careful about adding them, e.g. to only one side).
2014-04-25 16:22:23 +00:00
# This is the name of the binary we will generate and run; use this
# e.g. for `$(CC) -o $(RUN_BINFILE)`.
RUN_BINFILE = $(TMPDIR)/$(1)
run tests on the remote device even when the default address is used When running tests inside the Android emulator, bootstrap doesn't set the TEST_DEVICE_ADDR environment variable, as the default address (127.0.0.1:12345) is used. Instead, REMOTE_TEST_CLIENT is set all the times when remote testing is needed, and in no other cases. To ensure Android tests are executed in the emulator, change the check.
2022-11-03 15:04:07 +00:00
# Invoke the generated binary on the remote machine if compiletest was
# configured to use a remote test device, otherwise run it on the current host.
ifdef REMOTE_TEST_CLIENT
add support for running binaries with remote-test-client on run-make
2022-09-26 10:59:22 +00:00
# FIXME: if a test requires additional files, this will need to be changed to
# also push them (by changing the 0 to the number of additional files, and
# providing the path of the additional files as the last arguments).
EXECUTE = $(REMOTE_TEST_CLIENT) run 0 $(RUN_BINFILE)
else
EXECUTE = $(RUN_BINFILE)
endif
Refactoring: Introduce distinct host and target rpath var setters. Two line summary: Distinguish HOST_RPATH and TARGET_RPATH; added RPATH_LINK_SEARCH; skip tests broken in stage1; general cleanup. `HOST_RPATH_VAR$(1)_T_$(2)_H_$(3)` and `TARGET_RPATH_VAR$(1)_T_$(2)_H_$(3)` both match the format of the old `RPATH_VAR$(1)_T_$(2)_H_$(3)` (which is still being set the same way that it was before, to one of either HOST/TARGET depending on what stage we are building). Namely, the format is <XXX>_RPATH_VAR = "<LD_LIB_PATH_ENVVAR>=<COLON_SEP_PATH_ENTRIES>" What this commit does: * Pass both of the (newly introduced) HOST and TARGET rpath setup vars to `maketest.py` * Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself Instead, it passes along the HOST and TARGET rpath setup vars in environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV` * Also, pass the current stage number to maketest.py; it in turn passes it (via an env var) to run-make tests. This allows the run-make tests to selectively change behavior (e.g. turn themselves off) to deal with incompatibilities with e.g. stage1. * Cleanup: Distinguish in tools.mk between the command to run (`RUN`) and the file to generate to drive that command (`RUN_BINFILE`). The main thing this enables is that `RUN` can now setup the `TARGET_RPATH_ENV` without having to dirty up the runner code in each of the `run-make` Makefiles. * Cleanup: Factored out commands to delete dylib/rlib into REMOVE_DYLIBS/REMOVE_RLIBS. There were places where we were only calling `rm $(call DYLIB,foo)` even though we really needed to get rid of the whole glob (at least based on alex's findings on #13753 that removing the symlink does not suffice). Therefore rather than peppering the code with the awkward `rm $(TMPDIR)/$(call DYLIB_GLOB,foo)`, I instead introduced a common `REMOVE_DYLIBS` user function that expands into that when called. After I adding an analogous `REMOVE_RLIBS`, I changed all of the existing calls that rm dylibs or rlibs to use these routines instead. Note that the latter is not a true refactoring since I may have changed cases where it was our intent to only remove the sym-link. (But if that is the case, then we need to more deeply investigate alex's findings on #13753 where the system was still dynamically loading up the non-symlinked libraries that it finds on the load path.) * Added RPATH_LINK_SEARCH command and use it on Linux. On some platforms, namely Linux, when you have libboot.so that has its internal rpath set (to e.g. $(ORIGIN)/path/to/HOSTDIR), the linker still complains when you do the link step and it does not know where to find libraries that libboot.so depends upon that live in HOSTDIR (think e.g. librustuv.so). As far as I can tell, the GNU linker will consult the LD_LIBRARY_PATH as part of the linking process to find such libraries. But if you want to be more careful and not override LD_LIBRARY_PATH for the `gcc` invocation, then you need some other way to tell the linker where it can find the libraries that libboot.so needs. The solution to this on Linux is the `-Wl,-rpath-link` command line option. However, this command line option does not exist on Mac OS X, (which appears to be figuring out how to resolve the libboot.dylib dependency by some other means, perhaps by consulting the rpath setting within libboot.dylib). So, in order to abstract over this distinction, I added the RPATH_LINK_SEARCH macro to the run-make infrastructure and added calls to it where necessary to get Linux working. On architectures other than Linux, the macro expands to nothing. * Disable miscellaneous tests atop stage1. * An especially interesting instance of the previous bullet point: Excuse regex from doing rustdoc tests atop stage1. This was a (nearly-) final step to get `make check-stage1` working again. The use of a special-case check for regex here is ugly but is analogous other similar checks for regex such as the one that landed in PR #13844. The way this is written, the user will get a reminder that doc-crate-regex is being skipped whenever their rules attempt to do the crate documentation tests. This is deliberate: I want people running `make check-stage1` to be reminded about which cases are being skipped. (But if such echo noise is considered offensive, it can obviously be removed.) * Got windows working with the above changes. This portion of the commit is a cleanup revision of the (previously mentioned on try builds) re-architecting of how the LD_LIBRARY_PATH setup and extension is handled in order to accommodate Windows' (1.) use of `$PATH` for that purpose and (2.) use of spaces in `$PATH` entries (problematic for make and for interoperation with tools at the shell). * In addition, since the code has been rearchitected to pass the HOST_RPATH_DIR/TARGET_RPATH_DIR rather than a whole sh environment-variable setting command, there is no need to for the convert_path_spec calls in maketest.py, which in fact were put in place to placate Windows but were now causing the Windows builds to fail. Instead we just convert the paths to absolute paths just like all of the other path arguments. Also, note for makefile hackers: apparently you cannot quote operands to `ifeq` in Makefile (or at least, you need to be careful about adding them, e.g. to only one side).
2014-04-25 16:22:23 +00:00
# RUN and FAIL are basic way we will invoke the generated binary. On
# non-windows platforms, they set the LD_LIBRARY_PATH environment
# variable before running the binary.
Add a new run-make test directory This infrastructure is meant to support runnings tests that involve various interesting interdependencies about the types of crates being linked or possibly interacting with C libraries. The goal of these make tests is to not restrict them to a particular test runner, but allow each test to run its own tests. To this end, there is a new src/test/run-make directory which has sub-folders of tests. Each test requires a `Makefile`, and running the tests constitues simply running `make` inside the directory. The new target is `check-stageN-rmake`. These tests will have the destination directory (as TMPDIR) and the local rust compiler (as RUSTC) passed along to them. There is also some helpful cross-platform utilities included in src/test/run-make/tools.mk to aid with compiling C programs and running them. The impetus for adding this new test suite is to allow various interesting forms of testing rust linkage. All of the tests initially added are various flavors of compiling Rust and C with one another as well as just making sure that rust linkage works in general. Closes #10434
2013-11-17 01:07:32 +00:00
RLIB_GLOB = lib$(1)*.rlib
test: Fix run-make on windows
2014-04-27 07:52:36 +00:00
BIN = $(1)
Add a new run-make test directory This infrastructure is meant to support runnings tests that involve various interesting interdependencies about the types of crates being linked or possibly interacting with C libraries. The goal of these make tests is to not restrict them to a particular test runner, but allow each test to run its own tests. To this end, there is a new src/test/run-make directory which has sub-folders of tests. Each test requires a `Makefile`, and running the tests constitues simply running `make` inside the directory. The new target is `check-stageN-rmake`. These tests will have the destination directory (as TMPDIR) and the local rust compiler (as RUSTC) passed along to them. There is also some helpful cross-platform utilities included in src/test/run-make/tools.mk to aid with compiling C programs and running them. The impetus for adding this new test suite is to allow various interesting forms of testing rust linkage. All of the tests initially added are various flavors of compiling Rust and C with one another as well as just making sure that rust linkage works in general. Closes #10434
2013-11-17 01:07:32 +00:00
test: Fix run-make on windows
2014-04-27 07:52:36 +00:00
UNAME = $(shell uname)
ifeq ($(UNAME),Darwin)
add support for running binaries with remote-test-client on run-make
2022-09-26 10:59:22 +00:00
RUN = $(TARGET_RPATH_ENV) $(EXECUTE)
FAIL = $(TARGET_RPATH_ENV) $(EXECUTE) && exit 1 || exit 0
Add a new run-make test directory This infrastructure is meant to support runnings tests that involve various interesting interdependencies about the types of crates being linked or possibly interacting with C libraries. The goal of these make tests is to not restrict them to a particular test runner, but allow each test to run its own tests. To this end, there is a new src/test/run-make directory which has sub-folders of tests. Each test requires a `Makefile`, and running the tests constitues simply running `make` inside the directory. The new target is `check-stageN-rmake`. These tests will have the destination directory (as TMPDIR) and the local rust compiler (as RUSTC) passed along to them. There is also some helpful cross-platform utilities included in src/test/run-make/tools.mk to aid with compiling C programs and running them. The impetus for adding this new test suite is to allow various interesting forms of testing rust linkage. All of the tests initially added are various flavors of compiling Rust and C with one another as well as just making sure that rust linkage works in general. Closes #10434
2013-11-17 01:07:32 +00:00
DYLIB_GLOB = lib$(1)*.dylib
DYLIB = $(TMPDIR)/lib$(1).dylib
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
STATICLIB = $(TMPDIR)/lib$(1).a
STATICLIB_GLOB = lib$(1)*.a
Add a new run-make test directory This infrastructure is meant to support runnings tests that involve various interesting interdependencies about the types of crates being linked or possibly interacting with C libraries. The goal of these make tests is to not restrict them to a particular test runner, but allow each test to run its own tests. To this end, there is a new src/test/run-make directory which has sub-folders of tests. Each test requires a `Makefile`, and running the tests constitues simply running `make` inside the directory. The new target is `check-stageN-rmake`. These tests will have the destination directory (as TMPDIR) and the local rust compiler (as RUSTC) passed along to them. There is also some helpful cross-platform utilities included in src/test/run-make/tools.mk to aid with compiling C programs and running them. The impetus for adding this new test suite is to allow various interesting forms of testing rust linkage. All of the tests initially added are various flavors of compiling Rust and C with one another as well as just making sure that rust linkage works in general. Closes #10434
2013-11-17 01:07:32 +00:00
else
test: Fix run-make on windows
2014-04-27 07:52:36 +00:00
ifdef IS_WINDOWS
add support for running binaries with remote-test-client on run-make
2022-09-26 10:59:22 +00:00
RUN = PATH="$(PATH):$(TARGET_RPATH_DIR)" $(EXECUTE)
FAIL = PATH="$(PATH):$(TARGET_RPATH_DIR)" $(EXECUTE) && exit 1 || exit 0
test: Fix run-make on windows
2014-04-27 07:52:36 +00:00
DYLIB_GLOB = $(1)*.dll
DYLIB = $(TMPDIR)/$(1).dll
Fix staticlib name for *-pc-windows-gnu targets
2020-04-08 19:36:18 +00:00
ifdef IS_MSVC
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
STATICLIB = $(TMPDIR)/$(1).lib
STATICLIB_GLOB = $(1)*.lib
Fix staticlib name for *-pc-windows-gnu targets
2020-04-08 19:36:18 +00:00
else
Add test for #50176
2020-07-03 19:00:14 +00:00
IMPLIB = $(TMPDIR)/lib$(1).dll.a
Fix staticlib name for *-pc-windows-gnu targets
2020-04-08 19:36:18 +00:00
STATICLIB = $(TMPDIR)/lib$(1).a
STATICLIB_GLOB = lib$(1)*.a
endif
test: Fix run-make on windows
2014-04-27 07:52:36 +00:00
BIN = $(1).exe
compiletest: Make the LLVM FileCheck tool available to run-make tests.
2019-04-25 13:30:23 +00:00
LLVM_FILECHECK := $(shell cygpath -u "$(LLVM_FILECHECK)")
test: Fix run-make on windows
2014-04-27 07:52:36 +00:00
else
add support for running binaries with remote-test-client on run-make
2022-09-26 10:59:22 +00:00
RUN = $(TARGET_RPATH_ENV) $(EXECUTE)
FAIL = $(TARGET_RPATH_ENV) $(EXECUTE) && exit 1 || exit 0
Add a new run-make test directory This infrastructure is meant to support runnings tests that involve various interesting interdependencies about the types of crates being linked or possibly interacting with C libraries. The goal of these make tests is to not restrict them to a particular test runner, but allow each test to run its own tests. To this end, there is a new src/test/run-make directory which has sub-folders of tests. Each test requires a `Makefile`, and running the tests constitues simply running `make` inside the directory. The new target is `check-stageN-rmake`. These tests will have the destination directory (as TMPDIR) and the local rust compiler (as RUSTC) passed along to them. There is also some helpful cross-platform utilities included in src/test/run-make/tools.mk to aid with compiling C programs and running them. The impetus for adding this new test suite is to allow various interesting forms of testing rust linkage. All of the tests initially added are various flavors of compiling Rust and C with one another as well as just making sure that rust linkage works in general. Closes #10434
2013-11-17 01:07:32 +00:00
DYLIB_GLOB = lib$(1)*.so
DYLIB = $(TMPDIR)/lib$(1).so
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
STATICLIB = $(TMPDIR)/lib$(1).a
STATICLIB_GLOB = lib$(1)*.a
endif
Add a new run-make test directory This infrastructure is meant to support runnings tests that involve various interesting interdependencies about the types of crates being linked or possibly interacting with C libraries. The goal of these make tests is to not restrict them to a particular test runner, but allow each test to run its own tests. To this end, there is a new src/test/run-make directory which has sub-folders of tests. Each test requires a `Makefile`, and running the tests constitues simply running `make` inside the directory. The new target is `check-stageN-rmake`. These tests will have the destination directory (as TMPDIR) and the local rust compiler (as RUSTC) passed along to them. There is also some helpful cross-platform utilities included in src/test/run-make/tools.mk to aid with compiling C programs and running them. The impetus for adding this new test suite is to allow various interesting forms of testing rust linkage. All of the tests initially added are various flavors of compiling Rust and C with one another as well as just making sure that rust linkage works in general. Closes #10434
2013-11-17 01:07:32 +00:00
endif
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
ifdef IS_MSVC
COMPILE_OBJ = $(CC) -c -Fo:`cygpath -w $(1)` $(2)
Enable C++ exceptions on MSVC when building C++ tests
2019-10-26 01:47:06 +00:00
COMPILE_OBJ_CXX = $(CXX) -EHs -c -Fo:`cygpath -w $(1)` $(2)
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
NATIVE_STATICLIB_FILE = $(1).lib
NATIVE_STATICLIB = $(TMPDIR)/$(call NATIVE_STATICLIB_FILE,$(1))
OUT_EXE=-Fe:`cygpath -w $(TMPDIR)/$(call BIN,$(1))` \
-Fo:`cygpath -w $(TMPDIR)/$(1).obj`
else
Enable raw-dylib for binaries
2022-07-01 20:01:41 +00:00
COMPILE_OBJ = $(CC) -v -c -o $(1) $(2)
Add a test for issue 36710. This still expectedly fails for musl targets with +crt-static.
2018-05-02 08:26:00 +00:00
COMPILE_OBJ_CXX = $(CXX) -c -o $(1) $(2)
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
NATIVE_STATICLIB_FILE = lib$(1).a
NATIVE_STATICLIB = $(call STATICLIB,$(1))
OUT_EXE=-o $(TMPDIR)/$(1)
test: Fix run-make on windows
2014-04-27 07:52:36 +00:00
endif
Add a new run-make test directory This infrastructure is meant to support runnings tests that involve various interesting interdependencies about the types of crates being linked or possibly interacting with C libraries. The goal of these make tests is to not restrict them to a particular test runner, but allow each test to run its own tests. To this end, there is a new src/test/run-make directory which has sub-folders of tests. Each test requires a `Makefile`, and running the tests constitues simply running `make` inside the directory. The new target is `check-stageN-rmake`. These tests will have the destination directory (as TMPDIR) and the local rust compiler (as RUSTC) passed along to them. There is also some helpful cross-platform utilities included in src/test/run-make/tools.mk to aid with compiling C programs and running them. The impetus for adding this new test suite is to allow various interesting forms of testing rust linkage. All of the tests initially added are various flavors of compiling Rust and C with one another as well as just making sure that rust linkage works in general. Closes #10434
2013-11-17 01:07:32 +00:00
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
rustc: Preserve reachable extern fns with LTO All rust functions are internal implementation details with respect to the ABI exposed by crates, but extern fns are public components of the ABI and shouldn't be stripped. This commit serializes reachable extern fns to metadata, so when LTO is performed all of their symbols are not stripped. Closes #14500
2014-06-07 00:48:46 +00:00
# Extra flags needed to compile a working executable with the standard library
ifdef IS_WINDOWS
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
ifdef IS_MSVC
Add synchronization library to run-make flags
2024-02-26 01:28:30 +00:00
EXTRACFLAGS := ws2_32.lib userenv.lib advapi32.lib bcrypt.lib ntdll.lib synchronization.lib
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
else
Add synchronization library to run-make flags
2024-02-26 01:28:30 +00:00
EXTRACFLAGS := -lws2_32 -luserenv -lbcrypt -lntdll -lsynchronization
Add -lstdc++ for run-make-fulldeps tests on MinGW
2019-10-22 13:12:33 +00:00
EXTRACXXFLAGS := -lstdc++
Hack to make C++ exceptions test work on i686-pc-windows-gnu
2019-10-26 16:41:55 +00:00
# So this is a bit hacky: we can't use the DLL version of libstdc++ because
# it pulls in the DLL version of libgcc, which means that we end up with 2
# instances of the DW2 unwinding implementation. This is a problem on
# i686-pc-windows-gnu because each module (DLL/EXE) needs to register its
# unwind information with the unwinding implementation, and libstdc++'s
# __cxa_throw won't see the unwinding info we registered with our statically
# linked libgcc.
#
# Now, simply statically linking libstdc++ would fix this problem, except
# that it is compiled with the expectation that pthreads is dynamically
# linked as a DLL and will fail to link with a statically linked libpthread.
#
Add -Zunstable-options instead of feature
2021-10-28 21:38:21 +00:00
# So we end up with the following hack: we link use static:-bundle to only
Hack to make C++ exceptions test work on i686-pc-windows-gnu
2019-10-26 16:41:55 +00:00
# link the parts of libstdc++ that we actually use, which doesn't include
# the dependency on the pthreads DLL.
Stabilize the `bundle` native library modifier
2022-04-08 15:20:57 +00:00
EXTRARSCXXFLAGS := -l static:-bundle=stdc++
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
endif
rustc: Preserve reachable extern fns with LTO All rust functions are internal implementation details with respect to the ABI exposed by crates, but extern fns are public components of the ABI and shouldn't be stripped. This commit serializes reachable extern fns to metadata, so when LTO is performed all of their symbols are not stripped. Closes #14500
2014-06-07 00:48:46 +00:00
else
fixing some tests and temporarily disabling others to get Bitrig build working 100%
2015-03-23 19:48:42 +00:00
ifeq ($(UNAME),Darwin)
Reload nameserver information on lookup failure As discussed in #41570, UNIX systems often cache the contents of /etc/resolv.conf, which can cause lookup failures to persist even after a network connection becomes available. This patch modifies lookup_host to force a reload of the nameserver entries following a lookup failure. This is in line with what many C programs already do (see #41570 for details). On systems with nscd, this should not be necessary, but not all systems run nscd. Introduces an std linkage dependency on libresolv on macOS/iOS (which also makes it necessary to update run-make/tools.mk). Fixes #41570. Depends on rust-lang/libc#585.
2017-04-27 16:58:52 +00:00
EXTRACFLAGS := -lresolv
Fix macOS tests
2019-11-03 11:23:44 +00:00
EXTRACXXFLAGS := -lc++
EXTRARSCXXFLAGS := -lc++
rustc: Preserve reachable extern fns with LTO All rust functions are internal implementation details with respect to the ABI exposed by crates, but extern fns are public components of the ABI and shouldn't be stripped. This commit serializes reachable extern fns to metadata, so when LTO is performed all of their symbols are not stripped. Closes #14500
2014-06-07 00:48:46 +00:00
else
fixing some tests and temporarily disabling others to get Bitrig build working 100%
2015-03-23 19:48:42 +00:00
ifeq ($(UNAME),FreeBSD)
rustc: Preserve reachable extern fns with LTO All rust functions are internal implementation details with respect to the ABI exposed by crates, but extern fns are public components of the ABI and shouldn't be stripped. This commit serializes reachable extern fns to metadata, so when LTO is performed all of their symbols are not stripped. Closes #14500
2014-06-07 00:48:46 +00:00
EXTRACFLAGS := -lm -lpthread -lgcc_s
Test fixes and rebase conflicts
2015-02-02 19:04:58 +00:00
else
Add Illumos support
2016-01-21 16:30:22 +00:00
ifeq ($(UNAME),SunOS)
Some tests use `res_init()` and need `-lresolv` on Solaris This is a follow-up to ea23e50f, which fixed it for the build.
2017-08-03 22:38:34 +00:00
EXTRACFLAGS := -lm -lpthread -lposix4 -lsocket -lresolv
Add Illumos support
2016-01-21 16:30:22 +00:00
else
fixing some tests and temporarily disabling others to get Bitrig build working 100%
2015-03-23 19:48:42 +00:00
ifeq ($(UNAME),OpenBSD)
make OpenBSD to use libc++ instead of (e)stdc++
2017-11-26 09:08:25 +00:00
EXTRACFLAGS := -lm -lpthread -lc++abi
openbsd: use specific linker for building By default, rustc use `cc` as linker. Under OpenBSD, `cc` is gcc version 4.2.1. So use the compiler found at configure-time for linking: it will be gcc 4.9. It permits to resolv problem of finding -lestdc++ or -lgcc. For base gcc (4.2), there are in not standard path, whereas for ports gcc (4.9) there are in standard path.
2015-12-19 17:00:23 +00:00
RUSTC := $(RUSTC) -C linker="$(word 1,$(CC:ccache=))"
rustc: Preserve reachable extern fns with LTO All rust functions are internal implementation details with respect to the ABI exposed by crates, but extern fns are public components of the ABI and shouldn't be stripped. This commit serializes reachable extern fns to metadata, so when LTO is performed all of their symbols are not stripped. Closes #14500
2014-06-07 00:48:46 +00:00
else
EXTRACFLAGS := -lm -lrt -ldl -lpthread
fixing some tests and temporarily disabling others to get Bitrig build working 100%
2015-03-23 19:48:42 +00:00
EXTRACXXFLAGS := -lstdc++
Hack to make C++ exceptions test work on i686-pc-windows-gnu
2019-10-26 16:41:55 +00:00
EXTRARSCXXFLAGS := -lstdc++
fixing some tests and temporarily disabling others to get Bitrig build working 100%
2015-03-23 19:48:42 +00:00
endif
rustc: Preserve reachable extern fns with LTO All rust functions are internal implementation details with respect to the ABI exposed by crates, but extern fns are public components of the ABI and shouldn't be stripped. This commit serializes reachable extern fns to metadata, so when LTO is performed all of their symbols are not stripped. Closes #14500
2014-06-07 00:48:46 +00:00
endif
endif
endif
openbsd support
2015-01-29 07:19:28 +00:00
endif
rustc: Preserve reachable extern fns with LTO All rust functions are internal implementation details with respect to the ABI exposed by crates, but extern fns are public components of the ABI and shouldn't be stripped. This commit serializes reachable extern fns to metadata, so when LTO is performed all of their symbols are not stripped. Closes #14500
2014-06-07 00:48:46 +00:00
Refactoring: Introduce distinct host and target rpath var setters. Two line summary: Distinguish HOST_RPATH and TARGET_RPATH; added RPATH_LINK_SEARCH; skip tests broken in stage1; general cleanup. `HOST_RPATH_VAR$(1)_T_$(2)_H_$(3)` and `TARGET_RPATH_VAR$(1)_T_$(2)_H_$(3)` both match the format of the old `RPATH_VAR$(1)_T_$(2)_H_$(3)` (which is still being set the same way that it was before, to one of either HOST/TARGET depending on what stage we are building). Namely, the format is <XXX>_RPATH_VAR = "<LD_LIB_PATH_ENVVAR>=<COLON_SEP_PATH_ENTRIES>" What this commit does: * Pass both of the (newly introduced) HOST and TARGET rpath setup vars to `maketest.py` * Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself Instead, it passes along the HOST and TARGET rpath setup vars in environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV` * Also, pass the current stage number to maketest.py; it in turn passes it (via an env var) to run-make tests. This allows the run-make tests to selectively change behavior (e.g. turn themselves off) to deal with incompatibilities with e.g. stage1. * Cleanup: Distinguish in tools.mk between the command to run (`RUN`) and the file to generate to drive that command (`RUN_BINFILE`). The main thing this enables is that `RUN` can now setup the `TARGET_RPATH_ENV` without having to dirty up the runner code in each of the `run-make` Makefiles. * Cleanup: Factored out commands to delete dylib/rlib into REMOVE_DYLIBS/REMOVE_RLIBS. There were places where we were only calling `rm $(call DYLIB,foo)` even though we really needed to get rid of the whole glob (at least based on alex's findings on #13753 that removing the symlink does not suffice). Therefore rather than peppering the code with the awkward `rm $(TMPDIR)/$(call DYLIB_GLOB,foo)`, I instead introduced a common `REMOVE_DYLIBS` user function that expands into that when called. After I adding an analogous `REMOVE_RLIBS`, I changed all of the existing calls that rm dylibs or rlibs to use these routines instead. Note that the latter is not a true refactoring since I may have changed cases where it was our intent to only remove the sym-link. (But if that is the case, then we need to more deeply investigate alex's findings on #13753 where the system was still dynamically loading up the non-symlinked libraries that it finds on the load path.) * Added RPATH_LINK_SEARCH command and use it on Linux. On some platforms, namely Linux, when you have libboot.so that has its internal rpath set (to e.g. $(ORIGIN)/path/to/HOSTDIR), the linker still complains when you do the link step and it does not know where to find libraries that libboot.so depends upon that live in HOSTDIR (think e.g. librustuv.so). As far as I can tell, the GNU linker will consult the LD_LIBRARY_PATH as part of the linking process to find such libraries. But if you want to be more careful and not override LD_LIBRARY_PATH for the `gcc` invocation, then you need some other way to tell the linker where it can find the libraries that libboot.so needs. The solution to this on Linux is the `-Wl,-rpath-link` command line option. However, this command line option does not exist on Mac OS X, (which appears to be figuring out how to resolve the libboot.dylib dependency by some other means, perhaps by consulting the rpath setting within libboot.dylib). So, in order to abstract over this distinction, I added the RPATH_LINK_SEARCH macro to the run-make infrastructure and added calls to it where necessary to get Linux working. On architectures other than Linux, the macro expands to nothing. * Disable miscellaneous tests atop stage1. * An especially interesting instance of the previous bullet point: Excuse regex from doing rustdoc tests atop stage1. This was a (nearly-) final step to get `make check-stage1` working again. The use of a special-case check for regex here is ugly but is analogous other similar checks for regex such as the one that landed in PR #13844. The way this is written, the user will get a reminder that doc-crate-regex is being skipped whenever their rules attempt to do the crate documentation tests. This is deliberate: I want people running `make check-stage1` to be reminded about which cases are being skipped. (But if such echo noise is considered offensive, it can obviously be removed.) * Got windows working with the above changes. This portion of the commit is a cleanup revision of the (previously mentioned on try builds) re-architecting of how the LD_LIBRARY_PATH setup and extension is handled in order to accommodate Windows' (1.) use of `$PATH` for that purpose and (2.) use of spaces in `$PATH` entries (problematic for make and for interoperation with tools at the shell). * In addition, since the code has been rearchitected to pass the HOST_RPATH_DIR/TARGET_RPATH_DIR rather than a whole sh environment-variable setting command, there is no need to for the convert_path_spec calls in maketest.py, which in fact were put in place to placate Windows but were now causing the Windows builds to fail. Instead we just convert the paths to absolute paths just like all of the other path arguments. Also, note for makefile hackers: apparently you cannot quote operands to `ifeq` in Makefile (or at least, you need to be careful about adding them, e.g. to only one side).
2014-04-25 16:22:23 +00:00
REMOVE_DYLIBS = rm $(TMPDIR)/$(call DYLIB_GLOB,$(1))
REMOVE_RLIBS = rm $(TMPDIR)/$(call RLIB_GLOB,$(1))
Add a new run-make test directory This infrastructure is meant to support runnings tests that involve various interesting interdependencies about the types of crates being linked or possibly interacting with C libraries. The goal of these make tests is to not restrict them to a particular test runner, but allow each test to run its own tests. To this end, there is a new src/test/run-make directory which has sub-folders of tests. Each test requires a `Makefile`, and running the tests constitues simply running `make` inside the directory. The new target is `check-stageN-rmake`. These tests will have the destination directory (as TMPDIR) and the local rust compiler (as RUSTC) passed along to them. There is also some helpful cross-platform utilities included in src/test/run-make/tools.mk to aid with compiling C programs and running them. The impetus for adding this new test suite is to allow various interesting forms of testing rust linkage. All of the tests initially added are various flavors of compiling Rust and C with one another as well as just making sure that rust linkage works in general. Closes #10434
2013-11-17 01:07:32 +00:00
%.a: %.o
rustbuild: Support specifying archiver and linker explicitly
2017-10-10 20:06:22 +00:00
$(AR) crus $@ $<
Get tests working on MSVC 32-bit
2015-12-14 23:40:43 +00:00
ifdef IS_MSVC
%.lib: lib%.o
$(MSVC_LIB) -out:`cygpath -w $@` $<
else
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
%.lib: lib%.o
rustbuild: Support specifying archiver and linker explicitly
2017-10-10 20:06:22 +00:00
$(AR) crus $@ $<
Get tests working on MSVC 32-bit
2015-12-14 23:40:43 +00:00
endif
Add a new run-make test directory This infrastructure is meant to support runnings tests that involve various interesting interdependencies about the types of crates being linked or possibly interacting with C libraries. The goal of these make tests is to not restrict them to a particular test runner, but allow each test to run its own tests. To this end, there is a new src/test/run-make directory which has sub-folders of tests. Each test requires a `Makefile`, and running the tests constitues simply running `make` inside the directory. The new target is `check-stageN-rmake`. These tests will have the destination directory (as TMPDIR) and the local rust compiler (as RUSTC) passed along to them. There is also some helpful cross-platform utilities included in src/test/run-make/tools.mk to aid with compiling C programs and running them. The impetus for adding this new test suite is to allow various interesting forms of testing rust linkage. All of the tests initially added are various flavors of compiling Rust and C with one another as well as just making sure that rust linkage works in general. Closes #10434
2013-11-17 01:07:32 +00:00
%.dylib: %.o
Test fixes and merge conflicts
2013-11-29 02:03:38 +00:00
$(CC) -dynamiclib -Wl,-dylib -o $@ $<
Add a new run-make test directory This infrastructure is meant to support runnings tests that involve various interesting interdependencies about the types of crates being linked or possibly interacting with C libraries. The goal of these make tests is to not restrict them to a particular test runner, but allow each test to run its own tests. To this end, there is a new src/test/run-make directory which has sub-folders of tests. Each test requires a `Makefile`, and running the tests constitues simply running `make` inside the directory. The new target is `check-stageN-rmake`. These tests will have the destination directory (as TMPDIR) and the local rust compiler (as RUSTC) passed along to them. There is also some helpful cross-platform utilities included in src/test/run-make/tools.mk to aid with compiling C programs and running them. The impetus for adding this new test suite is to allow various interesting forms of testing rust linkage. All of the tests initially added are various flavors of compiling Rust and C with one another as well as just making sure that rust linkage works in general. Closes #10434
2013-11-17 01:07:32 +00:00
%.so: %.o
Test fixes and merge conflicts
2013-11-29 02:03:38 +00:00
$(CC) -o $@ $< -shared
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
ifdef IS_MSVC
%.dll: lib%.o
$(CC) $< -link -dll -out:`cygpath -w $@`
else
test: Fix run-make on windows
2014-04-27 07:52:36 +00:00
%.dll: lib%.o
Create implib for dlls when testing MinGW targets
2020-06-13 12:18:02 +00:00
$(CC) -o $@ $< -shared -Wl,--out-implib=$@.a
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
endif
test: Fix run-make on windows
2014-04-27 07:52:36 +00:00
Add a new run-make test directory This infrastructure is meant to support runnings tests that involve various interesting interdependencies about the types of crates being linked or possibly interacting with C libraries. The goal of these make tests is to not restrict them to a particular test runner, but allow each test to run its own tests. To this end, there is a new src/test/run-make directory which has sub-folders of tests. Each test requires a `Makefile`, and running the tests constitues simply running `make` inside the directory. The new target is `check-stageN-rmake`. These tests will have the destination directory (as TMPDIR) and the local rust compiler (as RUSTC) passed along to them. There is also some helpful cross-platform utilities included in src/test/run-make/tools.mk to aid with compiling C programs and running them. The impetus for adding this new test suite is to allow various interesting forms of testing rust linkage. All of the tests initially added are various flavors of compiling Rust and C with one another as well as just making sure that rust linkage works in general. Closes #10434
2013-11-17 01:07:32 +00:00
$(TMPDIR)/lib%.o: %.c
rmake: Get all tests passing on MSVC
2015-08-26 23:57:56 +00:00
$(call COMPILE_OBJ,$@,$<)
Reference in New Issue Copy Permalink