Re: [PATCH] gdb: link executables with libtool

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

> On 11/5/22 10:30, Jose E. Marchesi via Gdb-patches wrote:
>> 
>>>> Date: Sat,  5 Nov 2022 14:08:27 +0100
>>>> From: "Jose E. Marchesi via Gdb-patches" <gdb-patches@sourceware.org>
>>>> Cc: indu.bhagat@oracle.com, elena.zannoni@oracle.com
>>>>
>>>> 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.
>>>
>>> If this is supposed to be installed before we start the release cycle
>>> of GDB 13, I question the wisdom of making such a significant change
>>> when we are so close to the next release.
>>>
>>> Does this solve some grave problems, or can we wait until after GDB
>>> 13?
>> 
>> Basically it would unstuck us in getting the SFrame integration applied
>> in binutils.
>> 
>> See
>> https://sourceware.org/pipermail/gdb-patches/2022-November/193381.html
>> 
>> We could go with the simpler solution suggested in that email (already
>> used by libbacktrace and libctf) in GDB 13 and then we can apply the new
>> patch to switch to libtool for linking.
>> 
>> I know Mike doesn't like the idea; but I hope we have proved we do our
>> homework?
>
> IIUC, it would not be useful to have the libtool changes without the
> SFrame changes.  And given that the GDB 13 branch is supposed to be cut
> very shortly, do we expect to have the SFrame changes in GDB 13 (I have
> no idea what that consists of)?  If not, then the libtool changes are
> not really needed in GDB 13.

The SFrame support (it is a frame unwinding format) is purely in
binutils (assembler, and linker via BFD) and, per-se, it doesn't concern
GDB at all.

The issue is that given the current way GDB links with BFD (directly
with the ../bfd/libbfd.a archive) it becomes necessary to also
explicitly list libbfd's dependencies in the GDB build system.  In the
binutils SFrame patch we are introducing a libsframe in binutils, and
make libbfd link with it.  Having to satify these kind of indirect
dependencies for in-tree libraries in the GDB build system is generally
not a good idea, and therefore Mike's suggestion on making GDB use
libtool for linking and the patch I sent.

The patch also eliminates GDB's reliance on libtool internal paths like
.libs/foo.so (alghough doing that it is something not unheard of ^^.)

When is GDB 13 expected to be branched?