gdb and ancient GNU autotools

[Tomasz Kłoczko]

On Tue, 27 Feb 2024 at 17:33, Joseph Myers <josmyers@redhat.com> wrote:
[..]

> A reminder: mixing a libtool update into an autoconf/automake update would
> be a bad idea, a libtool update is likely a lot harder, since (a) the
> libtool version used is very old (reportedly based on upstream commit
> 2c9c38d8a12eb0a2ce7fe9c3862523026c3d5622); (b) there are many local
> patches, probably including some that are not present upstream; (c)
> libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c will need
> reverting because of usage of --with-sysroot incompatible with how the
> toolchain uses that option.
>
> I did the last autoconf/automake update in GCC, but that was building very
> heavily on your work on that update for binutils-gdb and would have been a
> lot harder without your work to update the shared files and show the way
> for the sort of changes to make to GCC-specific files.
>

In other words you are 100% AWARE that OOTB libtool *is in dead state*
because it has been abandoned by maintainer(s), and no one wants to
continue that work by forking it from current master (adding fixes ->
release new versions etc), and at the same time gdb maintainer(s) (and
probably gcc and binutils as well) definitely want to stick with GNU
autotools.
You cannot *eat cake and still have it on the plate* ..

Just FTR a few metrics from my +4.83k packages spec files (Fedora IIRC has
now ~21k, Debian 30k .. ish)

[tkloczko@pers-jacek SPECS]$ for i in meson libtool autoconf automake
cmake; do echo "$i = $(grep -c BuildRequires:.$i -l *spec |wc -l)"; done
meson = 436
libtool = 844
autoconf = 68
automake = 1040
cmake = 634

Even if my 4.8k package population produces values which are not
100% accurate, these metrics will be probably only +/- 2-3% different on
sampling them on a bigger population.

In above metrics if something requires automake it uses autoconf as well,
and as you can see:
- The number of people who/projects which abandoned/not choose GNU autoconf
is greater than cmake + meson (634+436 = 1070).
- The number of those which are using libtool (844) is already LOWER than
meson+cmake by ~20%.
- Metric of the meson+cmake is almost as big as the set in which it is used
by autoconf and/or automake (1040+68=1108).

*If no one will try to continue libtool maintenance* atractor anchored in
libtool will be changing those metrics with time in ONLY ONE DIRECTION
which will be ONLY more and more affecting gcc, binutils, gdb trio.

PURE LOGIC says that in this situation you guys (maintainers) have probably
ONLY two solutions/choices:
- someone will take over libtool to recover it from the current coma, and
rescue in longer term gcc, binutils, gdb trio as well.
- you can move to cmake or meson.
Above two possibilities are HARD LOGICAL CONCLUSIONS taken straight from
results of those metrics with which (conclusions) you may not agree but
existence of it is completely independent of what you can add more as
comment (and anyone here as persons with EnoughGood exp in context of build
automation).

As I wrote I can try to help in both possible scenarios but first someone
needs to MAKE THE DECISION about taking over libtool or about starting to
move towards cmake or meson.
I'm 100% sure that many other people may and WILL help with
above (necessary) changes BUT as long as libtool is unmaintained, investing
anyone's time is HIGHLY RISKY that time will be wasted.
In other words in the current state probably that you will stay ALONE and
no one will be trying to help you -> time which you already spend on
maintaining gcc, gdb binutils trion will be more or less kind of LOST .. is
only GROWING with every day of lack of that STRATEGIC decision.

I'm the only messenger .. please don't kill the messenger.

kloczek
PS. I found my ncurses and gdb issue solution but because it is JFDIN I'm
not going to publish it.
In other words my issue has now a solution (which I'm not happy/proud of
what I've done but ItWorks™️)
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH