Perform "linking to object file" as separate phase.#9444
Merged
Conversation
6961722 to
c61ff2e
Compare
kripken
reviewed
Sep 17, 2019
| out_dep.write(deps) | ||
| # Specifying -o with multiple input source files is not allowed. | ||
| # We error out much earlier in this case. | ||
| assert len(input_files) == 1 |
Member
There was a problem hiding this comment.
If the user does provide multiple inputs with -o, is the error message shown the assertion here failing? (if so I worry it may not be clear enough)
Is this a breaking change?
Collaborator
Author
There was a problem hiding this comment.
No, there is an earlier error for that case. This assert is as a fall back / internal consistency check.
2c9eb85 to
4f92c6b
Compare
This change moves the "linking to object file" logic to separate phase which runs after compilation, but before the real "linking" phase. We can also delay library processing until after this phase as that is only needed for actual linking. This change is a step towards more conventional library linking See #8912.
29e5749 to
1efce29
Compare
sbc100
added a commit
that referenced
this pull request
Sep 21, 2019
On mac, libtool/autoconf will often add `-Wl,-bind_at_load` at link time which was causing and error when passed down the lld. Add a blacklist of linker flags we don't support in lld to avoid this issue. This seems easier than trying to tell autoconf/libtool that we are really cross compiling and it shouldn't add darwin-specific flags. This was broken in #9444 beforewhich file same linker flag filter was used for lld and llvm-link when compiling to and object file (i.e. when building a shared library).
sbc100
added a commit
that referenced
this pull request
Sep 21, 2019
On mac, libtool/autoconf will often add `-Wl,-bind_at_load` at link time which was causing and error when passed down the lld. Add a blacklist of linker flags we don't support in lld to avoid this issue. This seems easier than trying to tell autoconf/libtool that we are really cross compiling and it shouldn't add darwin-specific flags. This was broken in #9444 beforewhich file same linker flag filter was used for lld and llvm-link when compiling to and object file (i.e. when building a shared library).
sbc100
added a commit
that referenced
this pull request
Sep 26, 2019
Without `-c` emscripten will try to run lld on the object files its given to produce another object file. We should probably disable that for the single build case. This breakage was introduced in #9444 and we should probably address it, but compiling without `-c` is also broken so fixing here. Fixes #9510
sbc100
added a commit
that referenced
this pull request
Sep 26, 2019
Without `-c` emscripten will try to run lld on the object files its given to produce another object file. We should probably disable that for the single build case. This breakage was introduced in #9444 and we should probably address it, but compiling without `-c` is also broken so fixing here. Fixes #9510
belraquib
pushed a commit
to belraquib/emscripten
that referenced
this pull request
Dec 23, 2020
…9444) This change moves the "linking to object file" logic to separate phase which runs after compilation, but before the real "linking" phase. We can also delay library processing until after this phase as that is only needed for actual linking. This change is a step towards more conventional library linking See emscripten-core#8912.
belraquib
pushed a commit
to belraquib/emscripten
that referenced
this pull request
Dec 23, 2020
On mac, libtool/autoconf will often add `-Wl,-bind_at_load` at link time which was causing and error when passed down the lld. Add a blacklist of linker flags we don't support in lld to avoid this issue. This seems easier than trying to tell autoconf/libtool that we are really cross compiling and it shouldn't add darwin-specific flags. This was broken in emscripten-core#9444 beforewhich file same linker flag filter was used for lld and llvm-link when compiling to and object file (i.e. when building a shared library).
belraquib
pushed a commit
to belraquib/emscripten
that referenced
this pull request
Dec 23, 2020
Without `-c` emscripten will try to run lld on the object files its given to produce another object file. We should probably disable that for the single build case. This breakage was introduced in emscripten-core#9444 and we should probably address it, but compiling without `-c` is also broken so fixing here. Fixes emscripten-core#9510
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This change moves the "linking to object file" logic to separate
phase which runs after compilation, but before the real "linking"
phase. We can also delay library processing until after this phase
as that is only needed for actual linking.
This change is a step towards more conventional library linking
See #8912.