V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

H.J. Lu hjl.tools@gmail.com
Tue Jul 28 18:31:22 GMT 2020


On Tue, Jul 28, 2020 at 10:43 AM Simon Marchi <simark@simark.ca> wrote:
>
> On 2020-07-28 1:26 p.m., H.J. Lu wrote:
> > On Tue, Jul 28, 2020 at 9:28 AM Simon Marchi <simark@simark.ca> wrote:
> >>
> >> On 2020-07-28 12:07 p.m., H.J. Lu via Gdb-patches wrote:
> >>> What doesn't work with my pkg.m4 change?
> >>
> >> (1) It deviates from upstream.  I don't think we should do this unless
> >>     absolutely needed.  That's not the case here, the change is just there
> >>     because you don't want to set up pkg-config properly for cross-compiling.
> >
> > Since when binutils can't fix issues in other packages?
>
> Like I said, we can make local changes if necessary, to fix issues.  But there is
> no issue to fix here, all is needed is to have a proper build environment.
>
> Doing an unnecessary local change just adds burden on the next person who
> will sync this file with upstream, so it should not be taken lightly.

I have submitted a merge request to fix it upstream.

> > Unlike gdb, binutils should have as few external depecies as possible.
> > debuginfod brings in some so many external depecies.
>
> I'm not a binutils maintainer, so that's not my role to decide about that
> tradeoff... but we are talking about having an optional (only needed when
> enabling support for libdebuginfod) *build* dependency on a quite standard
> tool.  That's not very demanding.
>
> If you don't want to deal with libdebuginfod, you can also just build with
> --without-debuginfod.

My binutils script had been working fine until pkg.m4 was added.  Can it
be moved to gdb directory?

-- 
H.J.


More information about the Binutils mailing list