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

[H.J. Lu]

On Tue, Jul 28, 2020 at 6:33 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Jul 28, 2020 at 5:46 AM Simon Marchi <simark@simark.ca> wrote:
> >
> > On 2020-07-28 6:45 a.m., H.J. Lu wrote:
> > > On Mon, Jul 27, 2020 at 12:32 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >>
> > >> On Mon, Jul 27, 2020 at 12:14 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >>>
> > >>> On Mon, Jul 27, 2020 at 9:11 AM Aaron Merey <amerey@redhat.com> wrote:
> > >>>>
> > >>>> On Mon, Jul 27, 2020 at 11:32 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >>>>>
> > >>>>> On Sat, Jul 25, 2020 at 9:01 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >>>>>> This caused:
> > >>>>>>
> > >>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26301
> > >>>>>>
> > >>>>>
> > >>>>> It is quite normal to have debuginfod headers without libdebuginfod on
> > >>>>> multilib OSes.  Restore AC_CHECK_LIB to check if libdebuginfod exists.
> > >>>>> And always define HAVE_LIBDEBUGINFOD to 0 or 1 for
> > >>>>>
> > >>>>> binutils/dwarf.c:#if HAVE_LIBDEBUGINFOD
> > >>>>> binutils/dwarf.c:#if HAVE_LIBDEBUGINFOD
> > >>>>> binutils/dwarf.c:#if HAVE_LIBDEBUGINFOD
> > >>>>> binutils/dwarf.h:#if HAVE_LIBDEBUGINFOD
> > >>>>> binutils/objdump.c:#if HAVE_LIBDEBUGINFOD
> > >>>>> binutils/objdump.c:#endif /* HAVE_LIBDEBUGINFOD */
> > >>>>> binutils/readelf.c:#if HAVE_LIBDEBUGINFOD
> > >>>>> binutils/readelf.c:#endif /* HAVE_LIBDEBUGINFOD */
> > >>>>> gdb/top.c:#if HAVE_LIBDEBUGINFOD
> > >>>>>
> > >>>>> OK for master?
> > >>>>
> > >>>> Thanks for spotting this. Normally PKG_CHECH_MODULES would correctly
> > >>>> detect whether the .so and header are installed and build accordingly,
> > >>>> but when cross compiling the AC_CHECK_LIB may be needed.
> > >>>
> > >>> I am not cross compiling.  I am simply using "gcc -m32".   The problem
> > >>> is PKG_CHECK_MODULES which doesn't check if $pkg_cv_[]$1[]_LIBS
> > >>> actually works.   Here is the updated patch to fix PKG_CHECK_MODULES.
> > >>> Any comments or objections?
> > >>>
> > >>>
> > >>
> > >> HAVE_LIBDEBUGINFOD is a separate issue.  Here is the updated patch
> > >> which only adds AC_TRY_LINK to PKG_CHECK_MODULES to check if
> > >> $pkg_cv_[]$1[]_LIBS works.
> > >>
> > >
> > > I am checking it in.
> > >
> > > --
> > > H.J.
> > >
> >
> > You said that you are not cross-compiling, but technically I'd say you are cross compiling, since
> > you are building for a different architecture than what the compiler is running.  You are probably
> > configuring with --host=i686-something-something?
>
> On x86, the native GCC can support -m32 and -m64.  "gcc -m32" or "gcc -m64"
>  are not cross compiling.
>
> > Anyway regardless of vocabulary, I don't think there was a problem to begin with (not that I blame
> > you, it's not made in an intuitive way).  The problem is that you were using pkg-config as
> > configured to look up x86_64 packages.  It looks up .pc files in (amongst others)
> > /usr/lib64/pkgconfig, which provides information about x86_64 packages, which are in turn obviously
> > not suitable not suitable to build a i686 program.  Just like you cross-compile "for real" (say,
> > for an ARM host), you need to set PKG_CONFIG or the PKG_CONFIG_* variables to returns packages for
> > the --host architecture.  That means searching in /usr/lib/pkgconfig instead of /usr/lib64/pkgconfig.
> >
> > You could for example set the PKG_CONFIG_LIBDIR variable to /usr/lib/pkgconfig:/usr/share/pkgconfig
>
> I didn't set PKG_CONFIG_LIBDIR and I don't want to set it.
>
> > This way, if you don't install the elfutils-debuginfod-client-devel.i686 package, your binutils won't
> > try to link with libdebuginfod (because pkg-config won't find it).  If you install it, then your
> > binutils will be built against the i686 libdebuginfod.
> >
> > Ideally, distros would ship a i686-something-something-pkg-config that automatically searchs in paths
> > that make sense for that architecture (just like you have arm-linux-gnueabihf-pkg-config when cross
> > compiling for ARM), but that doesn't seem to exist.  But this is just like you have to explicitly set
> > CC="gcc -m32" instead of using some i686-something-something-gcc.
> >
> > You can always make it yourself, create, say, a `i686-pc-linux-gnu-pkg-config` file somewhere in $PATH,
> > with:
> >
> >   export PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/share/pkgconfig
> >   exec pkg-config $*
>
> I don't want to do it.  PKG_CHECK_MODULES should check if the library
> really works.
> Otherwise we can use remove it and use the library directly without checking.
>
> > Then, when you configure with --host=i686-pc-linux-gnu, AC_PATH_TOOL will automatically pick up that as
> > the pkg-config to use, and everything will work seamlessly.
> >
> > So, I concede that it's not intuitive, but I think your patch is not right because it just hides the
> > mis-configuration.  If `pkg-config` says a lib exists but we are not able to link with it, there is a
> > bigger problem than "lib not found".  I think it should be a hard error (abort configure) and tell the
> > user about it: "pkg-config says that libfoo is available but we can't link with it, are you maybe using
> > the wrong pkg-config, or a wrong pkg-config path?".
> >
> > Finally, the file you modified is maintained upstream here:
> >
> >   https://cgit.freedesktop.org/pkg-config/tree/pkg.m4.in
> >
> > Do you intend to submit your changes there?  Otherwise, they will be overwritten next time we sync with
> > upstream.
> >
>
> Will do.
>
> --
> H.J.

https://gitlab.freedesktop.org/pkg-config/pkg-config/-/merge_requests/6

-- 
H.J.