[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[pogma at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

Peter O'Gorman <pogma at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #21 from Peter O'Gorman <pogma at gcc dot gnu.org> 2010-12-27 19:38:47 UTC ---
Fixed since 4.4.0

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[bugzilla-gcc at thewrittenword dot com]

------- Comment #3 from bugzilla-gcc at thewrittenword dot com  2006-02-22 23:43 -------
Any plans to add _LARGE_FILES support to g++/libstdc++ for AIX?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[haubi at gentoo dot org]

------- Comment #4 from haubi at gentoo dot org  2007-12-01 22:04 -------
Same here with gcc-4.2.2 and powerpc-ibm-aix5.3.0.0.

Some diagnostics what happens when _LARGE_FILES (and _LARGE_FILE_API) is
defined:

<sys/types.h>

/* would both be 'long' without _LARGE_FILES: */
typedef long long fpos_t;
typedef long long off_t;

/* because of _LARGE_FILE_API: */
typedef long long   off64_t;

<stdio.h>

/* because of _LARGE_FILES (the 'problematic' ones): */
#define fseeko fseeko64
#define ftello ftello64
#define fgetpos fgetpos64
#define fsetpos fsetpos64
#define fopen fopen64
#define freopen freopen64

/* these actually are declared as f*64() because of defines above: */
extern FILE *fopen(const char *, const char *);
extern FILE *freopen(const char *, const char *, FILE *);
extern int   fgetpos(FILE *, fpos_t *);
extern int   fsetpos(FILE *, const fpos_t *);
extern int   fseeko(FILE *, off_t, int);
extern off_t ftello(FILE *);

/* because of _LARGE_FILE_API: */
extern int fgetpos64(FILE *, fpos64_t *);
extern FILE *fopen64(const char *, const char *);
extern FILE *freopen64(const char *, const char *, FILE *);
extern int fseeko64(FILE *, off64_t, int);
extern int fsetpos64(FILE *, const fpos64_t *);
extern off64_t ftello64(FILE *);

<cstdio>

/* remember: these actually are declared as f*64(),
 * while the original ones are undeclared.
 */
#undef fgetpos
#undef fopen
#undef freopen
#undef fsetpos

namespace std {
  using ::fpos_t;
  using ::fgetpos;
  using ::fopen;
  using ::freopen;
  using ::fsetpos;
}


I'm unsure how to 'fix' that 'correctly' - one suggestion is to 'fixincludes':

Add this just _before_ those '#define fopen fopen64' lines in <stdio.h>

  static FILE *fopen(const char *a, const char *b) { return fopen64(a,b); }

Eventually there is a better way to redirect from 'fopen' to 'fopen64' on aix
also for the compiler - not just the preprocessor.


-- 

haubi at gentoo dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |haubi at gentoo dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[haubi at gentoo dot org]

------- Comment #5 from haubi at gentoo dot org  2007-12-19 15:57 -------
Created an attachment (id=14796)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14796&action=view)
the effect fixincludes could have on aix5.2/aix5.3

When applying this patch to (already fixed) stdio.h on aix5.2/aix5.3, compiling
"#include <iostream>" with -D_LARGE_FILES works. But I have no clue on how to
create entries with this effect in inclhack.def, or if this is the way to go.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[tcoleman at autowares dot com]

------- Comment #6 from tcoleman at autowares dot com  2007-12-20 00:06 -------

The test program will compile if you comment out the #undefs in cstdio.

//#undef fgetpos
//#undef fopen
//#undef freopen
//#undef fsetpos

I've wrestled with this problem with G++ on AIX for years.  In desparation I
just had our admin load the IBM 4.0.0 RPMs - same problem!

This is the second time this error has prevented me from porting a relatively
simple application to AIX.

This particular problem has gone on long enough.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[dsanderson at panasas dot com]

------- Comment #7 from dsanderson at panasas dot com  2007-12-20 00:17 -------
Note that my originally stated workaround -- to compile with -maix64 -- doesn't
really work beyond helping the compile to succeed.  Using -maix64 gives you a
64-bit executable (e.g. with 64-bit pointers and a 64-bit off_t) that can't
access large files.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[dje at gcc dot gnu dot org]

------- Comment #8 from dje at gcc dot gnu dot org  2007-12-21 00:29 -------
The issue is whether to default G++ to _LARGE_FILES, as is done for Fortran,
and perform all libstdc++ I/O as 64-bit operations, which will affect
performance.  Not everyone may want or need large I/O.  There is no way to give
users control over this without imposing it so G++, G++ headers, and libstdc++
all are self-consistent.  The other alternative is another multilib, but there
alredy are too many variants.


-- 

dje at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-12-21 00:29:21
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[bugzilla-gcc at thewrittenword dot com]

------- Comment #9 from bugzilla-gcc at thewrittenword dot com  2007-12-21 03:59 -------
(In reply to comment #8)
> The issue is whether to default G++ to _LARGE_FILES, as is done for Fortran,
> and perform all libstdc++ I/O as 64-bit operations, which will affect
> performance.  Not everyone may want or need large I/O.  There is no way to give
> users control over this without imposing it so G++, G++ headers, and libstdc++
> all are self-consistent.  The other alternative is another multilib, but there
> alredy are too many variants.

Why is this? -D_LARGE_FILES simply enables LFS. xlC works with and without
-D_LARGE_FILES. Shouldn't G++ work as effectively as xlC?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[dje at watson dot ibm dot com]

------- Comment #10 from dje at watson dot ibm dot com  2007-12-21 14:58 -------
Subject: Re:  AIX g++ -D_LARGE_FILES fails to compile #include <iostream> 

> Why is this? -D_LARGE_FILES simply enables LFS. xlC works with and without
> -D_LARGE_FILES. Shouldn't G++ work as effectively as xlC?

        You are mixing multiple questions and issues.

        -D_LARGE_FILES redefines all I/O functions to use the 64-bit
versions. 

        xlC has its own system header files.  G++ needs to use the AIX
system header files with changes from fixincludes, combined with libstdc++
header files that perform their own redefinitions.

        "Shouldn't G++ work as effectively..." is a business question, not
a technical question.  Many major AIX customers use GCC, but none have
told IBM that they will not buy a system unless GCC works better.  That
sets investment priorities.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[bugzilla-gcc at thewrittenword dot com]

------- Comment #11 from bugzilla-gcc at thewrittenword dot com  2007-12-21 19:14 -------
(In reply to comment #10)
> Subject: Re:  AIX g++ -D_LARGE_FILES fails to compile #include <iostream> 
> 
>         xlC has its own system header files.  G++ needs to use the AIX
> system header files with changes from fixincludes, combined with libstdc++
> header files that perform their own redefinitions.

Agreed. So, all that's left is for someone to do the work. I forgot about the
libstdc++ headers that would need to change. We're going to try and have
someone here work on this in the next 1-2 months as we're getting bitten by
this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[dje at gcc dot gnu dot org]

------- Comment #12 from dje at gcc dot gnu dot org  2007-12-21 23:23 -------
If AIX G++ users are focussing on 64-bit apps and large files, I'm willing to
switch the default to _LARGE_FILES.  The changes would be in
gcc/config/rs6000/aix*.h CPP_SPEC and libstdc++/config/os/aix/os_defines.h,
plus any fallout from the change.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[bugzilla-gcc at thewrittenword dot com]

------- Comment #13 from bugzilla-gcc at thewrittenword dot com  2007-12-21 23:25 -------
(In reply to comment #12)
> If AIX G++ users are focussing on 64-bit apps and large files, I'm willing to
> switch the default to _LARGE_FILES.  The changes would be in
> gcc/config/rs6000/aix*.h CPP_SPEC and libstdc++/config/os/aix/os_defines.h,
> plus any fallout from the change.

We only care about -D_LARGE_FILES to support files >2G while running a 32-bit
app. We're not building any 64-bit apps.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[tcoleman at autowares dot com]

------- Comment #14 from tcoleman at autowares dot com  2007-12-22 20:18 -------
(In reply to comment #12)

I don't see it as so much a matter of "focus".  

A lot of applications test for _LARGE_FILES in the C library and will set it as
a configuration option if supported.  As far as straight C goes, there's no
problem with gcc on AIX.

But if _LARGE_FILES is set, the fact that g++ can't compile C++ applications
using cstdio on AIX is a source of both frustration and annoyance.

Does G++ really have to be either one way or the other?  Can't it also include
conditional code to check for _LARGE_FILES?  Maybe I'm missing something here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[dje at watson dot ibm dot com]

------- Comment #15 from dje at watson dot ibm dot com  2007-12-22 20:52 -------
Subject: Re:  AIX g++ -D_LARGE_FILES fails to compile #include <iostream> 

>>>>> tcoleman at autowares dot com writes:

Tom> Does G++ really have to be either one way or the other?  Can't it also
include
Tom> conditional code to check for _LARGE_FILES?  Maybe I'm missing something
here.

        GNU libc does not use _LARGE_FILE to distinguish large offsets in
32-bit file I/O.  Why would the GCC libstdc++ community be interested in
complicating its header files with AIX-specific checks?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[peter at pogma dot com]

------- Comment #17 from peter at pogma dot com  2007-12-31 19:28 -------
(In reply to comment #16)

> This was also a problem on solaris:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4850

I mean

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4886


-- 

peter at pogma dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter at pogma dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[bugzilla-gcc at thewrittenword dot com]

------- Comment #18 from bugzilla-gcc at thewrittenword dot com  2007-12-31 19:39 -------
(In reply to comment #16)
> Because it is not currently possible to build an autoconf based project on aix
> with gcc without doing --disable-largefile, we would like to see this fixed.

More accurately, it is possible to use `gcc' and large files, just not `g++'
and large files.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[bugzilla-gcc at thewrittenword dot com]

------- Comment #19 from bugzilla-gcc at thewrittenword dot com  2008-03-03 21:12 -------
Proposed patch:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00162.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[rwild at gcc dot gnu dot org]

------- Comment #20 from rwild at gcc dot gnu dot org  2008-03-07 06:54 -------
Subject: Bug 20366

Author: rwild
Date: Fri Mar  7 06:53:59 2008
New Revision: 133001

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133001
Log:
fixincludes/
2008-03-07  Peter O'Gorman  <pogma@thewrittenword.com>

        PR c++/20366
        * inclhack.def (AAB_aix_stdio): Hack stdio.h for -D_LARGE_FILES.
        * fixincl.x: Regenerate.
        * tests/base/stdio.h: Add test.

gcc/testsuite/
2008-03-07  Peter O'Gorman  <pogma@thewrittenword.com>

        PR c++/20366
        * g++.dg/other/pr20366.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/other/pr20366.C
Modified:
    trunk/fixincludes/ChangeLog
    trunk/fixincludes/fixincl.x
    trunk/fixincludes/inclhack.def
    trunk/fixincludes/tests/base/stdio.h
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[pogma at gcc dot gnu dot org]

-- 

pogma at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pogma at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
      Known to work|                            |4.4.0
   Last reconfirmed|2007-12-21 00:29:21         |2008-04-04 05:31:57
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug c++/20366] New: AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[gcc-bugzilla at gcc dot gnu dot org]

	The compiler's C++ headers do not appear to work properly on AIX when
	the compiler is run with -D_LARGE_FILES.  This macro causes the
	system headers to #define symbols like fopen, while the C++ headers
	unconditionally #undef these symbols.

Environment:
System: AIX bigblue 2 5 000F699D4C00


	
host: powerpc-ibm-aix5.2.0.0
build: powerpc-ibm-aix5.2.0.0
target: powerpc-ibm-aix5.2.0.0
configured with: /usr0/slammert/gcc-3.4.3/configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld --disable-nls --enable-languages=c,c++ --enable-threads --enable-version-specific-runtime-libs

How-To-Repeat:
	On AIX 5.2, compile the following program with
	3.4.3 g++ -D_LARGE_FILES:

	    #include <iostream>
	    int main(void) { return 0; }

	You will get output similar to the following:

	    In file included from /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/powerpc-ibm-aix5.2.0.0/bits/c++locale.h:43,
			     from /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/iosfwd:46,
			     from /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/ios:44,
			     from /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/ostream:45,
			     from /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/iostream:45,
			     from bug0.C:1:
	    /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/cstdio:108: error: `::fgetpos' has not been declared
	    /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/cstdio:110: error: `::fopen' has not been declared
	    /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/cstdio:115: error: `::freopen' has not been declared
	    /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/cstdio:118: error: `::fsetpos' has not been declared
------- Additional Comments From dsanderson at panasas dot com  2005-03-07 19:12 -------
Fix:
	I can work around this problem and still compile a program with a
	64-bit off_t by compiling with -maix64 instead of -D_LARGE_FILES.

-- 
           Summary: AIX g++ -D_LARGE_FILES fails to compile #include
                    <iostream>
           Product: gcc
           Version: 3.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dsanderson at panasas dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-ibm-aix5.2.0.0
  GCC host triplet: powerpc-ibm-aix5.2.0.0
GCC target triplet: powerpc-ibm-aix5.2.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include <iostream>

[dje at gcc dot gnu dot org]

------- Additional Comments From dje at gcc dot gnu dot org  2005-03-07 19:30 -------
G++ and libstdc++ on AIX currently is configured to enable _LARGE_FILE_API, 
but not _LARGE_FILES.  _LARGE_FILE_API exposes the 64-bit functions with 
separate names off64_t and fopen64(), but does not redefine the original 
functions with their counterparts supporting 64-bit types.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366