From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ODXDKVFN3mXDjy8AWB0awg (envelope-from ) for ; Tue, 27 Feb 2024 16:00:01 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=xd56yHn7; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A51991E0D2; Tue, 27 Feb 2024 16:00:01 -0500 (EST) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 93A401E030 for ; Tue, 27 Feb 2024 15:59:59 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AF400385840D for ; Tue, 27 Feb 2024 20:59:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AF400385840D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1709067598; bh=EdHNdMNdp0K25YZXUOhxU7n94mNBSAtwJk3jHM+qv68=; h=To:Cc:Subject:In-Reply-To:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=xd56yHn7BTTIRRFKT7hSa+W+tg//0aV5EJOZhv2oAzxUh0XY0kqcHg4fD49wl1Gzj kcTmxi6pt4yUkeaY7uUuV9ZZh30M63P89NhQ7p+VxOPLIbzxc8wVN+nNFaEZ0KYEGj Cbgx4izcxYTMoXdPfqzwM0JQHE48tZloGAI/DMHQ= Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 2871F3858C24 for ; Tue, 27 Feb 2024 20:59:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2871F3858C24 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2871F3858C24 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709067554; cv=none; b=XVT6PnbH/je8mdGaMEntaeeUid6yZKWf5gW8Qhr5sUyYzHxS+aLylHKQcgjI9/WoFMBIiXhlHmbF5zzYX66jwX/772udgIQ+DBKIG+IyPbF+58adRZUExcEdXxsXVInD4vBph256u9MoSaroEeSPeRVsIBFVgydu69t0hvGYACQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709067554; c=relaxed/simple; bh=lDcgptCUMnf9g005lNgj8ZF5NJx4WfoZG13o6brOTDQ=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=SqOX2R1vmvJYFV9IwGjtZhCOaz0wGLnXqhRGOwuh8E4BBxbIexZXFk+6h9KBTo7ol0iQoCHBDZTZKPvHt0lEJKjpaXB+TZNUQhjDO1HFn1cXXBVJZBO1owfD4qBU1SKIXUpWqFvcguiNQktZxW5ccPh7TNoI2dnJnB4RrQfl3bc= ARC-Authentication-Results: i=1; server2.sourceware.org To: Tomasz =?utf-8?Q?K=C5=82oczko?= Cc: Joseph Myers , Simon Marchi , gdb@sourceware.org Subject: Re: gdb and ancient GNU autotools In-Reply-To: ("Tomasz =?utf-8?Q?K=C5=82oczko=22's?= message of "Tue, 27 Feb 2024 20:44:23 +0000") Organization: Gentoo References: <87v86d6byg.fsf@gentoo.org> <87o7c56ale.fsf@gentoo.org> <892bee4f-5d11-4e5b-b3d4-3f079f7bee43@simark.ca> User-Agent: mu4e 1.12.0; emacs 30.0.50 Date: Tue, 27 Feb 2024 20:59:05 +0000 Message-ID: <87o7c162ue.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sam James via Gdb Reply-To: Sam James Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" Tomasz K=C5=82oczko writes: [resending, sorry, my mail client recently changed bindings.] > On Tue, 27 Feb 2024 at 17:33, Joseph Myers wrote: > [..] > > A reminder: mixing a libtool update into an autoconf/automake update wou= ld=20 > be a bad idea, a libtool update is likely a lot harder, since (a) the=20 > libtool version used is very old (reportedly based on upstream commit=20 > 2c9c38d8a12eb0a2ce7fe9c3862523026c3d5622); (b) there are many local=20 > patches, probably including some that are not present upstream; (c)=20 > libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c will need=20 > reverting because of usage of --with-sysroot incompatible with how the=20 > toolchain uses that option. > > I did the last autoconf/automake update in GCC, but that was building ve= ry=20 > heavily on your work on that update for binutils-gdb and would have been= a=20 > lot harder without your work to update the shared files and show the way= =20 > 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 beca= use it has been abandoned by maintainer(s), and > no one wants to continue that work by forking it from current master (add= ing 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 c= hanges). > the same time gdb maintainer(s) (and probably gcc and binutils as well) d= efinitely 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 ha= s now ~21k, Debian 30k .. ish) > > [tkloczko@pers-jacek SPECS]$ for i in meson libtool autoconf automake cma= ke; do echo "$i =3D $(grep -c BuildRequires:.$i -l > *spec |wc -l)"; done > meson =3D 436 > libtool =3D 844 > autoconf =3D 68 > automake =3D 1040 > cmake =3D 634 > > Even if my 4.8k package population produces values which are not 100% acc= urate, 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 autoco= nf is greater than cmake + meson (634+436 =3D > 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 us= ed by autoconf and/or automake (1040+68=3D1108). > > If no one will try to continue libtool maintenance atractor anchored in l= ibtool will be changing those metrics with time > in ONLY ONE DIRECTION which will be ONLY more and more affecting gcc, bin= utils, gdb trio. > > PURE LOGIC says that in this situation you guys (maintainers) have probab= ly 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 indepen= dent 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 (necess= ary) changes BUT as long as libtool is > unmaintained, investing anyone's time is HIGHLY RISKY that time will be w= asted. > 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=E2=84=A2=EF=B8=8F)