-
-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
gcc 12.1.0 #106755
gcc 12.1.0 #106755
Conversation
# Use `lib/gcc/current` to provide a path that doesn't change with GCC's version. | ||
args = %W[ | ||
--prefix=#{opt_prefix} | ||
--libdir=#{opt_lib}/gcc/#{version_suffix} | ||
--libdir=#{opt_lib}/gcc/current |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CC @fxcoudert, in case this is not a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a good idea, and I cannot see any drawback. But, this is a subtle issue, so I might be overlooking something 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it's the subtle issues that I'm concerned about. Ah well, hopefully nothing 💥s
@@ -210,7 +208,7 @@ def post_install | |||
# * `-L#{HOMEBREW_PREFIX}/lib` instructs gcc to find the rest | |||
# brew libraries. | |||
# Note: *link will silently add #{libdir} first to the RPATH | |||
libdir = HOMEBREW_PREFIX/"lib/gcc/#{version_suffix}" | |||
libdir = HOMEBREW_PREFIX/"lib/gcc/current" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iMichka @danielnachun I don't know what this does, so would be good to check that this makes sense.
I'm also not clear on why we don't want opt_lib
here, as in opt_lib/"gcc/current"
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can clean this up in a second step as this is in the postinstall block.
current
looks ok to me given the other changes to gcc made here.
There are some explanations above: the spec file just makes sure the right -L
flags are passed when using brewed gcc (without shims, so when you want to compile your own stuff locally). With this our users don't need to set the -L
flags manually for the internal gcc libraries.
As to why not using opt_lib
: why not, might be worth a try.
I'm wondering if we really need to do this. I don't think anything inside Homebrew relies on this, and I think it's more confusing to add a duplicate tree structure (especially since we cannot have a single symlink). |
I would find it pretty confusing to have a If we don't want the symlinks, why not just make it Maybe as additional context, this is really motivated by the directory structure you find in a typical macOS framework. There, you have a If this is very confusing, we could make |
@carlocab I see your reasoning. One point of note is that if several directories exist, we might start having stuff link to specific version numbers instead of |
No, the linker will use the library install names, which reference In particular, you can do something like
and yet you will still link using the On Linux all that matters is the |
Linkage failures:
|
ARM failures:
|
Dropped |
If it fails again I don't think it should block merging this. |
which triggers failures in
|
In addition to the first PR removing Linux-only dependencies that fail at #106926 here is a list of failures in the previous (unfinished) run: |
Some Googling suggests this could be a consequence of running |
Bottles are being uploaded. Assuming the GitHub runner doesn't run out of space, I expect this to land within the next hour or so. |
🚢 |
This fails to build when Python3 is not available. See Homebrew#106755.
Here is the PR for |
Let's work on the rest of the issues found on Linux:
|
gdb: #107389
My guess is that this covers the rest of the
|
That would be very helpful, @bradcray, thanks so much. To be clear, the macOS builds are fine. It's the Linux build that seems to have issues. The error log is here: https://github.com/Homebrew/homebrew-core/runs/7661609625?check_suite_focus=true#step:11:4370 |
EDIT: Currently no error on macOS 10.15 with |
Follow up of Homebrew#106755
brew install --build-from-source <formula>
, where<formula>
is the name of the formula you're submitting?brew test <formula>
, where<formula>
is the name of the formula you're submitting?brew audit --strict <formula>
(after doingbrew install --build-from-source <formula>
)? If this is a new formula, does it passbrew audit --new <formula>
?Continuation of #100411, since rebasing that was a little tricky.
Closes #100411.