Skip to content
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

binutils: make keg_only #33419

Closed
wants to merge 2 commits into from
Closed

binutils: make keg_only #33419

wants to merge 2 commits into from

Conversation

zbeekman
Copy link
Contributor

@zbeekman zbeekman commented Oct 26, 2018

gnm is broken with macOS 10.14 Mojave/XCode 10. This breaks gcc when
binutils is linked.

Fixes: #32516

See also: https://sourceware.org/bugzilla/show_bug.cgi?id=23728

  • Have you followed the guidelines for contributing?
  • Have you checked that there aren't other open pull requests for the same formula update/change?
  • Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
  • Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

@zbeekman
Copy link
Contributor Author

I also changed the test do block, since gnm is currently broken on mojave/XCode10.

@zbeekman zbeekman added maintainer feedback Additional maintainers' opinions may be needed 10.14 Mojave is specifically affected xcode10 Xcode 10 is specifically affected labels Oct 26, 2018
@@ -32,6 +38,6 @@ def install
end

test do
assert_match "main", shell_output("#{bin}/gnm #{bin}/gnm")
assert_match "__TEXT", shell_output("#{bin}/gstrings #{bin}/gstrings")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than an using an internal symbol like __TEXT (which though unlikely could change) I'd suggest using some text from strings --help such as the word Usage.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a great idea!

@@ -12,6 +13,11 @@ class Binutils < Formula
sha256 "7c693e68ebfcd654fd781480e68469e8f5af93c7397754a8caae1937322feb8f" => :el_capitan
end

# See sourceware.org/bugzilla/show_bug.cgi?id=23728 and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# See sourceware.org/bugzilla/show_bug.cgi?id=23728 and
# See https://sourceware.org/bugzilla/show_bug.cgi?id=23728 and

@zbeekman zbeekman added ready to merge PR can be merged once CI is green and removed maintainer feedback Additional maintainers' opinions may be needed labels Oct 26, 2018
# https://github.com/Homebrew/homebrew-core/issues/32516
keg_only :provided_by_macos,
"because Apple provides binutils and gnm is broken and breaks gcc"

# No --default-names option as it interferes with Homebrew builds.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Remove the comment, which is now irrelevant.
  • The --program-prefix=g configure option should go too, since we don't put these tools in PATH anymore.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fxcoudert Which comment? The # No --default-names ... one? Also, should we add back --default-names?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better to create a directory libexec/bin of symlinks with the default names, that users can add to their path if they desire.

Copy link
Contributor Author

@zbeekman zbeekman Oct 27, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I searched for explicit dependencies on binutils, and came up with 4 formula:

(I used brew uses --include-build --include-test --include-optional --recursive binutils to search.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went through the four formula above and none had any obvious adjustments that were required in the formula itself, however, virtually all of them require access to binutils binaries at runtime. Will the cause issues because the binutils executables are not on the default PATH anymore? Would formula revision bumps solve this, if it is indeed an issue?

@zbeekman zbeekman added maintainer feedback Additional maintainers' opinions may be needed and removed ready to merge PR can be merged once CI is green labels Oct 27, 2018
@zbeekman zbeekman force-pushed the binutils branch 2 times, most recently from 8016b79 to b325233 Compare October 28, 2018 19:19
@zbeekman
Copy link
Contributor Author

@Homebrew/core It looks like pwntools 3.12.0 is failing due to Gallopsled/pwntools#1191. I'm having trouble figuring out what is causing the build failure for pwntools to 3.12.1. There are a bunch of undefined symbols. Do we have to add missing (new) dependencies?

I sort of pinged upstream in Gallopsled/pwntools#683.

Should I just leave pwntools as is and merge binutils?

@MikeMcQuaid
Copy link
Member

Should I just leave pwntools as is and merge binutils?

@zbeekman We should avoid merging PRs we know will break other software in Homebrew/homebrew-core.

@zbeekman
Copy link
Contributor Author

We should avoid merging PRs we know will break other software in Homebrew/homebrew-core.

@MikeMcQuaid I agree. I was (erroneously) under the impression that changes outside my binutils PR were responsible for breaking pwn tools.

I tested building pwntools 3.12.0 and 3.12.1 locally, without the binutils changes and the do in fact build for me. Since pwntools 3.12.1 fixes a bug that the binutils keg_only migration seems to trigger before the build fails in different ways, I'll open a PR just for upgrading pwntools, while I investigate what needs to be done to get it working with migrated binutils.

@MikeMcQuaid
Copy link
Member

@zbeekman Sounds good, thanks 👍

@zbeekman zbeekman mentioned this pull request Oct 29, 2018
@zbeekman zbeekman force-pushed the binutils branch 2 times, most recently from 8f6cec2 to 61130fb Compare October 29, 2018 19:56
@zbeekman zbeekman removed the maintainer feedback Additional maintainers' opinions may be needed label Oct 29, 2018
@zbeekman
Copy link
Contributor Author

Summary:

  • binutils was made keg_only
  • Installed binaries no longer have the g prefix, e.g., gnm -> nm
  • Symbolic links put in bin dir with the g prefix to ensure backwards compatibility for folks relying on, e.g., gstrings
  • Revision bump to trigger re-installation

# See https://sourceware.org/bugzilla/show_bug.cgi?id=23728 and
# https://github.com/Homebrew/homebrew-core/issues/32516
keg_only :provided_by_macos,
"because Apple provides binutils and gnm is broken and breaks gcc"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either we decide that keg-only is temporary, and the comment (and links) is adequate, or we decide that even when gnm is fixed we'd prefer binutils to stay keg-only (which I think is preferable). But then discussion about gnm bugs is irrelevant.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

decide that even when gnm is fixed we'd prefer binutils to stay keg-only (which I think is preferable)

👍 I'll remove comments.

`gnm` is broken with macOS 10.14 Mojave/XCode 10. This breaks gcc when
binutils is linked.

Fixes: Homebrew#32516

See also: https://sourceware.org/bugzilla/show_bug.cgi?id=23728
 - Putting binutils on the path at build time breaks the build
 - The test passes without the binutils dependency
@zbeekman zbeekman closed this in a85359b Oct 30, 2018
@lock lock bot added the outdated PR was locked due to age label Nov 29, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Nov 29, 2018
@zbeekman zbeekman deleted the binutils branch April 11, 2019 18:04
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
10.14 Mojave is specifically affected outdated PR was locked due to age xcode10 Xcode 10 is specifically affected
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants