[PATCH V3] gdb: link executables with libtool

[PATCH V3] gdb: link executables with libtool

[Jose E. Marchesi]

[Changes from V2:
- Add .. to AC_CONFIG_MACRO_DIRS so autoreconf DTRT.
- Refer to libopcode as a libtool library.
- Do not use libtool --mode=execute in testsuite/lib/gdb.exp.
- Remove spurious entry from top-level ChangeLog.
- Remove ChangeLog fragment from commit message.
- Add git trailer to commit message.
- Typos fixed in commit message.]

This patch changes the GDB build system in order to use libtool to
link the several built executables.  This makes it possible to refer
to libtool libraries (.la files) in CLIBS.

As an application of the above,

  BFD              now refers to ../libbfd/libbfd.la
  OPCODES          now refers to ../opcodes/libopcodes.la
  LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
  LIBCTF           now refers to ../libctf/libctf.la

NOTE1: The addition of libtool adds a few new configure-time options
       to GDB.  Among these, --enable-shared and --disable-shared, which were
       previously ignored.  Now GDB shall honor these options when linking,
       picking up the right version of the referred libtool libraries
       automagically.

NOTE2: I have not tested the insight build.

NOTE3: For regenerating configure I used an environment with Autoconf
       2.69 and Automake 1.15.1.  This should match the previously
       used version as announced in the configure script.

NOTE4: Now the installed shared object libbfd.so is used by gdb
       if binutils is installed with --enable-shared.

Testing performed:

- --enable-shared and --disable-shared (the default in binutils) work
  as expected: the linked executables link with the archive or shared
  libraries transparently.

- Makefile.in modified for EXEEXT = .exe.  It installs the binaries
  just fine.  The installed gdb.exe runs fine.

- Native build regtested in x86_64. The installed gdb runs fine.

  In the regression testing I'm observing that the following tests
  doesn't seem to be deterministic:

    gdb.base/step-over-syscall.exp
    gdb.threads/process-dies-while-detaching.exp
    gdb.threads/process-dies-while-handling-bp.exp

  Sometimes some of the the tests in these files unexpectedly fail,
  like in:

  -PASS: gdb.threads/process-dies-while-detaching.exp: single-process: \
         continue: detach: continue
  +FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: \
         continue: detach: continue

  Sometimes they unexpectedly pass:

  -KFAIL: gdb.base/step-over-syscall.exp: clone: displaced=on: \
          check_pc_after_cross_syscall: single step over clone \
          final pc (PRMS: gdb/19675)
  +PASS: gdb.base/step-over-syscall.exp: clone: displaced=on: \
         check_pc_after_cross_syscall: single step over clone final pc

  -KFAIL: gdb.threads/process-dies-while-handling-bp.exp: \
          non_stop=on: cond_bp_target=0: inferior 1 exited \
          (prompt) (PRMS: gdb/18749)
  +PASS: gdb.threads/process-dies-while-handling-bp.exp: \
          non_stop=on: cond_bp_target=0: inferior 1 exited

- Cross build for aarch64-linux-gnu built to exercise
  program_transform_name and friends.  The installed
  aarch64-linux-gnu-gdb runs fine.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
---
 gdb/Makefile.in  |    14 +-
 gdb/aclocal.m4   |     5 +
 gdb/config.in    |     4 +
 gdb/configure    | 31544 ++++++++++++++++++++++++++++++---------------
 gdb/configure.ac |    17 +-
 5 files changed, 21132 insertions(+), 10452 deletions(-)

diff --git a/gdb/Makefile.in b/gdb/Makefile.in
index c528ee5aa80..522fc20bccd 100644
--- a/gdb/Makefile.in
+++ b/gdb/Makefile.in
@@ -143,10 +143,12 @@ MAKEINFO_CMD = $(MAKEINFO) $(MAKEINFOFLAGS) $(MAKEINFO_EXTRA_FLAGS)
 MAKEHTML = $(MAKEINFO_CMD) --html
 MAKEHTMLFLAGS =
 
+LIBTOOL = @LIBTOOL@
+
 # Set this up with gcc if you have gnu ld and the loader will print out
 # line numbers for undefined references.
 #CC_LD = g++ -static
