Re: AC_SYS_LARGEFILE

On 21.09.2023 0:49, Paul Eggert wrote: On 2023-09-20 05:52, Evgeny Grin wrote: If you need have a function with "file offset" argument then use either 'uint64_t' Although your other advice is good, this one is suspect. I'm glad I didn't follow similar advice to use 'int32_t' or 'long' for f

Re: AC_SYS_LARGEFILE

On 2023-09-20 05:52, Evgeny Grin wrote: If you need have a function with "file offset" argument then use either 'uint64_t' Although your other advice is good, this one is suspect. I'm glad I didn't follow similar advice to use 'int32_t' or 'long' for file offsets back in the day. Also, to b

Re: AC_SYS_LARGEFILE

On 20.09.2023 0:04, Paul Eggert wrote: On 2023-09-19 01:52, Sébastien Hinderer wrote: Are you saying that there should normally not  be any undef in the config headers for macros whose name starts with a _ sign? No, it's normal when Autoconf is used as intended. What's not normal is that yo

Re: AC_SYS_LARGEFILE

On 2023-09-19 01:52, Sébastien Hinderer wrote: Are you saying that there should normally not be any undef in the config headers for macros whose name starts with a _ sign? No, it's normal when Autoconf is used as intended. What's not normal is that your package is including after including s

Re: AC_SYS_LARGEFILE

Paul Eggert (2023/09/18 13:46 -0700): > On 2023-09-18 02:55, Sébastien Hinderer wrote: > > the project currently has the convention of including > > system headers before its ocnfiguraiotn headers > > Ouch. The Autoconf manual explicitly says "The package should ‘#include’ the > configuration heade

Re: AC_SYS_LARGEFILE

On 2023-09-18 02:55, Sébastien Hinderer wrote: the project currently has the convention of including system headers before its ocnfiguraiotn headers Ouch. The Autoconf manual explicitly says "The package should ‘#include’ the configuration header file before any other header files"

Re: AC_SYS_LARGEFILE

riginal author used CC, but the > > reason is probably so that you can just take an existing package and > > just add AC_SYS_LARGEFILE with no other modifications and it will almost > > certainly work without any major problems. > > Back in the day when such flags were common (th

Re: AC_SYS_LARGEFILE

Hello, Many thanks for your response. Paul Eggert (2023/09/11 13:38 -0500): > On 9/11/23 13:23, Russ Allbery wrote: > > I suspect that the aswer to the original question is "don't worry about > > it, just use AC_SYS_LARGEFILE, because no system you will build on will >

Re: AC_SYS_LARGEFILE

Hi, Many thanks for your response. Nick Bowler (2023/09/11 13:56 -0400): > On 2023-09-11, Sébastien Hinderer wrote: > > I am writing with a quesiton about the AC_SYS_LARGEFILE macro. > > > > It would be great to be able to use it but according to its > > documentatio

Re: AC_SYS_LARGEFILE

On 9/11/23 13:23, Russ Allbery wrote: I suspect that the aswer to the original question is "don't worry about it, just use AC_SYS_LARGEFILE, because no system you will build on will need the CC modification anyway." Yes, that's the advice I'd give. One other caveat is

Re: AC_SYS_LARGEFILE

rent systems), AC_DEFINE is used. > It has been this way since the macro was originally added to Autoconf. > I can only speculate as to why the original author used CC, but the > reason is probably so that you can just take an existing package and > just add AC_SYS_LARGEFILE with no other m

Re: AC_SYS_LARGEFILE

On 2023-09-11, Sébastien Hinderer wrote: > I am writing with a quesiton about the AC_SYS_LARGEFILE macro. > > It would be great to be able to use it but according to its > documentation, the macro adds its flags to the CC output variable, which > is not convenient in my context

Re: AC_SYS_LARGEFILE

Dear Bob, Many thanks for your repsonse! Bob Friesenhahn (2023/09/11 11:28 -0500): > On Mon, 11 Sep 2023, Sébastien Hinderer wrote: > > > Dear all, > > > > I am writing with a quesiton about the AC_SYS_LARGEFILE macro. > > > > It would be great to be

Re: AC_SYS_LARGEFILE

