[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