From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8404 invoked from network); 24 May 2001 02:17:33 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 24 May 2001 02:17:33 -0000 Received: (qmail 8340 invoked by alias); 24 May 2001 02:17:25 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14465 Received: (qmail 8328 invoked from network); 24 May 2001 02:17:24 -0000 Date: Wed, 23 May 2001 19:17:21 -0700 From: nce@SLAC.Stanford.EDU Subject: Re: FWD: Re: 64-bit sparc instructions To: Andrej Borsenkow Cc: zsh-workers@sunsite.dk Message-id: <20010523191721.C9730@flora01.SLAC.Stanford.EDU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT User-Agent: Mutt/1.2.5i Hi, Excuse me if I missed any of this discussion, I wasn't on the -workers list until just now. Andrej Borsenkow wrote: > On Wed, 23 May 2001, Bart Schaefer wrote: > > > 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. Of course you're absolutely right about the above. > 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? I'd be willing to help with this if no one has a solution yet. -- Paul Ackersviller