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

["Jose E. Marchesi" <jose.marchesi@oracle.com>]

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