This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 2018-05-08 18:12, Joseph Myers wrote:
On Tue, 8 May 2018, Alan Modra wrote:I wasn't saying you must change all of binutils-gdb, let alone gcc, just that it would be nice. binutils-gdb config/* is copied from gccAnd as it's the start of development for GCC 9, it's essentially the optimal time for such a risky change in GCC.It's libtool for which an update may be the riskiest (necessary to revertlibtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c, see <https://gcc.gnu.org/ml/gcc-patches/2011-01/msg00520.html>, and need to check for any local changes relative to the last libtool version mergedfrom that aren't in the new libtool version used). I don't know whether updating other tools in GCC would require updating libtool or whether theupdates can be independent.
I attempted to convert binutils-gdb to autoconf 2.69 / automake 1.15.1 and it went reasonably well. I don't know very much about gcc, so I could try to do the same in the gcc tree blindly, but I don't feel confident enough to test and validate the changes. So I would avoid it if I can, somebody more used to building gcc could do that part.
Could we first rule whether we still need to support combined tree builds? I don't have the necessary background to judge the importance of that feature, but it would basically decide whether I can update the tools used in binutils-gdb in isolation from gcc.
Simon
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |