Re: gdb and ancient GNU autotools
Andrew Pinski via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CA+=Sn1nJJpJhyb=VWYXF_uqMKVetkAUXqa6eB=ud8BXt=FVPXQ@mail.gmail.com> |
On Sat, Feb 24, 2024 at 8:29 AM Tomasz Kłoczko via Gdb <[email protected]> wrote: > > Hi, > > In gdb source tree in config/override.m4 is hardcoded autoconf version > > m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.64], > > That version has been released almost SIXTEEN YEARS AGO !!! > https://savannah.gnu.org/news/?id=5867 Wait what version of gdb are you using here because config/override.m4 contains dnl Ensure exactly this Autoconf version is used m4_ifndef([_GCC_AUTOCONF_VERSION], [m4_define([_GCC_AUTOCONF_VERSION], [2.69])]) Yes there is a test for a workaround of 2.64 for AVR/RTEMS which might be able to be removed though. Maybe that is what you are looking at and misreading the check there. Note gdb, binutils, and GCC all updated to 2.69 back in 2018. gdb/binutils commit d0ac1c44885daf68f631befa37e3f3bad318fbbf gcc commit r9-3776-g22e052725189a4 Yes they have not updated to 2.70 or 2.72 yet. But with a complex build system as GCC/binutils/gdb, why update to something if it is working. Thanks, Andrew Pinski > > Literally NONE Linux distribution currently provides that version so in > case of any necessity to fix something in autoconf it is NOT POSSIBLE to > regenerate GNU autotools files. > > The same situation is with binutils ang gcc. > > Someone has been thinking about start update all that stuff to be able to > use the latest GNU autotools and/or start moving to cmake or meson (IMO > mesoon is better) arch/OS one by one (still living for other not migrated > archs/OSsess autotools until last arch/OS still in use will be not migrated > or abandoned)?🤔 > > kloczek > -- > Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*