From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sCbHAvtJ3mW0iy8AWB0awg (envelope-from ) for ; Tue, 27 Feb 2024 15:45:47 -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=nDYAKCzb; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 0794C1E0D2; Tue, 27 Feb 2024 15:45:47 -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 EC31B1E030 for ; Tue, 27 Feb 2024 15:45:44 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4D3D43858C74 for ; Tue, 27 Feb 2024 20:45:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4D3D43858C74 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1709066744; bh=jVhIFYui3nCuyWG88FJKfnwUngIzq7+bfnuWMUoG9fU=; h=References:In-Reply-To:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=nDYAKCzb5/Wa9QoxBN3TkcOB3jx1U8vFwhyv3j4oQzu9M5mfeh9wELt0V0S6BAmR9 dV9J3sf6+Kwzg3EevLh5oZNzEHG0B05DH21lDz1WRY+fN4hp/WUHPi5lN93NSWYUe0 ILPMPz3EZG/6nS7MyeZmaCAnzd8uX7IY4EYwPUVY= Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) by sourceware.org (Postfix) with ESMTPS id 9AF493858D33 for ; Tue, 27 Feb 2024 20:45:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9AF493858D33 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9AF493858D33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709066703; cv=none; b=mJERFkhJx+KztAOvvAZe+5btXmXJ/2s+cgZNp4aZGrj0FFWMf5hlJHtyRZu05KP7zTpbiDznsEL+pofI0wux1wWogynTBswKG85S2miudMAWVjtnHLCkY+aNWktSYlcD+qLVo5eMcjbntNrz45QDVzw1JUf2iFrzHxff3/JQJqo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709066703; c=relaxed/simple; bh=OuQ8aFJhL+xelDC+haar2sZCcZ25jmbV6lmf9i2I2Q4=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=GPHqIImvlsWObZdpDoN/UTUtgQhJR5lnjGGMIcETVwjWUG4xn8Y2aYRLYoFuNxTMNoZ3/1+qfxgwMBF24gZ47ZBi3WoMvXniY0htU7SNzq9wkSnYDSIQerWv/P9nDsSU33rfceFBJQp9yGCPOQEO3FoglqfSL0yI0UljLQn6BcM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-il1-x132.google.com with SMTP id e9e14a558f8ab-364f794f237so22525785ab.1 for ; Tue, 27 Feb 2024 12:45:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709066700; x=1709671500; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OuQ8aFJhL+xelDC+haar2sZCcZ25jmbV6lmf9i2I2Q4=; b=XW4pqSMZeSpD5tvhYrrA6XPJjL8XCRpMC526Yl2mEu9wjczAshXhO92l0GdR0YP6d4 YUHoDHAZcl9UvmzKEDftc1h9iS+lUypMwgNtBTIDY3TVYep8rcLat3awtGxYNodTMNZe qIngTFUSB2NxrYnDwM98PH1GHNnSMD2SH7+Wcj/qsNIp1bZsMS4LqDb/OY/FwnLxn75R hcoSTfnYRT8TSIDoS9DSarzYnJtISatnfpjDuRsB7vYRTtWyu1qiYLi0AD8PocgaW8P7 0KbspMTM6OrDzNFcfVGRPXVS5Au0vGJwU5bLpUHZfH/CDXr7qfPUk9koJrHnt9jNiKuj M5ig== X-Forwarded-Encrypted: i=1; AJvYcCUm5O9ADkQklMo93aecFo9unnH1QRxNaX0iPd80Op5TtugzI34hsDsBLHABdg6o+g9me94gZscKCe9gI06dFNCVpoM= X-Gm-Message-State: AOJu0Yz+Isxove9tOhlY+nb3x6CHtrfPyAwly9FVl6qCnIEukUwjopFx VdFlC29Pm1DKN49mkCeeLZUPP+BBeSK8A1KIRvaIzWJ77FaURGLG6AZqUBcH8xqE9LhCXRbnH8/ gOINsXk3a7SerhRU75LZDDTeN8Uo= X-Google-Smtp-Source: AGHT+IFAeuqgyDKmPvRbo6/50jnqkTJGwJnoU2+qdpta99dCuTY/IWHbGe5fpvyNleOjIVvAEF8kZTovNsSuGNLDu9c= X-Received: by 2002:a05:6e02:1d86:b0:363:bdb9:72af with SMTP id h6-20020a056e021d8600b00363bdb972afmr15441496ila.23.1709066699663; Tue, 27 Feb 2024 12:44:59 -0800 (PST) MIME-Version: 1.0 References: <87v86d6byg.fsf@gentoo.org> <87o7c56ale.fsf@gentoo.org> <892bee4f-5d11-4e5b-b3d4-3f079f7bee43@simark.ca> In-Reply-To: Date: Tue, 27 Feb 2024 20:44:23 +0000 Message-ID: Subject: Re: gdb and ancient GNU autotools To: Joseph Myers Cc: Simon Marchi , Sam James , gdb@sourceware.org X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_KAM_HTML_FONT_INVALID, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.30 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: =?utf-8?q?Tomasz_K=C5=82oczko_via_Gdb?= Reply-To: =?UTF-8?Q?Tomasz_K=C5=82oczko?= Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On Tue, 27 Feb 2024 at 17:33, Joseph Myers wrote: [..] > A reminder: mixing a libtool update into an autoconf/automake update woul= d > 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 ver= y > 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 =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% 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 =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 used by autoconf and/or automake (1040+68=3D1108). *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=E2=84=A2=EF=B8=8F) --=20 Tomasz K=C5=82oczko | LinkedIn: http://lnkd.in/FXPWxH