On Wed, 21 Feb 2007 10:05:10 -0500 James Carlson wrote:
> Glenn Fowler writes:
> > > However, if the ATT code already expects this to be "11" for a SunOS
> > > "5.11" version, then I'm fine with what you have now. If you could
> > > pass upstream the feedback, though, that this could break if the minor
> > > part ever reverts to "0", that would be appreciated.
> >
> > the HOSTTYPE value (.../arch/$HOSTTYPE/...) used in ast packaging is for
> > differentiating incompatible .o/a.out formats/compilation-systems
> > it lies somewhere between "i386" and "uname -r" or "gcc -v"
> > its not a place for version numbers unless version numbers illuminate
> > binary incompatibility
> Binary incompatibility for _what_?
at time (t) I post solaris sparc binaries for say, ksh
at time (t+1) the solaris implementation relase changes
and posted binaries no longer work for the new release
worse, binaries built to (t+1) dont work for (t)
so the binaries I post split to pre-(t) and post-(t)
> If that incompatibility is in the
> system itself, then I strongly object to using Solaris minor release
> numbers here. It makes no sense at all.
> If you must use a number here, then use the major number ('5').
hey, in this instance I'm just an outside hacker attempting to deal
with a real problem among N implementations, one of which is solaris
if some standard (defacto or otherwise) consistent with all implementations
had addressed this issue I would have been more than happy to use it
the spellings of HOSTTYPE evolve with empirical evidence for each implementation
for solaris there exists some (I) where sol(I).* binaries are/were incompatible
with sol(I+1) (I dont recall the (I) exactly, but 6 comes to mind)
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
