Danek Duvall wrote: > On Thu, Oct 23, 2008 at 09:36:49PM -0400, Stefan Teleman wrote: > >>> I thought binutils was generally pretty good about backwards >>> compatibility -- that you could always have the latest version on your >>> system and have it work with the old compilers. Is that not actually >>> the case, or is known not to be the case in the future? >> We don't know what will happen in the future. I am much less concerned >> about the binary utilities like objdump or objcopy, but I am concerned >> about future compatibility of the GNU assembler, which is currently >> required to build any bits on i386. > > So a) why put all this stuff under gcc4, making it look like you're worried > about compatibility across gcc versions
Because i am concerned about binutils compatibility across gcc versions. b) why not single out gas, and/or > c) why not just make sure that before pulling in a new version of binutils, > the new gas is capable of being the assembler for the portions of the OS > build that require it? Because: d) GCC5 might require a new and as-of-yet unwritten version of gas which is not compatible with GCC4 e) i am not concerned about maintaining compatibility of binutils within a GCC4 release. i am, however, concerned about compatibility when we introduce GCC5, and we have to maintain both GCC4 and GCC5, at least for a while. Hence the implication for a /usr/gnu/gcc5 directory tree, when that becomes necessary. f) i would like to keep everything as simple as possible. Creating build time dependencies of the "objdump and objcopy come from binutils 2.17 but gas comes from binutils 2.21 and readelf from binutils 2.23 because these are the only versions which works with two different GCC's" kind, is not, in my mind, simple. The approach currently proposed here is for every Major Version of GCC to have its own set of binutils, known to work with that particular major version. Retirement of one Major Version of GCC also implies retirement of its corresponding binutils collection. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
