On Tue, Jul 28, 2020 at 5:46 AM Simon Marchi <sim...@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.to...@gmail.com> wrote: > >> > >> On Mon, Jul 27, 2020 at 12:14 PM H.J. Lu <hjl.to...@gmail.com> wrote: > >>> > >>> On Mon, Jul 27, 2020 at 9:11 AM Aaron Merey <ame...@redhat.com> wrote: > >>>> > >>>> On Mon, Jul 27, 2020 at 11:32 AM H.J. Lu <hjl.to...@gmail.com> wrote: > >>>>> > >>>>> On Sat, Jul 25, 2020 at 9:01 AM H.J. Lu <hjl.to...@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.
