From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) by sourceware.org (Postfix) with ESMTPS id 62E153844046; Tue, 28 Jul 2020 13:53:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 62E153844046 Received: by mail-io1-xd44.google.com with SMTP id z6so20837576iow.6; Tue, 28 Jul 2020 06:53:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QzvbiMAPLPypvWD3V4lzywLLwhcwV+fyzdVBbL04Luc=; b=t72yc+lbQE/piTObgDwcF04z5WtWLd6ZrU++5e9wzGlZK7TNxQ/3w5e28gyxtTcQh3 OlSqWxUoz1Kq6I9i49S5g2N1cMC0e0rROzC3946F8LJ7TF6xjVba7xk/fCInYB0ui8TV 6m7Utt/bL+H+EM5n95XP1wUgTv85WHFozlm0w2ZBjqnkp/rTf49zbLdWEKPpKiOAgJ9z gL1p/ZE28LOS8fEIIjaOuKwr+q9LH6QoO6p/bGLe4bEJLkjw3L1n9R8kJAC3oBeaI6j1 XZ4uyfziheAV/lzetyvh8Qkff3fGgCw1bdg7DEdAUKVwGmVTPZhu3hhrfxef9RDjHNDK mq1A== X-Gm-Message-State: AOAM532I6IqYO5RIH9VMIlk19VEDNz2q/9/M01JN4NqfvrXOSjrM/cOr n5UiKOPQmxSqUUfi5kyOoANoFiyAO+RByRtDrEY= X-Google-Smtp-Source: ABdhPJwr561C18nInPMc48nTiIbljVSgIX2mPgQzWK9BkBTyb901XjCTK22/ylB8gcHoqeeRXXzFq7HoZQ8JiLO2xZg= X-Received: by 2002:a05:6638:1187:: with SMTP id f7mr33137362jas.58.1595944416764; Tue, 28 Jul 2020 06:53:36 -0700 (PDT) MIME-Version: 1.0 References: <20200502022903.175852-1-amerey@redhat.com> <3d9da16939fa6b503188033b56d30531e03d5d2a.camel@redhat.com> <87a72ino27.fsf@tromey.com> <64517fee-8b8f-84b2-a116-c3d146ff1119@simark.ca> <87eep4hp3s.fsf@tromey.com> <996bd0f9-cec5-119c-19ea-b127cf1bb95d@simark.ca> In-Reply-To: From: "H.J. Lu" Date: Tue, 28 Jul 2020 06:53:01 -0700 Message-ID: Subject: Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works To: Simon Marchi Cc: Aaron Merey , Tom Tromey , GCC Patches , Aaron Merey via Binutils , GDB Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 13:53:39 -0000 On Tue, Jul 28, 2020 at 6:33 AM H.J. Lu wrote: > > On Tue, Jul 28, 2020 at 5:46 AM Simon Marchi 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 wrote: > > >> > > >> On Mon, Jul 27, 2020 at 12:14 PM H.J. Lu wrote: > > >>> > > >>> On Mon, Jul 27, 2020 at 9:11 AM Aaron Merey wrote: > > >>>> > > >>>> On Mon, Jul 27, 2020 at 11:32 AM H.J. Lu wrote: > > >>>>> > > >>>>> On Sat, Jul 25, 2020 at 9:01 AM H.J. Lu 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.