-CC_LD = $(CXX) $(CXX_DIALECT)
+CC_LD = $(LIBTOOL) --mode=link $(CXX) $(CXX_DIALECT)
 
 # Where is our "include" directory?  Typically $(srcdir)/../include.
 # This is essentially the header file directory for the library
@@ -163,7 +165,7 @@ CTF_DEPS = @CTF_DEPS@
 
 # Where is the BFD library?  Typically in ../bfd.
 BFD_DIR = ../bfd
-BFD = $(BFD_DIR)/libbfd.a
+BFD = $(BFD_DIR)/libbfd.la
 BFD_SRC = $(srcdir)/$(BFD_DIR)
 BFD_CFLAGS = -I$(BFD_DIR) -I$(BFD_SRC)
 
@@ -504,7 +506,7 @@ SUBDIR_TARGET_OBS = $(patsubst %.c,%.o,$(SUBDIR_TARGET_SRCS))
 # disassemblers?
 OPCODES_DIR = ../opcodes
 OPCODES_SRC = $(srcdir)/$(OPCODES_DIR)
-OPCODES = $(OPCODES_DIR)/libopcodes.a
+OPCODES = $(OPCODES_DIR)/libopcodes.la
 # Where are the other opcode tables which only have header file
 # versions?
 OP_INCLUDE = $(INCLUDE_DIR)/opcode
@@ -2017,7 +2019,8 @@ install-only: $(CONFIG_INSTALL)
 		  true ; \
 		fi ; \
 		$(SHELL) $(srcdir)/../mkinstalldirs $(DESTDIR)$(bindir) ; \
-		$(INSTALL_PROGRAM_ENV) $(INSTALL_PROGRAM) gdb$(EXEEXT) \
+		$(LIBTOOL) --mode=install $(INSTALL_PROGRAM_ENV) $(INSTALL_PROGRAM) \
+			gdb$(EXEEXT) \
 			$(DESTDIR)$(bindir)/$$transformed_name$(EXEEXT) ; \
 		$(SHELL) $(srcdir)/../mkinstalldirs $(DESTDIR)$(includedir)/gdb ; \
 		$(INSTALL_DATA) jit-reader.h $(DESTDIR)$(includedir)/gdb/jit-reader.h
@@ -2529,7 +2532,8 @@ install-gdbtk:
 	  true ; \
 	fi ; \
 	$(SHELL) $(srcdir)/../mkinstalldirs $(DESTDIR)$(bindir); \
-	$(INSTALL_PROGRAM_ENV) $(INSTALL_PROGRAM) insight$(EXEEXT) \
+	$(LIBTOOL) --mode=install $(INSTALL_PROGRAM_ENV) $(INSTALL_PROGRAM) \
+		insight$(EXEEXT) \
 		$(DESTDIR)$(bindir)/$$transformed_name$(EXEEXT) ; \
 	$(SHELL) $(srcdir)/../mkinstalldirs \
 		$(DESTDIR)$(GDBTK_LIBRARY) ; \
diff --git a/gdb/aclocal.m4 b/gdb/aclocal.m4
index 3ed4a58d39f..4aac87b52ed 100644
--- a/gdb/aclocal.m4
+++ b/gdb/aclocal.m4
@@ -212,4 +212,9 @@ m4_include([../config/override.m4])
 m4_include([../config/pkg.m4])
 m4_include([../config/plugins.m4])
 m4_include([../config/tcl.m4])
+m4_include([../libtool.m4])
+m4_include([../ltoptions.m4])
+m4_include([../ltsugar.m4])
+m4_include([../ltversion.m4])
+m4_include([../lt~obsolete.m4])
 m4_include([acinclude.m4])
diff --git a/gdb/config.in b/gdb/config.in
index e13a409ec2d..736e6be1c48 100644
--- a/gdb/config.in
+++ b/gdb/config.in
@@ -614,6 +614,10 @@
    moved. */
 #undef JIT_READER_DIR_RELOCATABLE
 
+/* Define to the sub-directory in which libtool stores uninstalled libraries.
+   */
+#undef LT_OBJDIR
+
 /* Name of this package. */
 #undef PACKAGE
 
diff --git a/gdb/configure.ac b/gdb/configure.ac
index fceb80e8c9d..12561d4d2de 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -19,7 +19,7 @@ dnl along with this program.  If not, see <http://www.gnu.org/licenses/>.
 dnl Process this file with autoconf to produce a configure script.
 
 AC_INIT
