-
-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
elftoolchain 0.7.1 (new formula) #104303
elftoolchain 0.7.1 (new formula) #104303
Conversation
Formula/elftoolchain.rb
Outdated
# TODO: add conflicts after merge | ||
# on_macos do | ||
# conflicts_with "libelf", because: "both install `libelf`" | ||
# conflicts_with "dwarfutils", because: "both install `libdwarf`" | ||
# end |
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.
Currently chose to link on macOS and keep keg-only on Linux. All packages that may conflict:
binutils
- keg-only on macOSelfutils
- Linux-onlylibelf
- deprecated and planning to disable/remove soonmono
- due tomsc
binary, but I added workaround to only install intolibexec
and not link tobin
. Alternatively, could just mark conflict.dwarfutils
- only maintained formula that actually conflicts in current state.
Another option is to install libelf*
/libdwarf*
into a subdirectory like LIBDIR=#{lib}/#{name}
which may remove conflict with libelf
& dwarfutils
, but this may make it trickier to use by dependents/users as may need to manually add LDFLAGS
and update RPATH
include.mkpath | ||
|
||
# use libexec on macOS to avoid shadowing commands, which break dependent builds | ||
args = %W[ |
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.
Is there a PROGRAM_PREFIX
argument we can use? That seems to make more sense since the binaries that ship with this formula are meant to work on ELF files, so they're not exactly equivalent to the system-provided ones (which is the case for your typical keg-only/unlinked binaries).
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 didn't see anything that we can easily use.
MacPorts manually does this (i.e. mv cmd to elftc-#{cmd}
and symlink into libexec/elftoolchain/#{cmd}
) and also uses subdirectories (e.g. lib/elftoolchain
, include/elftoolchain
, ...) to avoid conflicts https://github.com/macports/macports-ports/blob/master/devel/elftoolchain/Portfile#L69-L78
The above would allow us to remove all conflicts/keg-only while having main files installed into linked directories.
Another option is to install binaries under libexec/...
and just symlink to bin/SOMEPREFIX-#{cmd}
(e.g. either elftc-ar
like MacPorts or full name like elftoolchain-ar
).
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.
Fine with doing any of that.
I'm ok to merge this as-is or after renaming the binaries to be prefixed with |
The draft formula feels like a pile of patches and hacks. I'd say either they can be upstreamed, or this does not feel stable at all. |
Closing for now. Still hoping for a new release. |
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>
?Considering as replacement for
libelf
on macOS #103251