public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] gdb: Don't overwrite CC when checking for BFD support
@ 2023-04-19 18:16 orbea
  2023-04-21 14:51 ` Tom Tromey
  0 siblings, 1 reply; 3+ messages in thread
From: orbea @ 2023-04-19 18:16 UTC (permalink / raw)
  To: gdb-patches

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

In gdb/acinclude.m4 'libtool' is hard coded within the provided custom
CC variable which results in a failure when using slibtool instead of
GNU libtool where the two different libtool implementations are
incompatible when both are used during the same build process at once.

This can be solved by using the default value for CC instead where
autotools is capable of providing an adequate value by default. I
attached a patch doing this.

A bug report was issued here:
https://sourceware.org/bugzilla/show_bug.cgi?id=30295

Please see comment 3 with the explanation where before I was missing
the real issue.

[-- Attachment #2: gdb_acinclude_m4.patch --]
[-- Type: text/x-patch, Size: 855 bytes --]

commit 31245fcf4fc31e732f05205f739317e9c8922da3
Author: orbea <orbea@riseup.net>
Date:   Fri Mar 31 09:46:51 2023 -0700

    gdb: Don't overwrite CC when checking for BFD support
    
    When building with an alternative libtool implementation such as
    slibtool the configure check for BFD features will fail in
    gdb/configure.ac because './libtool' was hardcoded.
    
    Simply removing the line allows the configure check to work correctly.

diff --git a/gdb/acinclude.m4 b/gdb/acinclude.m4
index 173e40b440..5f7589f9f6 100644
--- a/gdb/acinclude.m4
+++ b/gdb/acinclude.m4
@@ -237,7 +237,6 @@ AC_DEFUN([GDB_AC_CHECK_BFD], [
   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"
   AC_CACHE_CHECK(
     [$1],
     [$2],

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] gdb: Don't overwrite CC when checking for BFD support
  2023-04-19 18:16 [PATCH] gdb: Don't overwrite CC when checking for BFD support orbea
@ 2023-04-21 14:51 ` Tom Tromey
  2023-04-21 18:13   ` orbea
  0 siblings, 1 reply; 3+ messages in thread
From: Tom Tromey @ 2023-04-21 14:51 UTC (permalink / raw)
  To: orbea via Gdb-patches; +Cc: orbea

>>>>> orbea via Gdb-patches <gdb-patches@sourceware.org> writes:

> This can be solved by using the default value for CC instead where
> autotools is capable of providing an adequate value by default. I
> attached a patch doing this.

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.

I think for ordinary gdb builds, using libtool here is required.

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.

Anyway, I'm sorry, but I don't think this patch can go in as-is.

thanks,
Tom

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] gdb: Don't overwrite CC when checking for BFD support
  2023-04-21 14:51 ` Tom Tromey
@ 2023-04-21 18:13   ` orbea
  0 siblings, 0 replies; 3+ messages in thread
From: orbea @ 2023-04-21 18:13 UTC (permalink / raw)
  To: gdb-patches; +Cc: Tom Tromey

[-- 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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-04-21 18:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-19 18:16 [PATCH] gdb: Don't overwrite CC when checking for BFD support orbea
2023-04-21 14:51 ` Tom Tromey
2023-04-21 18:13   ` orbea

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).