-AC_CONFIG_MACRO_DIRS([../config])
+AC_CONFIG_MACRO_DIRS([.. ../config])
 AC_CONFIG_SRCDIR([main.c])
 AC_CONFIG_HEADERS(config.h:config.in, [echo > stamp-h])
 AM_MAINTAINER_MODE
@@ -46,6 +46,10 @@ ACX_NONCANONICAL_TARGET
 
 AC_ARG_PROGRAM
 
+# We require libtool to link with the in-tree libtool libraries
+# the proper way.
+LT_INIT
+
 # We require a C++11 compiler.  Check if one is available, and if
 # necessary, set CXX_DIALECT to some -std=xxx switch.
 AX_CXX_COMPILE_STDCXX(11, , mandatory)
@@ -2092,7 +2096,7 @@ AC_ARG_ENABLE([libbacktrace],
 
 if test "${enable_libbacktrace}" = "yes"; then
   LIBBACKTRACE_INC="-I$srcdir/../libbacktrace/ -I../libbacktrace/"
-  LIBBACKTRACE_LIB=../libbacktrace/.libs/libbacktrace.a
+  LIBBACKTRACE_LIB=../libbacktrace/libbacktrace.la
   AC_DEFINE(HAVE_LIBBACKTRACE, 1, [Define if libbacktrace is being used.])
 else
   LIBBACKTRACE_INC=
@@ -2151,15 +2155,10 @@ AC_ARG_WITH(xxhash,
   [], [with_xxhash=auto])
 
 GCC_ENABLE([libctf], [yes], [], [Handle .ctf type-info sections])
-if test x${enable_static} = xno; then
-  LIBCTF="-Wl,--rpath,../libctf/.libs ../libctf/.libs/libctf.so"
-  CTF_DEPS="../libctf/.libs/libctf.so"
-else
-  LIBCTF="../libctf/.libs/libctf.a"
-  CTF_DEPS="$LIBCTF"
-fi
 if test "${enable_libctf}" = yes; then
   AC_DEFINE(ENABLE_LIBCTF, 1, [Handle .ctf type-info sections])
+  LIBCTF="../libctf/libctf.la"
+  CTF_DEPS="../libctf/libctf.la"
 else
   LIBCTF=
   CTF_DEPS=
-- 
2.30.2

Re: [PATCH V3] gdb: link executables with libtool

[Simon Marchi]

On 11/6/22 08:10, Jose E. Marchesi via Gdb-patches wrote:
> [Changes from V2:
> - Add .. to AC_CONFIG_MACRO_DIRS so autoreconf DTRT.
> - Refer to libopcode as a libtool library.
> - Do not use libtool --mode=execute in testsuite/lib/gdb.exp.
> - Remove spurious entry from top-level ChangeLog.
> - Remove ChangeLog fragment from commit message.
> - Add git trailer to commit message.
> - Typos fixed in commit message.]
> 
> This patch changes the GDB build system in order to use libtool to
> link the several built executables.  This makes it possible to refer
> to libtool libraries (.la files) in CLIBS.
> 
> As an application of the above,
> 
>   BFD              now refers to ../libbfd/libbfd.la
>   OPCODES          now refers to ../opcodes/libopcodes.la
>   LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
>   LIBCTF           now refers to ../libctf/libctf.la
> 
> NOTE1: The addition of libtool adds a few new configure-time options
>        to GDB.  Among these, --enable-shared and --disable-shared, which were
>        previously ignored.  Now GDB shall honor these options when linking,
>        picking up the right version of the referred libtool libraries
>        automagically.
> 
> NOTE2: I have not tested the insight build.
> 
> NOTE3: For regenerating configure I used an environment with Autoconf
>        2.69 and Automake 1.15.1.  This should match the previously
>        used version as announced in the configure script.
> 
> NOTE4: Now the installed shared object libbfd.so is used by gdb
>        if binutils is installed with --enable-shared.
> 
> Testing performed:
> 
> - --enable-shared and --disable-shared (the default in binutils) work
>   as expected: the linked executables link with the archive or shared
>   libraries transparently.
> 
> - Makefile.in modified for EXEEXT = .exe.  It installs the binaries
>   just fine.  The installed gdb.exe runs fine.
> 
> - Native build regtested in x86_64. The installed gdb runs fine.
> 
>   In the regression testing I'm observing that the following tests
>   doesn't seem to be deterministic:
> 
>     gdb.base/step-over-syscall.exp
>     gdb.threads/process-dies-while-detaching.exp
>     gdb.threads/process-dies-while-handling-bp.exp
> 
>   Sometimes some of the the tests in these files unexpectedly fail,
>   like in:
> 
>   -PASS: gdb.threads/process-dies-while-detaching.exp: single-process: \
>          continue: detach: continue
>   +FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: \
>          continue: detach: continue
> 
>   Sometimes they unexpectedly pass:
> 
>   -KFAIL: gdb.base/step-over-syscall.exp: clone: displaced=on: \
>           check_pc_after_cross_syscall: single step over clone \
>           final pc (PRMS: gdb/19675)
>   +PASS: gdb.base/step-over-syscall.exp: clone: displaced=on: \
>          check_pc_after_cross_syscall: single step over clone final pc
> 
>   -KFAIL: gdb.threads/process-dies-while-handling-bp.exp: \
>           non_stop=on: cond_bp_target=0: inferior 1 exited \
>           (prompt) (PRMS: gdb/18749)
>   +PASS: gdb.threads/process-dies-while-handling-bp.exp: \
>           non_stop=on: cond_bp_target=0: inferior 1 exited
> 
> - Cross build for aarch64-linux-gnu built to exercise
>   program_transform_name and friends.  The installed
>   aarch64-linux-gnu-gdb runs fine.
> 
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
> ---
>  gdb/Makefile.in  |    14 +-
>  gdb/aclocal.m4   |     5 +
>  gdb/config.in    |     4 +
>  gdb/configure    | 31544 ++++++++++++++++++++++++++++++---------------
>  gdb/configure.ac |    17 +-

This diffstat claims there are changes to configure, but the patch
doesn't actually has them.  Perhaps it's on purpose, because they are a
bit on the big side to send by email.  I'd just like to double-check
that when I run autoreconf on my side, I get the same result as you.
Could you perhaps upload your patch to a git branch?  It could be a user
branch here in the sourceware binutils-gdb repo.

Simon

Re: [PATCH V3] gdb: link executables with libtool

[Jose E. Marchesi]

> On 11/6/22 08:10, Jose E. Marchesi via Gdb-patches wrote:
>> [Changes from V2:
>> - Add .. to AC_CONFIG_MACRO_DIRS so autoreconf DTRT.
>> - Refer to libopcode as a libtool library.
>> - Do not use libtool --mode=execute in testsuite/lib/gdb.exp.
>> - Remove spurious entry from top-level ChangeLog.
>> - Remove ChangeLog fragment from commit message.
>> - Add git trailer to commit message.
>> - Typos fixed in commit message.]
>> 
>> This patch changes the GDB build system in order to use libtool to
>> link the several built executables.  This makes it possible to refer
>> to libtool libraries (.la files) in CLIBS.
>> 
>> As an application of the above,
>> 
>>   BFD              now refers to ../libbfd/libbfd.la
>>   OPCODES          now refers to ../opcodes/libopcodes.la
>>   LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
>>   LIBCTF           now refers to ../libctf/libctf.la
>> 
>> NOTE1: The addition of libtool adds a few new configure-time options
>>        to GDB.  Among these, --enable-shared and --disable-shared, which were
>>        previously ignored.  Now GDB shall honor these options when linking,
>>        picking up the right version of the referred libtool libraries
>>        automagically.
>> 
>> NOTE2: I have not tested the insight build.
>> 
>> NOTE3: For regenerating configure I used an environment with Autoconf
>>        2.69 and Automake 1.15.1.  This should match the previously
>>        used version as announced in the configure script.
>> 
>> NOTE4: Now the installed shared object libbfd.so is used by gdb
>>        if binutils is installed with --enable-shared.
>> 
>> Testing performed:
>> 
>> - --enable-shared and --disable-shared (the default in binutils) work
>>   as expected: the linked executables link with the archive or shared
>>   libraries transparently.
>> 
>> - Makefile.in modified for EXEEXT = .exe.  It installs the binaries
>>   just fine.  The installed gdb.exe runs fine.
>> 
>> - Native build regtested in x86_64. The installed gdb runs fine.
>> 
>>   In the regression testing I'm observing that the following tests
>>   doesn't seem to be deterministic:
>> 
>>     gdb.base/step-over-syscall.exp
>>     gdb.threads/process-dies-while-detaching.exp
>>     gdb.threads/process-dies-while-handling-bp.exp
>> 
>>   Sometimes some of the the tests in these files unexpectedly fail,
>>   like in:
>> 
>>   -PASS: gdb.threads/process-dies-while-detaching.exp: single-process: \
>>          continue: detach: continue
>>   +FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: \
>>          continue: detach: continue
>> 
>>   Sometimes they unexpectedly pass:
>> 
>>   -KFAIL: gdb.base/step-over-syscall.exp: clone: displaced=on: \
>>           check_pc_after_cross_syscall: single step over clone \
>>           final pc (PRMS: gdb/19675)
>>   +PASS: gdb.base/step-over-syscall.exp: clone: displaced=on: \
>>          check_pc_after_cross_syscall: single step over clone final pc
>> 
>>   -KFAIL: gdb.threads/process-dies-while-handling-bp.exp: \
>>           non_stop=on: cond_bp_target=0: inferior 1 exited \
>>           (prompt) (PRMS: gdb/18749)
>>   +PASS: gdb.threads/process-dies-while-handling-bp.exp: \
>>           non_stop=on: cond_bp_target=0: inferior 1 exited
>> 
>> - Cross build for aarch64-linux-gnu built to exercise
>>   program_transform_name and friends.  The installed
>>   aarch64-linux-gnu-gdb runs fine.
>> 
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
>> ---
>>  gdb/Makefile.in  |    14 +-
>>  gdb/aclocal.m4   |     5 +
>>  gdb/config.in    |     4 +
>>  gdb/configure    | 31544 ++++++++++++++++++++++++++++++---------------
>>  gdb/configure.ac |    17 +-
>
> This diffstat claims there are changes to configure, but the patch
> doesn't actually has them.  Perhaps it's on purpose, because they are a
> bit on the big side to send by email.  I'd just like to double-check
> that when I run autoreconf on my side, I get the same result as you.
> Could you perhaps upload your patch to a git branch?  It could be a user
> branch here in the sourceware binutils-gdb repo.

Yeah I removed the configure thunk because it is big.
Just pushed the stuff to a branch users/jemarch/gdb-libtool.

Re: [PATCH V3] gdb: link executables with libtool

[Simon Marchi]

On 11/7/22 09:14, Jose E. Marchesi wrote:
> 
>> On 11/6/22 08:10, Jose E. Marchesi via Gdb-patches wrote:
>>> [Changes from V2:
>>> - Add .. to AC_CONFIG_MACRO_DIRS so autoreconf DTRT.
>>> - Refer to libopcode as a libtool library.
>>> - Do not use libtool --mode=execute in testsuite/lib/gdb.exp.
>>> - Remove spurious entry from top-level ChangeLog.
>>> - Remove ChangeLog fragment from commit message.
>>> - Add git trailer to commit message.
>>> - Typos fixed in commit message.]
>>>
>>> This patch changes the GDB build system in order to use libtool to
>>> link the several built executables.  This makes it possible to refer
>>> to libtool libraries (.la files) in CLIBS.
>>>
>>> As an application of the above,
>>>
>>>   BFD              now refers to ../libbfd/libbfd.la
>>>   OPCODES          now refers to ../opcodes/libopcodes.la
>>>   LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
>>>   LIBCTF           now refers to ../libctf/libctf.la
>>>
>>> NOTE1: The addition of libtool adds a few new configure-time options
>>>        to GDB.  Among these, --enable-shared and --disable-shared, which were
>>>        previously ignored.  Now GDB shall honor these options when linking,
>>>        picking up the right version of the referred libtool libraries
>>>        automagically.
>>>
>>> NOTE2: I have not tested the insight build.
>>>
>>> NOTE3: For regenerating configure I used an environment with Autoconf
>>>        2.69 and Automake 1.15.1.  This should match the previously
>>>        used version as announced in the configure script.
>>>
>>> NOTE4: Now the installed shared object libbfd.so is used by gdb
>>>        if binutils is installed with --enable-shared.
>>>
>>> Testing performed:
>>>
>>> - --enable-shared and --disable-shared (the default in binutils) work
>>>   as expected: the linked executables link with the archive or shared
>>>   libraries transparently.
>>>
>>> - Makefile.in modified for EXEEXT = .exe.  It installs the binaries
>>>   just fine.  The installed gdb.exe runs fine.
>>>
>>> - Native build regtested in x86_64. The installed gdb runs fine.
>>>
>>>   In the regression testing I'm observing that the following tests
>>>   doesn't seem to be deterministic:
>>>
>>>     gdb.base/step-over-syscall.exp
>>>     gdb.threads/process-dies-while-detaching.exp
>>>     gdb.threads/process-dies-while-handling-bp.exp
>>>
>>>   Sometimes some of the the tests in these files unexpectedly fail,
>>>   like in:
>>>
>>>   -PASS: gdb.threads/process-dies-while-detaching.exp: single-process: \
>>>          continue: detach: continue
>>>   +FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: \
>>>          continue: detach: continue
>>>
>>>   Sometimes they unexpectedly pass:
>>>
>>>   -KFAIL: gdb.base/step-over-syscall.exp: clone: displaced=on: \
>>>           check_pc_after_cross_syscall: single step over clone \
>>>           final pc (PRMS: gdb/19675)
>>>   +PASS: gdb.base/step-over-syscall.exp: clone: displaced=on: \
>>>          check_pc_after_cross_syscall: single step over clone final pc
>>>
>>>   -KFAIL: gdb.threads/process-dies-while-handling-bp.exp: \
>>>           non_stop=on: cond_bp_target=0: inferior 1 exited \
>>>           (prompt) (PRMS: gdb/18749)
>>>   +PASS: gdb.threads/process-dies-while-handling-bp.exp: \
>>>           non_stop=on: cond_bp_target=0: inferior 1 exited
>>>
>>> - Cross build for aarch64-linux-gnu built to exercise
>>>   program_transform_name and friends.  The installed
>>>   aarch64-linux-gnu-gdb runs fine.
>>>
>>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
>>> ---
>>>  gdb/Makefile.in  |    14 +-
>>>  gdb/aclocal.m4   |     5 +
>>>  gdb/config.in    |     4 +
>>>  gdb/configure    | 31544 ++++++++++++++++++++++++++++++---------------
>>>  gdb/configure.ac |    17 +-
>>
>> This diffstat claims there are changes to configure, but the patch
>> doesn't actually has them.  Perhaps it's on purpose, because they are a
>> bit on the big side to send by email.  I'd just like to double-check
>> that when I run autoreconf on my side, I get the same result as you.
>> Could you perhaps upload your patch to a git branch?  It could be a user
>> branch here in the sourceware binutils-gdb repo.
> 
> Yeah I removed the configure thunk because it is big.
> Just pushed the stuff to a branch users/jemarch/gdb-libtool.

Thanks, this works for me, I think you can go ahead and push this.
Please add the following trailer to the commit:

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Simon

Re: [PATCH V3] gdb: link executables with libtool

[Jose E. Marchesi]

> On 11/7/22 09:14, Jose E. Marchesi wrote:
>> 
>>> On 11/6/22 08:10, Jose E. Marchesi via Gdb-patches wrote:
>>>> [Changes from V2:
>>>> - Add .. to AC_CONFIG_MACRO_DIRS so autoreconf DTRT.
>>>> - Refer to libopcode as a libtool library.
>>>> - Do not use libtool --mode=execute in testsuite/lib/gdb.exp.
>>>> - Remove spurious entry from top-level ChangeLog.
>>>> - Remove ChangeLog fragment from commit message.
>>>> - Add git trailer to commit message.
>>>> - Typos fixed in commit message.]
>>>>
>>>> This patch changes the GDB build system in order to use libtool to
>>>> link the several built executables.  This makes it possible to refer
>>>> to libtool libraries (.la files) in CLIBS.
>>>>
>>>> As an application of the above,
>>>>
>>>>   BFD              now refers to ../libbfd/libbfd.la
>>>>   OPCODES          now refers to ../opcodes/libopcodes.la
>>>>   LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
>>>>   LIBCTF           now refers to ../libctf/libctf.la
>>>>
>>>> NOTE1: The addition of libtool adds a few new configure-time options
>>>>        to GDB.  Among these, --enable-shared and --disable-shared, which were
>>>>        previously ignored.  Now GDB shall honor these options when linking,
>>>>        picking up the right version of the referred libtool libraries
>>>>        automagically.
>>>>
>>>> NOTE2: I have not tested the insight build.
>>>>
>>>> NOTE3: For regenerating configure I used an environment with Autoconf
>>>>        2.69 and Automake 1.15.1.  This should match the previously
>>>>        used version as announced in the configure script.
>>>>
>>>> NOTE4: Now the installed shared object libbfd.so is used by gdb
>>>>        if binutils is installed with --enable-shared.
>>>>
>>>> Testing performed:
>>>>
>>>> - --enable-shared and --disable-shared (the default in binutils) work
>>>>   as expected: the linked executables link with the archive or shared
>>>>   libraries transparently.
>>>>
>>>> - Makefile.in modified for EXEEXT = .exe.  It installs the binaries
>>>>   just fine.  The installed gdb.exe runs fine.
>>>>
>>>> - Native build regtested in x86_64. The installed gdb runs fine.
>>>>
>>>>   In the regression testing I'm observing that the following tests
>>>>   doesn't seem to be deterministic:
>>>>
>>>>     gdb.base/step-over-syscall.exp
>>>>     gdb.threads/process-dies-while-detaching.exp
>>>>     gdb.threads/process-dies-while-handling-bp.exp
>>>>
>>>>   Sometimes some of the the tests in these files unexpectedly fail,
>>>>   like in:
>>>>
>>>>   -PASS: gdb.threads/process-dies-while-detaching.exp: single-process: \
>>>>          continue: detach: continue
>>>>   +FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: \
>>>>          continue: detach: continue
>>>>
>>>>   Sometimes they unexpectedly pass:
>>>>
>>>>   -KFAIL: gdb.base/step-over-syscall.exp: clone: displaced=on: \
>>>>           check_pc_after_cross_syscall: single step over clone \
>>>>           final pc (PRMS: gdb/19675)
>>>>   +PASS: gdb.base/step-over-syscall.exp: clone: displaced=on: \
>>>>          check_pc_after_cross_syscall: single step over clone final pc
>>>>
>>>>   -KFAIL: gdb.threads/process-dies-while-handling-bp.exp: \
>>>>           non_stop=on: cond_bp_target=0: inferior 1 exited \
>>>>           (prompt) (PRMS: gdb/18749)
>>>>   +PASS: gdb.threads/process-dies-while-handling-bp.exp: \
>>>>           non_stop=on: cond_bp_target=0: inferior 1 exited
>>>>
>>>> - Cross build for aarch64-linux-gnu built to exercise
>>>>   program_transform_name and friends.  The installed
>>>>   aarch64-linux-gnu-gdb runs fine.
>>>>
>>>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
>>>> ---
>>>>  gdb/Makefile.in  |    14 +-
>>>>  gdb/aclocal.m4   |     5 +
>>>>  gdb/config.in    |     4 +
>>>>  gdb/configure    | 31544 ++++++++++++++++++++++++++++++---------------
>>>>  gdb/configure.ac |    17 +-
>>>
>>> This diffstat claims there are changes to configure, but the patch
>>> doesn't actually has them.  Perhaps it's on purpose, because they are a
>>> bit on the big side to send by email.  I'd just like to double-check
>>> that when I run autoreconf on my side, I get the same result as you.
>>> Could you perhaps upload your patch to a git branch?  It could be a user
>>> branch here in the sourceware binutils-gdb repo.
>> 
>> Yeah I removed the configure thunk because it is big.
>> Just pushed the stuff to a branch users/jemarch/gdb-libtool.
>
> Thanks, this works for me, I think you can go ahead and push this.
> Please add the following trailer to the commit:
>
> Approved-By: Simon Marchi <simon.marchi@efficios.com>

Branch rebased to latest master, trailer expanded with the Approved-By
and, sanity-checked and pushed to master.

I will be on the look for possible breakages.
Thanks!