> Sorry for answering myself, but I only realized this is the same kind of
> bug as the previous one, but more convoluted.
I have been watching this closely and thinking "what about Solaris 8 and
Solaris 9" which both have 32-bit x86 and both can run on 32-bit Sparc
hardware just fine?
I am not sure what happens if a person attempts a build on Solaris 8 x86
and then relies on the ABI to provide upward compatibility. I think .. no
way will that work.
Regardless, that tweak doesn't actually fix the problem.
> the "replace" script does the right only if *both* the
> SunOS5/i386-5.10/i86 and SunOS5/i386-5.10/amd64 directories are present.
> If not, it assumes it can replace the binaries directly. This is
> obviously an insufficient check.
This sort of machine would be an issue :
$ uname -a
SunOS titan 5.10 Generic_120012-14 i86pc i386 i86pc
$ psrinfo -pv
The physical processor has 1 virtual processor (0)
x86 (GenuineIntel family 6 model 5 step 2 clock 400 MHz)
Intel Pentium(r) II or Pentium(r) II Xeon(tm)
The physical processor has 1 virtual processor (1)
x86 (GenuineIntel family 6 model 5 step 2 clock 400 MHz)
Intel Pentium(r) II or Pentium(r) II Xeon(tm)
$ isalist -v
pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
$ /bin/optisa pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
pentium_pro+mmx
I also have some appliance style hardware that I am experimenting with and
it is even wilder still :
$ uname -a
SunOS aequitas 5.11 snv_69 i86pc i386 i86pc
$ psrinfo -pv
The physical processor has 1 virtual processor (0)
x86 (CentaurHauls 6A9 family 6 model 10 step 9 clock 1200 MHz)
VIA Esther processor 1200MHz
$ isalist -v
i486 i386 i86
$ /bin/optisa pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
i486
I would think that the lowest common denominator is still a 32-bit build
targeted for the i486 processor.
> The "buildsunos" script is the one supposed to create those directories
> in the first place.
> Again, the check is insufficient. If that one fails, it assumes 32 bit
> only, and won't create architecture subdirectories:
>
> if [ $solrev -ge 10 ] && /bin/optisa sparcv8plus amd64 > /dev/null
>
> However, I'm running S10 on a 32 bit processor, so that check will fail
> (no amd64), but the i86/ and amd64/ subdirectories are *still* both needed.
I am in the same boat here. Plus I have Solaris 8 to contend with.
> I think the check should only be on the version of Solaris and the
> ability of the compiler to generate both i86 and amd64 binaries. And in
> any case, even if amd64 binaries are not possible, it should always use
> an i86/ subdirectory, not . , and the "replace" script should, too.
>
> Of course, this issue does not exist on SPARC, since there's no 32 bit
> SPARC supported by S10.
I often wonder if that was a good choice. There could have been embedded
solutions uisng 32-bit Sparc quite neatly and they could compete with
PowerPC solutions. ... but I digress.
Dennis
