From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id rhZBKHDSQmQ8ejIAWB0awg (envelope-from ) for ; Fri, 21 Apr 2023 14:14:08 -0400 Received: by simark.ca (Postfix, from userid 112) id 924141E221; Fri, 21 Apr 2023 14:14:08 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=oM0UvBIO; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C2E501E128 for ; Fri, 21 Apr 2023 14:14:07 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E59CC3857716 for ; Fri, 21 Apr 2023 18:14:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E59CC3857716 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1682100846; bh=8hKqX9i7bBm2lklld+XfvuRGkGAm8K5LOJ2FDuCpmUQ=; h=Date:To:Cc:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=oM0UvBIOP+IDUKvdvqxIpT3iaqk+sg23F+Zn7kthPpkaYBf/0aW4V0uSnWfraEdB7 eXrmFkhoLl9V/aiSkWnIP/HxCVF9rOqSmAu2BfFdAbKRr2gsEUPGz3YjaTNsED1hDb RgMVRLMnHATBbivKT+1VAYzfbCh9vODQswZlYQ2A= Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) by sourceware.org (Postfix) with ESMTPS id D3C653858D20 for ; Fri, 21 Apr 2023 18:13:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D3C653858D20 Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.riseup.net", Issuer "R3" (not verified)) by mx0.riseup.net (Postfix) with ESMTPS id 4Q32hm2VSJz9tJM; Fri, 21 Apr 2023 18:13:44 +0000 (UTC) X-Riseup-User-ID: FFE57944C932B31548D7484ACE7050380AB5A11D8D8C72D0F3568FD952565FF1 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4Q32hl6f9kzFpx2; Fri, 21 Apr 2023 18:13:43 +0000 (UTC) Date: Fri, 21 Apr 2023 11:13:40 -0700 To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: Re: [PATCH] gdb: Don't overwrite CC when checking for BFD support Message-ID: <20230421111315.6cde5485@Akita> In-Reply-To: <87354t1e78.fsf@tromey.com> References: <20230419111628.0e1f33f0@Akita> <87354t1e78.fsf@tromey.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/rVIOhgor+GN_znBTdO1mhD." 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: , From: orbea via Gdb-patches Reply-To: orbea Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" --MP_/rVIOhgor+GN_znBTdO1mhD. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, 21 Apr 2023 08:51:07 -0600 Tom Tromey wrote: > I applied this patch and re-ran autoconf, then tried a build. > It failed, and looking in gdb/config.log I see: > > configure:28348: gcc -o conftest -I../../binutils-gdb/gdb/../include > -I../bfd -I../../binutils-gdb/gdb/../bfd -g -O2 -L../bfd > -L../libiberty conftest.c -lbfd -liberty -lncursesw -lm >&5 > /bin/ld: cannot find -lbfd > > ... which is what I guess I would have predicted. This is likely because the first '-l../bfd' precedes the '-L../bfd' and I have attached a new more complete patch that should correct this oversight. Additionally I made a second patch for libctf which has the same issue. > IIUC you are using some kind of libtool replacement. I don't know > exactly how but it seems to me that some other sort of fix is needed. > > Perhaps the line: > > CC="./libtool --quiet --mode=link $CC" > > could also use whatever variable(s) you are setting to pass in your > alternative setup? Looking at your build log, I don't see anything > special passed to configure, so perhaps that also has to change on > your side. When using an alternative libtool implementation it is set in the user's environment with the $MAKEFLAGS variable. export MAKEFLAGS='LIBTOOL=rlibtool' However some build systems where I believe gdb is an example will somehow lose $MAKEFLAGS during the build process through the use of recursive make where the $MAKE variable also needs to be set. export MAKE='make LIBTOOL=rlibtool' Ideally it would be nice to not rely on the $LIBTOOL variable during the configure process. If you are interested there is more information at the slibtool upstream git repo. https://dev.midipix.org/cross/slibtool Additionally the directions on how to use this in Gentoo is documented at their wiki. https://wiki.gentoo.org/wiki/Slibtool > Anyway, I'm sorry, but I don't think this patch can go in as-is. > > thanks, > Tom Thank you for testing and apologies that I should of looked closer before submitting my first patch. --MP_/rVIOhgor+GN_znBTdO1mhD. Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=0001-gdb-Don-t-use-libtool-during-configure.patch >From f9927ebcc896c6acdad7457fa6c11ef723a1c992 Mon Sep 17 00:00:00 2001 From: orbea Date: Fri, 21 Apr 2023 10:34:16 -0700 Subject: [PATCH 1/2] gdb: Don't use libtool during configure When using alternative libtool implementations such as slibtool the configure process will fail to check for ELF support in BFD because it uses the hard coded libtool from configure.ac rather than slibtool which was used to build BFD. This can be solved by not using libtool here where the linker paths are changed to explicitly precede the appropriate linker flag to ensure the newly built BFD is used. --- gdb/acinclude.m4 | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/gdb/acinclude.m4 b/gdb/acinclude.m4 index 173e40b4..46b2b43f 100644 --- a/gdb/acinclude.m4 +++ b/gdb/acinclude.m4 @@ -227,17 +227,12 @@ dnl A link test is run. dnl HEADER is the name of an extra BFD header to include. AC_DEFUN([GDB_AC_CHECK_BFD], [ OLD_CFLAGS=$CFLAGS - OLD_LDFLAGS=$LDFLAGS OLD_LIBS=$LIBS - OLD_CC=$CC - # Put the old CFLAGS/LDFLAGS last, in case the user's (C|LD)FLAGS - # points somewhere with bfd, with -I/foo/lib and -L/foo/lib. We - # always want our bfd. + # Put the old CFLAGS last, in case the user's CFLAGS points somewhere + # bfd, with -I/foo/lib and -L/foo/lib. We always want our bfd. CFLAGS="-I${srcdir}/../include -I../bfd -I${srcdir}/../bfd $CFLAGS" - LDFLAGS="-L../bfd -L../libiberty $LDFLAGS" intl=`echo $LIBINTL | sed 's,${top_builddir}/,,g'` - LIBS="-lbfd -liberty $intl $LIBS" - CC="./libtool --quiet --mode=link $CC" + LIBS="-L../bfd -lbfd -L../libiberty -liberty $intl $LIBS" AC_CACHE_CHECK( [$1], [$2], @@ -253,9 +248,7 @@ AC_DEFUN([GDB_AC_CHECK_BFD], [ [[$2]=no] )] ) - CC=$OLD_CC CFLAGS=$OLD_CFLAGS - LDFLAGS=$OLD_LDFLAGS LIBS=$OLD_LIBS]) dnl GDB_GUILE_PROGRAM_NAMES([PKG-CONFIG], [VERSION]) -- 2.39.2 --MP_/rVIOhgor+GN_znBTdO1mhD. Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=0002-libctf-Don-t-use-libtool-during-configure.patch >From ebe4db6c971cc7babbc8365d13151171b7b118b5 Mon Sep 17 00:00:00 2001 From: orbea Date: Fri, 21 Apr 2023 10:39:21 -0700 Subject: [PATCH 2/2] libctf: Don't use libtool during configure When using alternative libtool implementations such as slibtool the configure process will fail to check for ELF support in BFD because it uses the hard coded libtool from configure.ac rather than slibtool which was used to build BFD. This can be solved by not using libtool here where the linker paths are changed to explicitly precede the appropriate linker flag to ensure the newly built BFD is used. --- libctf/configure.ac | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/libctf/configure.ac b/libctf/configure.ac index 6a5eade1..b84b46f1 100644 --- a/libctf/configure.ac +++ b/libctf/configure.ac @@ -78,17 +78,12 @@ AM_CONDITIONAL(ENABLE_LIBCTF_HASH_DEBUGGING, test "${enable_libctf_hash_debuggin # Similar to GDB_AC_CHECK_BFD. OLD_CFLAGS=$CFLAGS -OLD_LDFLAGS=$LDFLAGS OLD_LIBS=$LIBS -OLD_CC=$CC -# Put the old CFLAGS/LDFLAGS last, in case the user's (C|LD)FLAGS -# points somewhere with bfd, with -I/foo/lib and -L/foo/lib. We -# always want our bfd. -CC="./libtool --quiet --mode=link $OLD_CC" +# Put the old CFLAGS last, in case the user's CFLAGS points somewhere +# with bfd, with -I/foo/lib and -L/foo/lib. We always want out bfd. CFLAGS="-I${srcdir}/../include -I../bfd -I${srcdir}/../bfd $CFLAGS" -LDFLAGS="-L../bfd -L../libiberty $LDFLAGS" intl=`echo $LIBINTL | sed 's,${top_builddir}/,,g'` -LIBS="-lbfd -liberty $intl $LIBS" +LIBS="-L../bfd -lbfd -L../libiberty -liberty $intl $LIBS" AC_CACHE_CHECK([for ELF support in BFD], ac_cv_libctf_bfd_elf, [AC_TRY_LINK([#include #include @@ -99,9 +94,7 @@ AC_CACHE_CHECK([for ELF support in BFD], ac_cv_libctf_bfd_elf, [ac_cv_libctf_bfd_elf=yes], [ac_cv_libctf_bfd_elf=no])]) CFLAGS=$OLD_CFLAGS -LDFLAGS=$OLD_LDFLAGS LIBS=$OLD_LIBS -CC=$OLD_CC if test $ac_cv_libctf_bfd_elf = yes; then AC_DEFINE([HAVE_BFD_ELF], 1, -- 2.39.2 --MP_/rVIOhgor+GN_znBTdO1mhD.--