James Carlson wrote:
> Stefan Teleman writes:
>> James Carlson wrote:
>>> 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 ... ?
>> That was my implied point. There does not seem to be a consistent approach
>> here,
>> with the existing SUNWbinutils.
>
> Yep.
>
> I have no idea how the OpenSolaris distribution became inconsistent in
> this way, but perhaps it doesn't matter for ARC purposes: OpenSolaris
> is still just an unintegrated project, which means that they needn't
> conform necessarily with any particular architecture.
The other problem with having symlinks in /usr/bin is that we implicitly assert
a preference for one version of binutils, or GCC, over another. Meaning: as
long
as there is only one version of binutils, or GCC, available, everything is
fine:
the symlinks in /usr/bin point to the sole instance. This no longer holds
when
there is more than one version of either component available: we are making an
implicit value judgement ("the latest version is the one we like best"). This
can create binary compatibility problems.
> So I would assert that the real issue (at least for the ARC) is the
> intended architecture of SUNWbinutils, and not how it happens to
> appear on one or another (locally modified?) distribution.
>
> To conform with the /usr/gnu cases you're citing, that should mean
> that non-conflicting bits belong in /usr/bin, and only things with
> conflicts go in /usr/gnu/bin.
>
> In other words, /usr/bin/gar makes sense, as does /usr/gnu/bin/ar, but
> /usr/gnu/bin/gar doesn't make sense.
I can then change the bits in /usr/gnu/bin to remove the 'g', with the
exception
of gprof.
--Stefan
--
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman at Sun.COM
