[rescue] Solaris Studio

[Mike Meredith]

On Mon, 17 Jul 2017 10:37:02 -0400 (EDT), Mouse wrote:
> > And absolutely critically, I need to be able to compile Bacula
> > 64-bit.  ALL of the open-source packages are 32-bit.
> > [...]
> > Look, I don't care if a task runs 2%-3% slower.  But I *REALLY* care
> > if something as simple as a file copy craps out in the middle of a
> > 4GB file because it can't handle a file offset larger than 2GB.
>
> Well, I don't know Solaris,  But building for a 32-bit ISA is not
> necessarily incompatible with correct handling of >31bit (or even

The relevant neurons are very rusty, but I had good reasons to look
into this fairly deeply back in the day (half of my Solaris boxes were
running Oracle and more than half of those were running databases
larger than 4Gbytes).

Although backwards compatibility with SunOS4 meant that Solaris
binaries _could_ be incompatible with LFS, you had to go to quite some
effort to compile source without support for LFS. Basically what
happened was that fseek retained the 31/2-bit limit and a new function
fseeko used a 64-bit integer type; by default a macro defined fseek as
fseeko.

Essentially a freshly compiled 32-bit binary is very unlikely not to
support large files.

But as always, test before trusting random strangers on the Internet.

AMD64 confused matters, but ignoring that architecture the general
advice was to compile 32-bit binaries unless you needed large memory
space. We found that pretty much the only things that needed to be
64-bits were Oracle and Java-based stuff.

--
Mike Meredith (http://zonky.org/)
Needless to say, this is not a good idea.
   -- The US National Hurricane Centre in part of their response to the
      suggestion that we could nuke hurricanes to stop them.

[demime 1.01d removed an attachment of type application/pgp-signature]