On Mon, 11 Sep 2023, Sébastien Hinderer wrote: Dear all, I am writing with a quesiton about the AC_SYS_LARGEFILE macro. It would be great to be able to use it but according to its documentation, the macro adds its flags to the CC output variable, which is not convenient in my context because

AC_SYS_LARGEFILE

Dear all, I am writing with a quesiton about the AC_SYS_LARGEFILE macro. It would be great to be able to use it but according to its documentation, the macro adds its flags to the CC output variable, which is not convenient in my context because we have dedicated variables not only for C flags

Re: autoconf: AC_SYS_LARGEFILE documentation misleading

Jan 2017 11:50:31 +0100 Subject: [PATCH] doc: Fix incorrect AC_SYS_LARGEFILE documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The output goes to DEFS or config.h, by calling AC_DEFINE_UNQUOTED. Building on top of Eric Blake’s clarificat

Re: autoconf: AC_SYS_LARGEFILE documentation misleading

Dixi quod… > On Wed, 25 Jan 2017, Eric Blake wrote: > > > I also think we can try harder to point out the need for config.h to > > appear first. How about the following counter-proposal: […] > Nice, but I think I can improve on that a bit (later, I’m almost > dropping down due to tiredness), it s

Re: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

gt; 1999-05-01), but it was in the very next release, 2.50 (2001-05-21). > The ChangeLog entry for the addition says "Import AC_SYS_LARGEFILE > from largefile.m4 serial 12", so that sounds like there was an add-on > .m4 file with the same functionality floating around prior to t

Re: autoconf: AC_SYS_LARGEFILE documentation misleading

On Wed, 25 Jan 2017, Eric Blake wrote: > Thanks; that's helpful. I'm still thinking we may want to iterate on Yes, of course; you know autoconf much better than I do. > You're deleting all mention that the macro may modify CC (true, it > doesn't do it on most platforms, but the code is still th

Re: autoconf: AC_SYS_LARGEFILE documentation misleading

On Wed, Jan 25, 2017 at 2:06 PM, Eric Blake wrote: > > I also think we can try harder to point out the need for config.h to > appear first. How about the following counter-proposal: ... If we're going to warn people about this in the context of specific macros we should do the same for AC_USE_SY

Re: autoconf: AC_SYS_LARGEFILE documentation misleading

On 01/25/2017 11:30 AM, Thorsten Glaser wrote: > On Wed, 25 Jan 2017, Eric Blake wrote: > >> Please propose a patch to the documentation, rather than just telling me >> that it is wrong, so that we have a concrete proposal for a wording >> improvement that we can discuss. > Oh okay, I’ll cater for

Re: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

On 01/25/2017 10:24 AM, Zack Weinberg wrote: The ChangeLog entry for the addition says "Import AC_SYS_LARGEFILE from largefile.m4 serial 12", so that sounds like there was an add-on .m4 file with the same functionality floating around prior to that - I don't know where to find

Re: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

On Wed, Jan 25, 2017 at 1:02 PM, Thorsten Glaser wrote: > On Wed, 25 Jan 2017, Zack Weinberg wrote: > >> As far as I can tell from the Git history, AC_SYS_LARGEFILE has >> *always* used AC_DEFINE_UNQUOTED to define the various preprocessor >> macros that it can d

Re: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

On Wed, 25 Jan 2017, Zack Weinberg wrote: > As far as I can tell from the Git history, AC_SYS_LARGEFILE has > *always* used AC_DEFINE_UNQUOTED to define the various preprocessor > macros that it can define (_FILE_OFFSET_BITS, _LARGE_FILES, and > _DARWIN_USE_64_BIT_INODE). Inter

Re: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

oing the change.) As far as I can tell from the Git history, AC_SYS_LARGEFILE has *always* used AC_DEFINE_UNQUOTED to define the various preprocessor macros that it can define (_FILE_OFFSET_BITS, _LARGE_FILES, and _DARWIN_USE_64_BIT_INODE). That part of the code has been unchanged since AC_SYS_LARG

Re: autoconf: AC_SYS_LARGEFILE documentation misleading

SteegFrom e1319f97063b2e3b1db0d62fcbfd996d8cf2657c Mon Sep 17 00:00:00 2001 From: mirabilos Date: Wed, 25 Jan 2017 18:27:27 +0100 Subject: [PATCH] doc: Fix incorrect AC_SYS_LARGEFILE documentation The output goes to DEFS or config.h, by calling AC_DEFINE_UNQUOTED. Reported as Debian #158969 by Florian Weimer

