>Garrett D'Amore wrote: >> Note that I find a similar case in /usr/sbin/sparcv9 as well. Although, >> in that case, it appears that there is less duplication, and most of the >> contents of /usr/sbin with equivalents in /usr/bin/sparcv9 are just >> links to isaexec. But why even waste the extra cycles to do the >> isaexec, when we could just have the binaries physically in /usr/sbin? >> (Likewise for isaexec binaries in /usr/bin.) > >I noticed that as well a while ago and filed: >6226947 isaexec and the sparcv[79] binaries no longer useful on sparc
We really should have a better structured build for this. Much of prototype_sparc vs prototype_i386 is sparcv7/sparcv9 vs i86pc/amd64. If we start fixing this, the build mechanism should figure this out mostly by itself. f usr/bin/$KERNISA/truss should map on sparc to: f usr/bin/truss (one kernel architecture on SPARC) and on x86 to: l usr/bin/truss=../../usr/lib/isaexec f usr/bin/i86/truss f usr/bin/amd64/truss whereas f usr/bin/$ALLISA/mdb should map on sparc to: l usr/bin/mdb=../../usr/lib/isaexec f usr/bin/sparcv7/mdb f usr/bin/sparcv9/mdb and on x86 to: l usr/bin/mdb=../../usr/lib/isaexec f usr/bin/i86/mdb f usr/bin/amd64/mdb With some additional Makefile rules, of course, to make this all transparent. "ls" would likely remain an exception; sort possibly too. (But we'd only ship 64 bit ls and sort on SPARC, I would think) Casper _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
