[PATCH] libbfd: Always compile plugin.c into libbfd
H.J. Lu
hjl.tools@gmail.com
Thu Aug 7 13:47:18 GMT 2025
On Thu, Aug 7, 2025 at 6:37 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Aug 7, 2025 at 6:31 AM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 07.08.2025 15:24, H.J. Lu wrote:
> > > On Thu, Aug 7, 2025 at 5:37 AM Alan Modra <amodra@gmail.com> wrote:
> > >>
> > >> On Thu, Aug 07, 2025 at 10:47:56AM +0200, Jan Beulich wrote:
> > >>> On 06.08.2025 20:21, H.J. Lu wrote:
> > >>>> Always compile plugin.c into libbfd.
> > >>>
> > >>> As indicated, I disagree with any adding of entirely dead code to an already
> > >>> too large (in many cases) library. It's not a huge amount of code, but still
> > >>> it moves us into the wrong direction, imo. I do not, however, disagree enough
> > >>> to outright reject this change - if Nick and/or Alan think it's okay to do go
> > >>> this route, then so be it.
> > >>
> > >> I too think we are better off without this change.
> > >
> > > 99% of binutils users need plugin while very few of them need S-records,
> > > verilog, tekhex, ihex, which are always included in libbfd. This doesn't
> > > make any sense to me.
> >
> > Well, I'd very much like to see us drop unused bits wherever possible.
> >
>
> Well, plugin is used by almost all binutils users. It is far from dead code.
> If these less common codes could be include in libbfd in the first place,
> plugin is far more qualified.
>
> --
> H.J.
Checking BFD_SUPPORTS_PLUGINS all over the place only benefits
very small percentage of binutils users while everyone else pays the price.
--
H.J.
More information about the Binutils
mailing list