bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ac_sys_largefile / fseeko problem


From: Petr Vandrovec
Subject: Re: ac_sys_largefile / fseeko problem
Date: Mon, 17 Mar 2003 13:05:55 +0100

On 17 Mar 03 at 12:02, Guido Draheim wrote:
> Petr Vandrovec schrieb:
> > On 17 Mar 03 at 11:33, Guido Draheim wrote:
> > 
> >>Personally, I think it would be the best to simply
> >>add a global change in features.h
> > 
> > 
> > What about reading LFS standard: if _LARGEFILE_SOURCE is not
> > defined, neither fseeko nor fseeko64 do exist. Take it up 
> > with standard authors, not with glibc guys.
> 
> I can take it up with either guys ;-)
> 
> Firstly, SUS2/UNIX98 lists fseeko _without_ a requirement
> on some _LARGEFILE_SOURCE to exist. Read the given standard
> page reference if you don't believe me:
> 
> http://www.opengroup.org/onlinepubs/007908799/xsh/fseeko.html

If you'll define _XOPEN_SOURCE=500 (to get SUSv2), you get 
_LARGEFILE_SOURCE, so I see no problem...
 
> Secondly, I'm cc'ing autoconf ML exactly for that reason,
> since AC_SYS_LARGEFILE has never set _LARGEFILE_SOURCE
> even that LFS specs mandate that it should be the
> primary selector to enable LFS pieces. I guess that you
> did guess a requirement for fseeko from that fact.

3.3 Accessing the Extensions to the SUS
3.3.1 Compilation Environment - Visibility of Additions to the API
Application which define the macro _LARGEFILE_SOURCE to be 1 before
inclusion of any header will enable at least the functionality
described ni "2.0 Change to the Single UNIX Specification" on implementations
that support these features. Implementatons that support these features
will define _LFS_LARGEFILE to be 1 in <unistd.h>, as described in
3.1.2.12 <unistd.h>

(from 
http://216.239.51.100/search?q=cache:Jvi-99KXhFgC:www.sas.com/standards/large.file/x_open.20Mar96.html+fseeko+large+file+summit&hl=cs&ie=UTF-8)

So you are either operating in pre-SUSv2 environment, where above
applies and you must define _LARGEFILE_SOURCE, or you operate in
post SuSv2 environment, where you must set _XOPEN_SOURCE=500.

Or, you should build all apps with _GNU_SOURCE, which gives you complete
API as exported by glibc library.

Unfortunately there is no way how to prevent you from using fseeko
symbol from binary if you ignored compilation warnings (except naming
fseeko differently, but almost all glibc functions are available only
after defining certain defines, so this would create only nightmare).

                                        Petr Vandrovec
                                        address@hidden
                                        





reply via email to

[Prev in Thread] Current Thread [Next in Thread]