From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3261 invoked from network); 12 May 1999 09:47:11 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 12 May 1999 09:47:11 -0000 Received: (qmail 11650 invoked by alias); 12 May 1999 09:46:43 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6270 Received: (qmail 11643 invoked from network); 12 May 1999 09:46:42 -0000 From: "Andrej Borsenkow" To: "Peter Stephenson" , "ZSH workers mailing list" Subject: RE: PATCH: Re: LFS notes RE: pws-18 is go Date: Wed, 12 May 1999 13:43:11 +0400 Message-ID: <004001be9c5b$d95c62a0$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: <9905120900.AA13913@ibmth.df.unipi.it> Importance: Normal > > > 3. Setting LFS[64]_CFLAGS & Co is not enough!!! One must set either > > _LARGEFILE_SOURCE *or* _LARGEFILE64_SOURCE to indicate, which > mode is used > > (a side note, that _LARGEFILE64_SOURCE has some problems on our system). > > Eh? The LFS_CFLAGS getconf stuff just probes for the right flags to set. > On Solaris 5.6 I get CPPFLAGS set to > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > Is the getconf test working where you are? If not, none of this stuff > applies anyway. > >>From the page I quoted: 3.3.1 Compilation Environment - Visibility of Additions to the API Applications which define the macro _LARGEFILE_SOURCE to be 1 before inclusion of any header will enable at least the functionality described in 2.0 Changes to the Single UNIX Specification on implementations that support these features. Implementations that support these features will define _LFS_LARGEFILE to be 1 in , as described in 3.1.2.12 . 3.3.4 Utilities: Optional Method for Specifying the Size of an off_t For programs to take advantage of different environments, it is necessary to compile them for each particular environment. For programs to make use of the features described in this section they must be compiled with new compiler and linker options. The getconf utility called with the new arguments can be used to generate compiler and linker options. Example 1: An example of compiling a program with a "large" off_t and that uses fseeko() and ftello() and uses yacc: c89 -D_LARGEFILE_SOURCE -o foo \ $(getconf LFS_CFLAGS) y.tab.c b.o \ $(getconf LFS_LDFLAGS) \ -ly $(getconf LFS_LIBS) Example 2: An example of compiling a program with a "large" off_t and that does not use fseeko() and ftello() and has no application specific libraries: c89 $(getconf LFS_CFLAGS) a.c \ $(getconf LFS_LDFLAGS) \ $(getconf LFS_LIBS) A.3.2.1 Compilation Environment - Visibility of Additions to the API Applications which use the fseeko() and ftello() interfaces should define _LARGEFILE_SOURCE to be 1, then include and then test that _LFS_LARGEFILE is 1 to determine if the additional functionality is indeed available. This additional functionality may be available even when _LARGEFILE_SOURCE is not defined, but it will not be available to strictly conforming X/Open programs. This macro does not affect the size of off_t (see 3.3.3 Mixed API and Compile Environments Within a Single Process). In other words: to use 64 bit off_t, one has to use LFS_CFLAGS to use ftello/fseeko one must set _LARGEFILE_SOURCE Solaris is non-conformant in automagically setting _LARGEFILE_SOURCE in LFS_CFLAGS > > I've added this, but all you're supposed to do is set CPPFLAGS to > anything, > even empty, and it will suppress modification of all the flags by > the large > file check. > Hmm... I've tried it, but still got all LFS flags. I'll recheck it when I have a bit more time. /andrej