Re: gdb and ancient GNU autotools

[Sam James via Gdb <gdb@sourceware.org>]

Tomasz Kłoczko <kloczko.tomasz@gmail.com> writes:

[resending, sorry, my mail client recently changed bindings.]

> 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

No, the situation with the GNU toolchain's libtool version/soft fork vs
the upstream one is more complicated.

There's some patches which never got submitted upstream, some which need
to be reconciled with upstream changes, some where we really need to
figure out why they were done in the first place, etc.

(Joseph already identified one such deliberate divergence: --with-sysroot.)

It's not as simple as "GNU libtool is unmaintained". In fact, it's got
(another) new maintainer as of last month or so, and a lot of activity
upstream since then. But that's separate to the issue of the libtool
used within the GNU toolchain, although kind of related (active
maintainers might help motivate updating it and sorting through the local changes).


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

Toolchain packages are generally special.

Can you please reconsider your tone? It comes across aggressive to me.

> 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™️)