mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
964234654d
rust/tests/run-make-fulldeps/mixing-formats/Makefile

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

75 lines
2.7 KiB
Makefile
Raw Normal View History

Diagnose missing includes in run-make tests
2022-08-22 19:00:00 -05:00
include ../tools.mk
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
# Testing various mixings of rlibs and dylibs. Makes sure that it's possible to
# link an rlib to a dylib. The dependency tree among the file looks like:
#
# foo
# / \
# bar1 bar2
# / \ /
# baz baz2
#
# This is generally testing the permutations of the foo/bar1/bar2 layer against
# the baz/baz2 layer
all:
# Building just baz
$(RUSTC) --crate-type=rlib foo.rs
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib bar1.rs -C prefer-dynamic
$(RUSTC) --crate-type=dylib,rlib baz.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=bin baz.rs
rm $(TMPDIR)/*
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib foo.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=rlib bar1.rs
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib,rlib baz.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=bin baz.rs
rm $(TMPDIR)/*
# Building baz2
$(RUSTC) --crate-type=rlib foo.rs
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib bar1.rs -C prefer-dynamic
$(RUSTC) --crate-type=dylib bar2.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=dylib baz2.rs && exit 1 || exit 0
$(RUSTC) --crate-type=bin baz2.rs && exit 1 || exit 0
rm $(TMPDIR)/*
$(RUSTC) --crate-type=rlib foo.rs
$(RUSTC) --crate-type=rlib bar1.rs
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib bar2.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=dylib,rlib baz2.rs
$(RUSTC) --crate-type=bin baz2.rs
rm $(TMPDIR)/*
$(RUSTC) --crate-type=rlib foo.rs
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib bar1.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=rlib bar2.rs
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib,rlib baz2.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=bin baz2.rs
rm $(TMPDIR)/*
$(RUSTC) --crate-type=rlib foo.rs
$(RUSTC) --crate-type=rlib bar1.rs
$(RUSTC) --crate-type=rlib bar2.rs
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib,rlib baz2.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=bin baz2.rs
rm $(TMPDIR)/*
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib foo.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=rlib bar1.rs
$(RUSTC) --crate-type=rlib bar2.rs
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib,rlib baz2.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=bin baz2.rs
rm $(TMPDIR)/*
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib foo.rs -C prefer-dynamic
$(RUSTC) --crate-type=dylib bar1.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=rlib bar2.rs
$(RUSTC) --crate-type=dylib,rlib baz2.rs
$(RUSTC) --crate-type=bin baz2.rs
rm $(TMPDIR)/*
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib foo.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=rlib bar1.rs
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib bar2.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=dylib,rlib baz2.rs
$(RUSTC) --crate-type=bin baz2.rs
rm $(TMPDIR)/*
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
2014-11-03 01:02:53 -06:00
$(RUSTC) --crate-type=dylib foo.rs -C prefer-dynamic
$(RUSTC) --crate-type=dylib bar1.rs -C prefer-dynamic
$(RUSTC) --crate-type=dylib bar2.rs -C prefer-dynamic
rustc: Add some suppot for mixing rlibs and dylibs Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
2014-05-02 02:59:27 -05:00
$(RUSTC) --crate-type=dylib,rlib baz2.rs
$(RUSTC) --crate-type=bin baz2.rs
Reference in New Issue Copy Permalink