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 Gcc-patches
mailing list