James Carlson wrote: > John Fischer writes: >> This FastTrack proposes the Integration of a more recent version >> of GNU binutils, which is compatible with Versions 4.3.x of the >> GNU Compiler Collection [ GCC ]. [2] > > Will this stuff eventually be moving to /usr/bin?
Yes. The idea is to add add symlinks to /usr/bin for GCC 4.3.2. This implies that we favor this particular version of GCC over a future one. This also implies that we need some plan for GCC4 upgrade paths, and what happens with the existing /usr/bin symlinks: do they always follow the latest version, or do they stay immutable ? There are valid arguments for either approach. Future versions of GCC might generate binaries incompatible with existing binaries generated with existing versions of GCC. On the other hand, changing symlinks every single time GCC revs up can be confusing for the developers. > It doesn't seem to need to be in /usr/gnu, as it's all g-prefixed > already, and having those functions work without path trouble would be > nice. The symlinks in /usr/bin will take care of easy discovery. They do need to be in /usr/gnu/gcc4, because these binutils are specific to/for GCC4. We don't know what happens when we integrate GCC5. "Things" might not be backwards compatible with GCC4, and we most likely want to keep the older GCC4 version around for a while. > >> /usr/gnu/bin/gobjcopy -> /usr/gnu/gcc4/bin/gobjcopy >> /usr/gnu/bin/gobjdump -> /usr/gnu/gcc4/bin/gobjdump >> /usr/gnu/bin/gprof -> /usr/gnu/gcc4/bin/gprof > > That's odd, and doesn't seem to follow PSARC 2007/047. Why would the > /usr/gnu/bin links have g-prefixes as well? Because by default some of the binaries in binutils are already prefixed with 'g', and some others aren't. I find this confusing and inconsistent, therefore i am making a ruling on the naming convention for all the executables. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
