Stefan Teleman writes: > > 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.
Are those symlinks part of this project or part of some other project? I'm a bit confused about what's going on here. On a Nevada 101 system, I see no /usr/bin/gas on the system at all, though it does have SUNWbinutils installed, and I can see /usr/sfw/bin/gas. On an OpenSolaris 0.99 system, I see a /usr/bin/gas symlink coming from SUNWbinutils that points over to /usr/sfw. What the ... ? > 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 ? Following newest installed makes the most sense to me. > 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. When we create the /usr/bin symlinks (and it's unclear to me whether we have done this yet or not!), I think we should try to be as consistent with other platforms as possible, even if the historical name used in /usr/sfw/bin (and thus the symlink left behind there) may have been different. That's all I'm asking. I can understand 'gar' and 'gas' because of the obvious conflicts. 'gobjcopy' is a little less obvious, at least to me ... but if that's expected, then ok. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