Re: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

severity 852617 wishlist tags 852617 = upstream thanks On Wed, 25 Jan 2017, Eric Blake wrote: > If the real-world package is not including config.h first, then that is > a bug in the real-world package that should be fixed there. Autoconf OK, I’ve (separately) reported the bug to xrdp upstream.

Re: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

On 01/25/2017 10:57 AM, Thorsten Glaser wrote: > On Wed, 25 Jan 2017, Thorsten Glaser wrote: > >> Looking at the source, AC_SYS_LARGEFILE calls AC_DEFINE_UNQUOTED, >> which appends to DEFS (which I agree with Tom Dickey is wrong) as >> Florian Weimer said, but — even more

Re: autoconf: AC_SYS_LARGEFILE documentation misleading

On 01/25/2017 10:45 AM, Thorsten Glaser wrote: > > This is even more unfortunate, because now, if any program includes > a glibc system header before "config.h", the definition will be > ignored, because it comes too late. This is wrong. The manual clearly states that config.h MUST be included pr

autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

On Wed, 25 Jan 2017, Thorsten Glaser wrote: > Looking at the source, AC_SYS_LARGEFILE calls AC_DEFINE_UNQUOTED, > which appends to DEFS (which I agree with Tom Dickey is wrong) as > Florian Weimer said, but — even more confusingly — only when > AC_CONFIG_HEADERS is not u

autoconf: AC_SYS_LARGEFILE documentation misleading

