Re: [PATCH] Makefile: update the default build options for AIX

[Johannes Sixt <j.sixt@viscovery.net>]

Mike Ralphson schrieb:
> 2008/5/7 Johannes Sixt <j.sixt@viscovery.net>:
>>  I'm trying this patch on AIX 4.3.3 (sigh!) with gcc3. I get this:
>>
>>  git-compat-util.h:209:1: warning: "fopen" redefined
>>  In file included from git-compat-util.h:51,
>>                  from builtin.h:4,
>>                  from git.c:1:
>>  /usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/3.2.1/include/stdio.h:110:1:
>>  warning: this is the location of the previous definition
>>
>>  Line 110 in ...include/stdio.h is inside a #ifdef _LARGE_FILES section and
>>  says:
>>
>>  #define fopen fopen64
>>
>>  Did you also get this warning? Is _LARGE_FILES support solved in a
>>  different way on 5.3?
> 
> The warning (I get rather a lot of them) is caused by the
> compat/fopen.c included when FREAD_READS_DIRECTORIES is defined. I
> tried moving the #undef fopen to git-compat-util.h but that resulted
> in a broken build and me reaching the end of my limited ability with
> c.
> 
> In file included from cache.h:4,
>                  from daemon.c:1:
> git-compat-util.h:209:1: warning: "fopen" redefined
> In file included from git-compat-util.h:51,
>                  from cache.h:4,
>                  from daemon.c:1:
> /opt/freeware/lib/gcc-lib/powerpc-ibm-aix5.3.0.0/3.3.2/include/stdio.h:110:1:
> warning: this is the location of the previous definition

So you we in the same boat.

> The warnings are harmless, though untidy.
> I don't believe it's anything to do with _LARGE_FILES. Could you try
> building first with one commented out, then the other? I don't think I
> have access to a 4.3.3 box any more.

Untidy, yes; harmless: not necessarily. It has a lot to do with _LARGE_FILES.

The #define fopen in git-compat-util.h essentially defeats the effect of
_LARGE_FILES as far as fopen() calls are concerned: If
FREAD_READS_DIRECTORIES is not defined, fopen() would be redirected to
fopen64(), but when it is defined, it is redirected to git_fopen(), which
in turn uses fopen() instead of fopen64() (due to the #undef in
compat/fopen.c).

This might be dangerous if some other function of the f*64() family uses
the FILE* that the fopen() call returned. I don't know if there is such a
usage pattern somewhere in git.

Why did you need _LARGE_FILES in the first place?

-- Hannes