mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
e30d27be00
rust/tests/run-make/extern-flag-pathless/Makefile

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

35 lines
1.0 KiB
Makefile
Raw Normal View History

ignore failing cross-compiled run-make tests `run-make-fulldeps` is never cross-compiled, so a lot of these tests never accounted for --target. Ignore them when cross-compiling for now.
2023-03-30 08:46:31 -05:00
# ignore-cross-compile
Diagnose missing includes in run-make tests
2022-08-22 19:00:00 -05:00
include ../tools.mk
Add more --extern tests.
2019-09-29 20:17:27 -05:00
# Test mixing pathless --extern with paths.
Verify that all crate sources are in sync This ensures that rustc will not attempt to link against a cdylib as if it is a rust dylib when an rlib for the same crate is available. Previously rustc didn't actually check if any further formats of a crate which has been loaded are of the same version and if they are actually valid. This caused a cdylib to be interpreted as rust dylib as soon as the corresponding rlib was loaded. As cdylibs don't export any rust symbols, linking would fail if rustc decides to link against the cdylib rather than the rlib. Two crates depended on the previous behavior by separately compiling a test crate as both rlib and dylib. These have been changed to capture their original spirit to the best of my ability while still working when rustc verifies that all crates are in sync. It is unlikely that build systems depend on the current behavior and in any case we are taking a lot of measures to ensure that any change to either the source or the compilation options (including crate type) results in rustc rejecting it as incompatible. We merely didn't do this check here for now obsolete perf reasons.
2023-07-14 09:50:21 -05:00
# Test for static linking by checking that the binary runs if the dylib
# is removed and test for dynamic linking by checking that the binary
# fails to run if the dylib is removed.
Add more --extern tests.
2019-09-29 20:17:27 -05:00
all:
Verify that all crate sources are in sync This ensures that rustc will not attempt to link against a cdylib as if it is a rust dylib when an rlib for the same crate is available. Previously rustc didn't actually check if any further formats of a crate which has been loaded are of the same version and if they are actually valid. This caused a cdylib to be interpreted as rust dylib as soon as the corresponding rlib was loaded. As cdylibs don't export any rust symbols, linking would fail if rustc decides to link against the cdylib rather than the rlib. Two crates depended on the previous behavior by separately compiling a test crate as both rlib and dylib. These have been changed to capture their original spirit to the best of my ability while still working when rustc verifies that all crates are in sync. It is unlikely that build systems depend on the current behavior and in any case we are taking a lot of measures to ensure that any change to either the source or the compilation options (including crate type) results in rustc rejecting it as incompatible. We merely didn't do this check here for now obsolete perf reasons.
2023-07-14 09:50:21 -05:00
$(RUSTC) bar.rs --crate-type=rlib --crate-type=dylib -Cprefer-dynamic
Add more --extern tests.
2019-09-29 20:17:27 -05:00
# rlib preferred over dylib
$(RUSTC) foo.rs --extern bar
Verify that all crate sources are in sync This ensures that rustc will not attempt to link against a cdylib as if it is a rust dylib when an rlib for the same crate is available. Previously rustc didn't actually check if any further formats of a crate which has been loaded are of the same version and if they are actually valid. This caused a cdylib to be interpreted as rust dylib as soon as the corresponding rlib was loaded. As cdylibs don't export any rust symbols, linking would fail if rustc decides to link against the cdylib rather than the rlib. Two crates depended on the previous behavior by separately compiling a test crate as both rlib and dylib. These have been changed to capture their original spirit to the best of my ability while still working when rustc verifies that all crates are in sync. It is unlikely that build systems depend on the current behavior and in any case we are taking a lot of measures to ensure that any change to either the source or the compilation options (including crate type) results in rustc rejecting it as incompatible. We merely didn't do this check here for now obsolete perf reasons.
2023-07-14 09:50:21 -05:00
mv $(call DYLIB,bar) $(TMPDIR)/bar.tmp
$(call RUN,foo)
mv $(TMPDIR)/bar.tmp $(call DYLIB,bar)
Add more --extern tests.
2019-09-29 20:17:27 -05:00
$(RUSTC) foo.rs --extern bar=$(TMPDIR)/libbar.rlib --extern bar
Verify that all crate sources are in sync This ensures that rustc will not attempt to link against a cdylib as if it is a rust dylib when an rlib for the same crate is available. Previously rustc didn't actually check if any further formats of a crate which has been loaded are of the same version and if they are actually valid. This caused a cdylib to be interpreted as rust dylib as soon as the corresponding rlib was loaded. As cdylibs don't export any rust symbols, linking would fail if rustc decides to link against the cdylib rather than the rlib. Two crates depended on the previous behavior by separately compiling a test crate as both rlib and dylib. These have been changed to capture their original spirit to the best of my ability while still working when rustc verifies that all crates are in sync. It is unlikely that build systems depend on the current behavior and in any case we are taking a lot of measures to ensure that any change to either the source or the compilation options (including crate type) results in rustc rejecting it as incompatible. We merely didn't do this check here for now obsolete perf reasons.
2023-07-14 09:50:21 -05:00
mv $(call DYLIB,bar) $(TMPDIR)/bar.tmp
$(call RUN,foo)
mv $(TMPDIR)/bar.tmp $(call DYLIB,bar)
Add more --extern tests.
2019-09-29 20:17:27 -05:00
# explicit --extern overrides pathless
$(RUSTC) foo.rs --extern bar=$(call DYLIB,bar) --extern bar
Verify that all crate sources are in sync This ensures that rustc will not attempt to link against a cdylib as if it is a rust dylib when an rlib for the same crate is available. Previously rustc didn't actually check if any further formats of a crate which has been loaded are of the same version and if they are actually valid. This caused a cdylib to be interpreted as rust dylib as soon as the corresponding rlib was loaded. As cdylibs don't export any rust symbols, linking would fail if rustc decides to link against the cdylib rather than the rlib. Two crates depended on the previous behavior by separately compiling a test crate as both rlib and dylib. These have been changed to capture their original spirit to the best of my ability while still working when rustc verifies that all crates are in sync. It is unlikely that build systems depend on the current behavior and in any case we are taking a lot of measures to ensure that any change to either the source or the compilation options (including crate type) results in rustc rejecting it as incompatible. We merely didn't do this check here for now obsolete perf reasons.
2023-07-14 09:50:21 -05:00
mv $(call DYLIB,bar) $(TMPDIR)/bar.tmp
$(call FAIL,foo)
mv $(TMPDIR)/bar.tmp $(call DYLIB,bar)
Add more --extern tests.
2019-09-29 20:17:27 -05:00
# prefer-dynamic does what it says
$(RUSTC) foo.rs --extern bar -C prefer-dynamic
Verify that all crate sources are in sync This ensures that rustc will not attempt to link against a cdylib as if it is a rust dylib when an rlib for the same crate is available. Previously rustc didn't actually check if any further formats of a crate which has been loaded are of the same version and if they are actually valid. This caused a cdylib to be interpreted as rust dylib as soon as the corresponding rlib was loaded. As cdylibs don't export any rust symbols, linking would fail if rustc decides to link against the cdylib rather than the rlib. Two crates depended on the previous behavior by separately compiling a test crate as both rlib and dylib. These have been changed to capture their original spirit to the best of my ability while still working when rustc verifies that all crates are in sync. It is unlikely that build systems depend on the current behavior and in any case we are taking a lot of measures to ensure that any change to either the source or the compilation options (including crate type) results in rustc rejecting it as incompatible. We merely didn't do this check here for now obsolete perf reasons.
2023-07-14 09:50:21 -05:00
mv $(call DYLIB,bar) $(TMPDIR)/bar.tmp
$(call FAIL,foo)
mv $(TMPDIR)/bar.tmp $(call DYLIB,bar)
Reference in New Issue Copy Permalink