From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id DA29B3857C52; Tue, 28 Jul 2020 12:46:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DA29B3857C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 2EEA81E794; Tue, 28 Jul 2020 08:46:25 -0400 (EDT) Subject: Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works To: "H.J. Lu" , Aaron Merey Cc: Tom Tromey , GCC Patches , Aaron Merey via Binutils , GDB 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> From: Simon Marchi Message-ID: <996bd0f9-cec5-119c-19ea-b127cf1bb95d@simark.ca> Date: Tue, 28 Jul 2020 08:46:19 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, 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 12:46:31 -0000 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? 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 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 $* 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. Simon