found 158969 2.69-10 thanks Hi *, I have to reopen this because the documentation is plain wrong and misleading still: -- Macro: AC_SYS_LARGEFILE Arrange for 64-bit file offsets, known as large-file support (http://www.unix-systems.org/version2/whatsnew/lfs20mar.html). On some

suggest AC_SYS_LARGEFILE should #define _LARGEFILE, at least for VMS

I suggest AC_SYS_LARGEFILE should #define _LARGEFILE, at least for VMS See: http://h71000.www7.hp.com/commercial/c/docs/5763pro_033.html https://curl.haxx.se/mail/lib-2009-12/0278.html https://en.wikibooks.org/wiki/Porting_Open_Source_to_OpenVMS I have another suggestion. Instead of having

Re: AC_SYS_LARGEFILE & URL

Bob Friesenhahn <[EMAIL PROTECTED]> writes: > "http://www.sas.com/standards/large.file/x_open.20Mar96.html";. This > URL no longer works. It seems that the best URL to use is > "http://www.sas.com/standards/large.file/";. Thanks. The latest CVS autoconf uses

Re: AC_SYS_LARGEFILE & URL

On 9 Jul 2003, Paul Eggert wrote: > Bob Friesenhahn <[EMAIL PROTECTED]> writes: > > > "http://www.sas.com/standards/large.file/x_open.20Mar96.html";. This > > URL no longer works. It seems that the best URL to use is > > "http://www.sas.com/standards/large.file/";. > > Thanks. The latest CVS auto

AC_SYS_LARGEFILE & URL

The documentation for AC_SYS_LARGEFILE lists the URL "http://www.sas.com/standards/large.file/x_open.20Mar96.html";. This URL no longer works. It seems that the best URL to use is "http://www.sas.com/standards/large.file/";. Bob == Bo

Re: ac_sys_largefile / fseeko problem

Guido Draheim <[EMAIL PROTECTED]> writes: > The glibc cvs stdio.h should be fixed, - atleast do export fseeko > when #def __USE_FILE_OFFSET64 is set! POSIX 1003.1-2001 says that fseeko should be exported by any implementation that claims conformance to XSI. glibc doesn't claim that yet, but it w

Re: ac_sys_largefile / fseeko problem

On Mon, 17 Mar 2003, Guido Draheim wrote: > Petr Vandrovec schrieb: > > On 17 Mar 03 at 15:08, Guido Draheim wrote: > > You get warning. In C++ you get error. If you ignore warnings, it is > > your problem... > > You only get warnings when using -Wall or similar. The C > language is otherwise fine

Re: ac_sys_largefile / fseeko problem

ILE64_SOURCE, it can still expect to have its own fseeko function which does something completely different. what? doh! how so? You can read archives - while googling for LFS text I found quite a lot 'ac_sys_largefile' discussions, all comming down to the "Use proper #define for y

Re: ac_sys_largefile / fseeko problem

does something completely different. You can read archives - while googling for LFS text I found quite a lot 'ac_sys_largefile' discussions, all comming down to the "Use proper #define for your code" and do not ignore warnings. Petr Vandrovec

Re: ac_sys_largefile / fseeko problem

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

Re: ac_sys_largefile / fseeko problem

me _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... &

Re: ac_sys_largefile / fseeko problem

, 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. Thirdly, it doesn't h

Re: ac_sys_largefile / fseeko problem

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

Re: ac_sys_largefile / fseeko problem

Guido Draheim schrieb: Paul Eggert schrieb: Guido Draheim <[EMAIL PROTECTED]> writes: I am using AC_SYS_LARGEFILE AC_CHECK_FUNCS(ftello fseeko) Use AC_FUNC_FSEEKO rather than AC_CHECK_FUNCS(fseeko). That should work around your problems. Thanks. However, that macro still calls the

Re: ac_sys_largefile / fseeko problem

Paul Eggert schrieb: Guido Draheim <[EMAIL PROTECTED]> writes: I am using AC_SYS_LARGEFILE AC_CHECK_FUNCS(ftello fseeko) Use AC_FUNC_FSEEKO rather than AC_CHECK_FUNCS(fseeko). That should work around your problems. Thanks. However, that macro still calls the glibc behavior a bug, w

Re: ac_sys_largefile / fseeko problem

Guido Draheim <[EMAIL PROTECTED]> writes: > I am using > AC_SYS_LARGEFILE > AC_CHECK_FUNCS(ftello fseeko) Use AC_FUNC_FSEEKO rather than AC_CHECK_FUNCS(fseeko). That should work around your problems.

ac_sys_largefile / fseeko problem

I am using AC_SYS_LARGEFILE AC_CHECK_FUNCS(ftello fseeko) Later in the source files, I have some #include "config.h" #include #ifdef HAVE_FTELLO #define _ftell ftello #else #define _ftell ftell #endif When configuring, I see... checking for unistd.h... (cached) yes checking for of

ac-archive.sf.net/largefile - ac_sys_largefile and libraries...

Paul Eggert schrieb: >>Date: Sat, 11 Jan 2003 20:05:30 +0100 >>From: Guido Draheim <[EMAIL PROTECTED]> > >>why not let those scripts check for spurious instances of >>fopen/lseek and friends and warn at them - so that libraries and >>modules are compiled 64bit always (using the alternate symbols >>

Re: ac-archive: ac_sys_largefile and libraries...

pilation fails. if they ignore it, fine, but they've been warned - and when there is a problem, people will check that one more closely :-)=) How about if we change AC_TYPE_OFF_T to invoke AC_SYS_LARGEFILE by default? If you want a small-file program, you'd have to invoke AC

Re: ac-archive: ac_sys_largefile and libraries...

> Date: Sat, 11 Jan 2003 11:00:57 +0100 > From: Guido Draheim <[EMAIL PROTECTED]> > > It's just like you shouldn't mix x86 applications with sparc > > libraries. They're different flavors of executable code. Don't try > > to link them together. > > Well, the linker would tell you in this exampl

Re: ac-archive: ac_sys_largefile and libraries...

> Date: Sat, 11 Jan 2003 11:00:57 +0100 > From: Guido Draheim <[EMAIL PROTECTED]> > > The end of the discussion can only be to change the compilation > behaviour globally - making 64bit off_t the default if that is > supported by the system, and dropping the settable off_t altogether. I suppose w

Re: ac-archive: ac_sys_largefile and libraries...

Paul Eggert schrieb: Date: Sat, 11 Jan 2003 11:00:57 +0100 From: Guido Draheim <[EMAIL PROTECTED]> The end of the discussion can only be to change the compilation behaviour globally - making 64bit off_t the default if that is supported by the system, and dropping the settable off_t altogether.

Re: ac-archive: ac_sys_largefile and libraries...

nd all I'm asking is for means to "defend" oneself. That can be as simple as #if defined LARGFILE_SENSITIVE && ! defined _LARGEFILE_SOURCE #error using this library requires to enable largefile mode #endif I'll go even further and say that if you have an application that

Re: ac-archive: ac_sys_largefile and libraries...

s one _can_ link x86 code to sparc code. However, generally speaking it's a bad idea, as it is much more trouble than it's worth. I'll go even further and say that if you have an application that uses file offsets and you don't invoke AC_SYS_LARGEFILE or its equivalent, you're not serious about building portable code. Apps that don't use AC_SYS_LARGEFILE aren't worth worrying about.

Re: ac-archive: ac_sys_largefile and libraries...

I don't think we should worry about supporting mixed 32- and 64-bit off_t. All sane programs will use plain 64-bit off_t on modern platforms. Libraries should be built in 64-bit mode as well. If you really need a 32-bit off_t library for some strange reason, build it separately; that's easy to d

Re: ac-archive: ac_sys_largefile and libraries...

resending Guido Draheim schrieb: Paul Eggert schrieb: I don't think we should worry about supporting mixed 32- and 64-bit off_t. All sane programs will use plain 64-bit off_t on modern platforms. Libraries should be built in 64-bit mode as well. If you really need a 32-bit off_t library

Re: ac-archive: ac_sys_largefile and libraries...

Paul Eggert schrieb: I don't think we should worry about supporting mixed 32- and 64-bit off_t. All sane programs will use plain 64-bit off_t on modern platforms. Libraries should be built in 64-bit mode as well. If you really need a 32-bit off_t library for some strange reason, build it separa

Re: ac-archive: ac_sys_largefile and libraries...

http://cvs.samba.org/cgi-bin/cvsweb/samba/source/configure.in?rev=1.383 The AC_SYS_LARGEFILE macro looks a bit outdated in comparison. Note also the agreement of the large.file.summit people to use -D_LARGEFILE_SOURCE as the primary define to enable 64bit off_t.

ac-archive: ac_sys_largefile and libraries...

the other hand, freebsd and darwin have done better and simply changed over to use 64bit off_t by default. Well, an application writer can take advantage of a prepackaged macro in autoconf AC_SYS_LARGEFILE that will ensure that his/her program gets compiled with largefile support on either unix98

Re: ["Florian Weimer" ] Bug#158969: autoconf: AC_SYS_LARGEFILE documentation misleading

> From: "Florian Weimer" <[EMAIL PROTECTED]> > Date: Sat, 31 Aug 2002 09:50:21 +0200 > > Quote from the documentation: > > - Macro: AC_SYS_LARGEFILE > Arrange for large-file support(1). On some hosts, one must use > special compiler options

Re: ["Florian Weimer" ] Bug#158969: autoconf: AC_SYS_LARGEFILE documentation misleading

-- Start of forwarded message > Subject: Bug#158969: autoconf: AC_SYS_LARGEFILE documentation misleading > From: "Florian Weimer" <[EMAIL PROTECTED]> > To: "Debian Bug Tracking System" <[EMAIL PROTECTED]> > Date: Sat, 31 Au

["Florian Weimer" ] Bug#158969: autoconf: AC_SYS_LARGEFILE documentation misleading

: AC_SYS_LARGEFILE documentation misleading From: "Florian Weimer" <[EMAIL PROTECTED]> To: "Debian Bug Tracking System" <[EMAIL PROTECTED]> Date: Sat, 31 Aug 2002 09:50:21 +0200 Message-Id: <[EMAIL PROTECTED]> Quote from the documentation: - Macro: AC_SYS_LARGEFILE

RE: Check if AC_SYS_LARGEFILE is actually provided

Well! The answer is: ifdef([AC_SYS_LARGEFILE],[],[ ])dnl Which I tried before but failed miserably, who knows why, but it worked today. Sam

Check if AC_SYS_LARGEFILE is actually provided

It's nice to be able to put AC_SYS_LARGEFILE in the configure.in and have largefile support enabled automatically. Unless of course the builder has an earlier version of autoconf installed. In which case it would be nice not to have the undefined macros error. It would be even nice

Re: AC_SYS_LARGEFILE

> From: Russ Allbery <[EMAIL PROTECTED]> > Date: Thu, 10 Jan 2002 16:23:59 -0800 > > You also need _LARGEFILE_SOURCE. That was true in older versions of AC_SYS_LARGEFILE, but in newer versions (e.g. the version shipped with Autoconf 2.52) _LARGEFILE_SOURCE has been banished

Re: AC_SYS_LARGEFILE

Russ Allbery writes: > You also need _LARGEFILE_SOURCE. I added that define and recompiled, but unfortunately g++ fails with the same error message when _LARGEFILE_SOURCE was not defined, so the define doesn't seem to make any difference. -peter

Re: AC_SYS_LARGEFILE

> From: Peter Simons <[EMAIL PROTECTED]> > Date: Wed, 9 Jan 2002 20:39:03 +0100 > > I recently added AC_SYS_LARGEFILE macro to my configure scripts, but I > encountered an interesting problem on Solaris 8: The configure script > adds the define "_FILE_OFFSET_BITS=64

Re: AC_SYS_LARGEFILE

Peter Simons <[EMAIL PROTECTED]> writes: > I recently added AC_SYS_LARGEFILE macro to my configure scripts, but I > encountered an interesting problem on Solaris 8: The configure script > adds the define "_FILE_OFFSET_BITS=64" to my CPPFLAGS, but once it does, > and

Re: AC_SYS_LARGEFILE

Albert Chin writes: > So, if your program uses open(2) and you link, you get an > unresolved reference to the symbol open? No, the header files doesn't even define the open(2) prototype anymore, thus compilation fails: | g++ -DBYTE_ORDER=BIG_ENDIAN -Du_int32_t=uint32_t -Ilibgetopt \ | -

Re: AC_SYS_LARGEFILE

On Wed, Jan 09, 2002 at 08:39:03PM +0100, Peter Simons wrote: > I recently added AC_SYS_LARGEFILE macro to my configure scripts, but I > encountered an interesting problem on Solaris 8: The configure script > adds the define "_FILE_OFFSET_BITS=64" to my CPPFLAGS, but o

AC_SYS_LARGEFILE

Hi, I recently added AC_SYS_LARGEFILE macro to my configure scripts, but I encountered an interesting problem on Solaris 8: The configure script adds the define "_FILE_OFFSET_BITS=64" to my CPPFLAGS, but once it does, and colleagues don't define open(2) anymore; apparently, I hav

Re: AC_SYS_LARGEFILE macro

> From: "Andrej Borsenkow" <[EMAIL PROTECTED]> > Date: Tue, 3 Jul 2001 21:44:58 +0400 > > > > From: "Andrej Borsenkow" <[EMAIL PROTECTED]> > > > Date: Thu, 28 Jun 2001 13:58:35 +0400 > > > > > > It checks only for specific option for IRIX and _FILE_OFFSET_BITS and > > > _LARGE_FILES macros. That

RE: AC_SYS_LARGEFILE macro

er, _FILE_OFFSET_BITS should be enough. -Kll64 is not described anywhere; I suspect it is obsoltete version of -Klonglong that is on by default. My question was mostly about getconf usage. > > why AC_SYS_LARGEFILE does not use getconf that is the > > sdtandard interface to obtain {C,LD}FL

Re: AC_SYS_LARGEFILE macro

t what flags should be added for that OS? We could add a special case for it, just as there is already a special case for IRIX 6.2. > why AC_SYS_LARGEFILE does not use getconf that is the > sdtandard interface to obtain {C,LD}FLAGS needed to compile program with LFS > support? I used tha

Re: AC_SYS_LARGEFILE macro

>>>>> "Andrej" == Andrej Borsenkow <[EMAIL PROTECTED]> writes: Andrej> So, the question is - why AC_SYS_LARGEFILE does not use Andrej> getconf that is the sdtandard interface to obtain {C,LD}FLAGS Andrej> needed to compile program with LFS support? Nothing

AC_SYS_LARGEFILE macro

I was about to replace our custom check for LFS flags with AC_SYS_LARGEFILE but found that it is no real replacement. It checks only for specific option for IRIX and _FILE_OFFSET_BITS and _LARGE_FILES macros. That is not enough; e.g. on our system: bor@itsrm2% getconf LFS_CFLAGS