-
-
Notifications
You must be signed in to change notification settings - Fork 10.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 flags to superenv when building with [email protected] #13568
Conversation
Review period will end on 2022-07-19 at 00:00:00 UTC. |
gcc_include_dir, = Open3.capture2("#{cc} --print-file-name=include") | ||
gcc_include_fixed_dir, = Open3.capture2("#{cc} --print-file-name=include-fixed") | ||
paths << gcc_include_dir.strip << gcc_include_fixed_dir.strip |
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.
gcc_include_dir, = Open3.capture2("#{cc} --print-file-name=include") | |
gcc_include_fixed_dir, = Open3.capture2("#{cc} --print-file-name=include-fixed") | |
paths << gcc_include_dir.strip << gcc_include_fixed_dir.strip | |
gcc_include_dir = Utils.safe_popen_read(cc, "--print-file-name=include").chomp | |
gcc_include_fixed_dir = Utils.safe_popen_read(cc, "--print-file-name=include-fixed").chomp | |
paths << gcc_include_dir << gcc_include_fixed_dir |
This is more consistent with what we do elsewhere, assuming this works.
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 had a feeling that Open3 wasn't what we normally used. I'll test this in the Docker image before pushing to here.
I'm marking this as a draft for now because I need to push commits to this that I can test in a VM but I don't want it to be merged until the testing is done. |
82059ce
to
989d8c1
Compare
989d8c1
to
47b6492
Compare
There was just one minor issue I had to fix and now |
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.
Makes sense to me!
Review period skipped due to |
I know @Bo98 is busy with the ephemeral CI stuff right now but I would probably be good for him to have one more chance to look at this before merging given that this is tightly integrated with Homebrew/homebrew-portable-ruby#156. |
@@ -326,6 +328,9 @@ class Cmd | |||
end | |||
args += rpath_flags("#{wl}-rpath=", rpath_paths) | |||
args += ["#{wl}--dynamic-linker=#{dynamic_linker_path}"] if dynamic_linker_path | |||
# Use -rpath-link to make sure linker uses [email protected] rather than the system glibc for indirect | |||
# dependencies because -L will only handle direct dependencies. | |||
args << "#{wl}-rpath-link=#{@opt}/[email protected]/lib" if @deps.include?("[email protected]") |
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.
Do we need to change the -B
a few lines above?
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 guess it would only matter if the user was building against [email protected]
on a host where brewed glibc
was also installed. Given that we're only building against [email protected]
for relocatable bottles I don't think scenario should happen very often. We could probably accommodate this by just doing:
if @deps.include?("[email protected]")
args << "-B#{@opt}/[email protected]/lib"
else
args << "-B#{@opt}/glibc/lib"
end
If this sounds good I'll push the change.
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.
LGTM
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.
Did you decide against pushing this?
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 suspect @danielnachun forgot.
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.
Sorry I misunderstood your comment as wanting to merge as-is. We need to fix the issue below with unconditionally passing nostdinc
so I will add this in a follow up PR.
@@ -292,6 +292,8 @@ class Cmd | |||
args.concat(optflags) unless runtime_cpu_detection? | |||
args.concat(archflags) | |||
args << "-std=#{@arg0}" if /c[89]9/.match?(@arg0) | |||
# Add -nostdinc when building against [email protected] to avoid mixing system and brewed glibc headers. | |||
args << "-nostdinc" if @deps.include?("[email protected]") |
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.
Looks like this is gated to not run if we're not doing arg refurbishment (line 287).
I argue we actually want to do this unconditionally. I think this should be in cppflags
instead, like the other -isystem
flags. cppflags
applies to all modes - including cpp
invokations where neither cflags
nor cxxflags
are used.
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.
That makes sense. I tried this and it fixed the issue where the system headers were still being included seen here: Homebrew/homebrew-portable-ruby#156 (comment).
def homebrew_extra_isystem_paths | ||
paths = [] | ||
# Add paths for GCC headers when building against [email protected] because we have to use -nostdinc. | ||
if deps.any? { |d| d.name == "[email protected]" } |
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.
@danielnachun I'd really like if we can extract all these references into a global constant or, if that doesn't allow superenv handling, a file somewhere.
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.
So basically use a variable instead of hard coding [email protected]
so we only have to change it once? That does seem better for maintainability, I just have to see where I can define it that will be seen by both the superenv and the compiler shim.
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.
@danielnachun I think the answer may be "nowhere" but at least if it's in two places with a comment in both that says to change them both at once that'd be better!
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.
Our compiler shim doesn't load the Homebrew
module, but we can definitely put this into a global constant which is passed to the compiler shim via an environment variable.
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.
ooo environment variable, 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.
Or the existing cccfg system
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 we could append_to_cccfg
a character for whenever glibc@#{MIN_GLIBC_VERSION}
is a dependency where MIN_GLIBC_VERSION
is an environment variable we set once globally. The individual conditionals on [email protected]
being a dependency could then be replaced with conditional on HOMEBREW_CCCFG
containing the relevant character, and the actual flags we set would also use #{MIN_GLIBC_VERSION}
instead of the hardcoded 2.13
we're currently using. That should mean that whenever the version needs to be changed, we can just update MIN_GLIBC_VERSION
and everything else will be updated automatically because it's not hardcoded.
Now that we know our strategy for handling [email protected]
works I can just test the refactoring by trying to build binutils
as it will fail quickly if I mess something up. Thanks for the great suggestions for this!
This PR should fix most of the issues we were hitting in Homebrew/homebrew-portable-ruby#156. The root of the problem is that we can't mix headers from the system
glibc
with[email protected]
and the only way to guarantee this is to use-nostdinc
and add the paths to the GCC headers with-isystem
flags.