GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008]

[James Carlson]

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