Open
Conversation
When using the macos system python, we replace <venv>/bin/python ``/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/bin/python` which does not exist, only a python3.9 and python3 binary exist. To fix this problem, use two approaches: 1) if <venv>/bin/python is a symlink, resolve that and 2) try checking for python3.
Similar to pyrefly silence all the warnings that are too annoying to fix immediately to establish a baseline to prevent regressions.
These should not be used for other projects, they are just there to add an easy way of building linux using GCC instead of the default clang. In the future we may want to also allow using GCC to compile other targets but for now this is sufficient.
Now that there's RVY muslc and busybox
Instead of having one common target info, use one for each Linux repository. Since these all build different versions of Linux and install to different root directories, it does not make sense to share the same target info. This greatly simplifies finding the correct dependencies and is overall cleaner.
This is needed to resolve the cyclic dependency between compiler-rt-builtins (which needs musl and linux headers) and musl which needs compiler-rt-builtins to build correctly. Install just the headers first, then build compiler-rt-builtins and then build muslc. Co-authored-by: Alex Richardson <alexrichardson@google.com>
When installing the muslc headers (for compiler-rt), we should reuse the same source and build directory as the full "stage2" build that depends on compiler-rt and the linux headers.
compiler-rt only depends on the C and kernel headers, not an entire sysroot which will unnecessarily builds muslc. This could also trigger circular deps conflicts because dynamically-linked muslc depends on compiler-rt library. Co-authored-by: Alex Richardson <alexrichardson@google.com>
If building muslc on its own, it only requires the Linux kernel headers and compiler-rt builtin libraries.
Dynamically linked muslc does need compiler-rt builtins
There are no guarantees the kernel sets up valid stdio fds for init, so explicitly set it up in the init script.
This is already done in AutotoolsProject.
We have to limit it to <82 to ensure that projects that still need pkg_resources continue working.
arichardson
force-pushed
the
linux-updates-improved
branch
from
0356f7f to
8966b80
Compare
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 is a rebased and somewhat improved version of PR #451.
I dropped the linux-headers target since it is not needed to solve cyclic dependencies, otherwise the result should be mostly the same.
@heshamelmatary could you test this?