[OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Richard L. Hamilton]

> On May 26, 2017, at 12:01, Alan Coopersmith <alan.coopersmith at oracle.com> wrote:
> 
> On 05/26/17 04:26 AM, Harry Putnam wrote:
>> Jonathan Adams <t12nslookup at gmail.com> writes:
>> 
>>> Much better than the Linux "file 'which file'" (with back ticks) ...
>>> 
>> 
>> sudo  file `which file`
>> /usr/bin/file:  ELF 32-bit LSB executable 80386 Version 1, dynamically
>> linked, not stripped, no debugging information available
>> 
>> Er... looks like one of the techniques has got it wrong
>> 
>> Or does something else explain this?
> 
> That works on Linux distros which have separate 32-bit & 64-bit versions
> and compile every binary in the OS to match.
> 
> That doesn't work on Solaris-derived distros which have a unified 32/64 bit
> version that supports binaries of either flavor, and which many programs are
> 32-bit so they can run on either 32-bit or 64-bit kernels.
> 
> As distros drop 32-bit kernel support, they'll likely convert more and more
> of their programs to 64-bit, but it can be a gradual process, not a flag day.
> 
> For the one I work on (not OI, but "Big Red"), we've been making this conversion
> across 5+ years now, and are >90% done in our development trunk, though much
> less done in what's been released so far.  I've written far more about the
> topic for the terminally curious at:
> 
> https://blogs.oracle.com/alanc/moving-oracle-solaris-to-lp64-bit-by-bit
> https://blogs.oracle.com/observatory/oracle-solaris-113-progress-on-lp64-conversion
> 
> 	-alan-

Aside from executables that reference timestamps (given that a signed twos-complement will overflow after Tue Jan 19 03:14:07 2038 GMT), and for programs that will never need to manipulate files larger than 2GiB-1 (unless  they use large file support), is it necessarily desirable to upgrade user-space binaries at all?  On x86, ok you get more registers and such; but on SPARC, I've heard you may be better off with V8 (or V8+), given smaller binaries, better use of cache, etc.

Ok, thinking about it, now that static libc is gone, with the time issues, a 32-bit libc would be an invitation to forget that it wouldn't work with something that used timestamps, not to mention whatever complications follow from maintaining support for 32-bit executables.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://openindiana.org/pipermail/openindiana-discuss/attachments/20170531/a2c3dc79/attachment.bin>