Re: gdb and ancient GNU autotools
Tomasz Kłoczko via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CABB28CwhHkHXAbV3zRpLvegmqPRoG9iftU5R-xPa+M+1ex5yUA@mail.gmail.com> |
On Sun, 25 Feb 2024 at 23:32, Mark Wielaard <[email protected]> wrote: > > Offlist you said that you didn't really got throttled because of those > 8 packages you have that are hosted on sourceware none of them need > many patches in the first place. So it isn't clear to me if we are > actually discussing a real issue or if you are just worried that you > could have an issue in theory. > So .. more than a decade of not updating gdb build automation to be able use it with latest GNU autotools tooling is NOT THE REAL ISSUE?🤔 Really? And .. sincerely thank you for your "argumentum ad hominem". I found that gdb autoconf has some issue with ncurses detection when ncurses source code is configured before compiling in some exact way. I'm able to fix that but *I'm not able to test the result of that fix* (before possible sending PR) because *I'm not able to regenerate all gdb build automation .. because for more than decade that gdb automation update has been postponed by any cost*. Yes, ncurses code has changed in the last decade and now provides for example full UTF-8 wide characters support. In the last 3-4 years it offers as well a simpler source code setup which so far is not widely used in any leading Linux distro. Indirectly I've offered my help with updating that build automation as I'm dealing with ac/am/lt *almost 30 years*. Issue is that so far I don't see any WILL to work on that .. as it is not a task for a single person and working on that alone would be WASTE OF TIME. I have access only to Linux/x86_64 and Solari/OpenSolaris x86 and gdb ac/am/lt automation needs to be correctly working on many asch and operating systems. Are you able to help me with ABOVE issue?🤔 kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH