zsh-workers
 help / color / mirror / code / Atom feed
From: Chet Ramey <chet@nike.ins.cwru.edu>
To: schaefer@brasslantern.com
Cc: zsh-workers@sunsite.auc.dk
Subject: Re: ZSH 2GB File Limit (Solaris 2.6)
Date: Tue, 4 May 1999 15:04:12 -0400	[thread overview]
Message-ID: <990504190412.AA12429.SM@nike.ins.cwru.edu> (raw)
In-Reply-To: Message from schaefer@brasslantern.com of Tue, 4 May 1999 11:00:25 -0700 (id <990504110026.ZM28651@candle.brasslantern.com>)

> On May 4, 10:34am, Peter Stephenson wrote:
> } Subject: Re: ZSH 2GB File Limit (Solaris 2.6)
> }
> } That's this code from bash's configure.  What do we do, just copy it and
> } change BASH to ZSH?
> 
> Unless I'm missing something (which is entirely possible), this configure
> stuff doesn't do anything but define BASH_LARGE_FILE_SUPPORT.  There must
> be some actual C code somewhere in the bash source that tests for that
> constant and does *something*.  That something is far more interesting
> than the configure part.

I got into this discussion late, but that's not what the code in
bash's aclocal.m4 does.  It's designed to work with the Solaris large
file stuff, and very little, if anything, else.  It uses getconf to
test for, in turn,

	LFS_CFLAGS
	LFS64_CFLAGS
	LFS_LDFLAGS
	LFS64_LDFLAGS
	LFS_LIBS
	LFS64_LIBS

sets

	ac_getconfs

to any values returned, and sets

	ac_test_CPPFLAGS
	ac_test_LDFLAGS
	ac_test_LIBS

to the values appropriate for those variables as returned by getconf.

If any of those variables has a value, the CPPFLAGS, LDFLAGS, and LIBS
variables get seeded from them.  The bash configure calls
BASH_LARGE_FILE_SUPPORT before any other autoconf tests that can set
these values, right after AC_PROG_CC.

On Solaris 2.6, CPPFLAGS gets set to

CPPFLAGS = -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE

This stuff gets used only if the user didn't pass values for the
variables in configure's environment.

The cpp defines and libraries (if any) make solaris use the 64-bit
versions of certain file-handling system calls.  Run `man interface64'
on a Solaris 2.6 machine for more info.

Chet


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu


  reply	other threads:[~1999-05-04 19:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-05-04  7:24 Peter Bray
1999-05-04  8:34 ` Peter Stephenson
1999-05-04 18:00   ` Bart Schaefer
1999-05-04 19:04     ` Chet Ramey [this message]
1999-05-04 19:21     ` Kevin Sullivan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=990504190412.AA12429.SM@nike.ins.cwru.edu \
    --to=chet@nike.ins.cwru.edu \
    --cc=chet@po.CWRU.Edu \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).