-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add dependence arc from running rustc to its libraries. #7820
Closed
pnkfelix
wants to merge
1
commit into
rust-lang:master
from
pnkfelix:fill-in-some-missing-rustc-lib-dependences
Closed
Add dependence arc from running rustc to its libraries. #7820
pnkfelix
wants to merge
1
commit into
rust-lang:master
from
pnkfelix:fill-in-some-missing-rustc-lib-dependences
+20
−16
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit fixes some oversights in the Makefile where rustc could be invoked without some of its dependencies yet in place. (I encountered the problem in practice; its not just theoretical.) As written in Makefile.in, $(STAGE$(1)_T_$(2)_H_$(3)) is the way one writes an invocation of rustc where $(1) is the stage number $(2) is the target triple $(3) is the host triple. (Other uses of the macro may plug in actual values or different parameters in for those three formal parameters.) When you have invocations of $(STAGE...), you need to make sure that its dependences are satisfied; otherwise, if someone is using `make -jN` for certain (large-ish) `N`, one can encounter situations where GNU make attempts to invoke `rustc` before it has actually copied some of its libraries into place, such as libmorestack.a, which causes a link failure when the rustc invocation attempts to link in those libraries. In this case, the main prerequisite to add is TSREQ$(1)_T_$(2)_H_$(3), which is described in Makefile.in as "Prerequisites for using the stageN compiler to build target artifacts" ---- In addition to adding the extra dependences on TSREQ..., I also replaced occurrences of the pattern: TSREQ$(1)_T_$(2)_H_$(3) $$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_STDLIB_$(2)) $$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_EXTRALIB_$(2)) with: SREQ$(1)_T_$(2)_H_$(3) which is equivalent to the above, as defined in Makefile.in ---- Finally, for the cases where TSREQ was missing in tests.mk, I went ahead and put in a dependence on SREQ rather than just TSREQ, since it was not clear to me how one could expect to compile those cases without stdlib and extralib. (It could well be that I should have gone ahead and done the same in other cases where I saw TSREQ was missing, and put SREQ in those cases as well. But this seemed like a good measure for now, without needing to tax my understanding of the overall makefile infrastructure much further.)
I've actually run into this too, on my bench server (which uses |
@cmr can I interpret your comment as an r+ then? :) |
formally filed as #8057 |
bors
added a commit
that referenced
this pull request
Jul 26, 2013
…pendences, r=graydon r? anyone Fix #8057 This commit fixes some oversights in the Makefile where rustc could be invoked without some of its dependencies yet in place. (I encountered the problem in practice; its not just theoretical.) As written in Makefile.in, $(STAGE$(1)_T_$(2)_H_$(3)) is the way one writes an invocation of rustc where $(1) is the stage number $(2) is the target triple $(3) is the host triple. (Other uses of the macro may plug in actual values or different parameters in for those three formal parameters.) When you have invocations of $(STAGE...), you need to make sure that its dependences are satisfied; otherwise, if someone is using `make -jN` for certain (large-ish) `N`, one can encounter situations where GNU make attempts to invoke `rustc` before it has actually copied some of its libraries into place, such as libmorestack.a, which causes a link failure when the rustc invocation attempts to link in those libraries. In this case, the main prerequisite to add is TSREQ$(1)_T_$(2)_H_$(3), which is described in Makefile.in as "Prerequisites for using the stageN compiler to build target artifacts" ---- In addition to adding the extra dependences on TSREQ..., I also replaced occurrences of the pattern: TSREQ$(1)_T_$(2)_H_$(3) $$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_STDLIB_$(2)) $$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_EXTRALIB_$(2)) with: SREQ$(1)_T_$(2)_H_$(3) which is equivalent to the above, as defined in Makefile.in ---- Finally, for the cases where TSREQ was missing in tests.mk, I went ahead and put in a dependence on SREQ rather than just TSREQ, since it was not clear to me how one could expect to compile those cases without stdlib and extralib. (It could well be that I should have gone ahead and done the same in other cases where I saw TSREQ was missing, and put SREQ in those cases as well. But this seemed like a good measure for now, without needing to tax my understanding of the overall makefile infrastructure much further.)
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Nov 23, 2021
Fix `manual_map` with unsafe functions fixes: rust-lang#7820 changelog: Fix `manual_map` suggestion when used with unsafe functions and unsafe blocks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
r? anyone
Fix #8057
This commit fixes some oversights in the Makefile where rustc could be
invoked without some of its dependencies yet in place. (I encountered
the problem in practice; its not just theoretical.)
As written in Makefile.in,$(STAGE$ (1)T$(2)H$(3)) is the way one$(1) is the stage number $ (2) is
writes an invocation of rustc where
the target triple $(3) is the host triple. (Other uses of the macro
may plug in actual values or different parameters in for those three
formal parameters.)
When you have invocations of $(STAGE...), you need to make sure that
its dependences are satisfied; otherwise, if someone is using
make -jN
for certain (large-ish)N
, one can encounter situations whereGNU make attempts to invoke
rustc
before it has actually copied someof its libraries into place, such as libmorestack.a, which causes a
link failure when the rustc invocation attempts to link in those
libraries.
In this case, the main prerequisite to add is TSREQ$(1)T$(2)H$(3),
which is described in Makefile.in as "Prerequisites for using the
stageN compiler to build target artifacts"
In addition to adding the extra dependences on TSREQ..., I also
replaced occurrences of the pattern:
with:
which is equivalent to the above, as defined in Makefile.in
Finally, for the cases where TSREQ was missing in tests.mk, I went
ahead and put in a dependence on SREQ rather than just TSREQ, since it
was not clear to me how one could expect to compile those cases
without stdlib and extralib.
(It could well be that I should have gone ahead and done the same in
other cases where I saw TSREQ was missing, and put SREQ in those
cases as well. But this seemed like a good measure for now, without
needing to tax my understanding of the overall makefile
infrastructure much further.)