From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10557 invoked from network); 15 May 1999 13:49:19 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 May 1999 13:49:19 -0000 Received: (qmail 52 invoked by alias); 15 May 1999 13:48:52 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6289 Received: (qmail 44 invoked from network); 15 May 1999 13:48:51 -0000 Message-Id: <9905151324.AA25833@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: gcc problem with 64 bit integers Date: Sat, 15 May 1999 15:24:29 +0200 From: Peter Stephenson I'm wrestling with what looks like a gcc 2.8.1 bug when trying to get the large file support to work properly under SunOS 5.6. The struct gmatch in glob.c contains file sizes which need to be off_t, 64 bit integers (i.e. long long) in this case. The compiled code crashes when attempting to assign to this, matchptr->size = buf.st_size; (both are off_t) in insert(). Compiling without optimization doesn't help. The native cc works without a problem. I've tried using __attribute__ ((align)) in various forms to get the members of struct gmatch aligned correctly, but that doesn't seem to help. It looks like it may be worse, anyway, because even memcpy() doesn't seem to do the trick. Any suggestions for a workaround? If gcc can't handle this, it makes the large file support look distinctly dodgy. My impression of looking at docs.sun.com is that LP64 is only supported if the underlying operating system is 64-bit, i.e. there's no way of just compiling zsh with 64-bit longs on an existing 32-bit system. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy