public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: orbea <orbea@riseup.net>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: Re: [PATCH] gdb: Don't overwrite CC when checking for BFD support
Date: Fri, 21 Apr 2023 11:13:40 -0700	[thread overview]
Message-ID: <20230421111315.6cde5485@Akita> (raw)
In-Reply-To: <87354t1e78.fsf@tromey.com>

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

On Fri, 21 Apr 2023 08:51:07 -0600
Tom Tromey <tom@tromey.com> 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.

[-- Attachment #2: 0001-gdb-Don-t-use-libtool-during-configure.patch --]
[-- Type: text/x-patch, Size: 1927 bytes --]

From f9927ebcc896c6acdad7457fa6c11ef723a1c992 Mon Sep 17 00:00:00 2001
From: orbea <orbea@riseup.net>
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


[-- Attachment #3: 0002-libctf-Don-t-use-libtool-during-configure.patch --]
[-- Type: text/x-patch, Size: 2085 bytes --]

From ebe4db6c971cc7babbc8365d13151171b7b118b5 Mon Sep 17 00:00:00 2001
From: orbea <orbea@riseup.net>
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 <stdlib.h>
 	     #include <string.h>
@@ -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


      reply	other threads:[~2023-04-21 18:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-19 18:16 orbea
2023-04-21 14:51 ` Tom Tromey
2023-04-21 18:13   ` orbea [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230421111315.6cde5485@Akita \
    --to=orbea@riseup.net \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).