Re: 64-bit sparc instructions

[Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru>]

On Wed, 23 May 2001, Bart Schaefer wrote:

> On May 22,  8:04pm, Paul Ackersviller wrote:
> }
> } [...] What does make a difference is simply generating default 32-bit
> } sparc instructions.  I'd negelected to mention that I was using Sun's
> } compiler and 64-bit code.  I suppose it's fair to blame this one on Sun.
>
> Is that problem solved by the following?
>
> On May 22,  2:32pm, Clint Adams wrote:
> } Subject: Re: 4.0.1-pre-5 (solaris issues)
> }
> } > the 64-bit Forte compiler.  Can you figure out what we need to be passing
> } > as a compiler argument that we aren't, or whatever?
> }
> } LFS64_CFLAGS:                   -D_LARGEFILE64_SOURCE
> } LFS_CFLAGS:                     -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> }
> } By replacing the latter with the former, the test [succeeds].
>
> If so, can you identify a configure test we can use to decide when to
> use LFS64_CFLAGS instead of LFS_CFLAGS ?  (The existing test is in the
> definition of zsh_LARGE_FILE_SUPPORT in aczsh.m4.)
>
>

Hmm ... they both have very different semantic. LFS means, use existing
interfaces but assume some parameters are 64 bit (off_t, size_t, ino_t to
name some).

LFS64 means - you are explicitly using special 64-bit version of these
interfaces (open64 vs. open, stat64 vs. stat etc) that are using special
types (off64_t, ino64_t etc). Zsh is not designed to do it.

So, if the above change really helped, it was just because zsh was
actually compiled in 32-bit mode :-) We simply need better detection if
LFS really works. Could you provide testcase suitable for putting in
configure?

-andrej