Mike Kupfer writes:
> 265 P3 scm-migration-dev at opensolar... SGS commands use sccs SID in
> version...
I think we need more discussion about this one before putting it on
the stopper list for internal review.
The problem listed here is that "ld -V" grabs its version number
information from the SCCS SID on this file:
usr/src/cmd/sgs/packages/common/SUNWonbld-README
On a build done from a Mercurial gate, we get "0.0" for the version
number:
# ld -V
ld: Software Generation Utilities - Solaris Link Editors:
5.11-0.0:rbridges-test-carlsonj-03/20/08
which then causes nightly to fall apart.
The problem cited in this bug happens only when we try to be "self
hosting." In other words, you can't currently build OpenSolaris on a
machine running bits compiled from a Mercurial repository. In fact,
the problem is true today even before we integrate our updated build
tools -- builds have to be done on a machine running SXCE.
However, I think we can split this Gordian knot. The check that
nightly is making is for version 1.422 of ld, which corresponds to the
fix for CR 4948119. That fix went into s10_47 (i.e., prior to Solaris
10 FCS), so nobody building OpenSolaris is going to run into it.
You'd have to be attempting to build OpenSolaris on Solaris 9 with
something older than Update 7.
Thus, we can just ditch the check in nightly. It was needed 4.5 years
ago when it was added, but it isn't needed anymore.
That leaves just the semi-bogus output from "ld -V" itself. I don't
think that's a stopper for SCM tool integration. It's an existing
problem that we're making no worse. It might be considered a blocker
for the ON gate switchover instead -- and we should have a CR on this.
If we agree on this, I'll make the changes to nightly, file the new
CR, and close out this bug.
--
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
