Re: [PATCH] Makefile: update the default build options for AIX
- From
Johannes Sixt <j.sixt@viscovery.net>
- Date
- May 7, 2008, 13:14 UTC
- Message-ID
- <4821AB32.8090700@viscovery.net>
- In-Reply-To
- <e2b179460805070551x7a0072e0w4d406ef4112849ce@mail.gmail.com>
Mike Ralphson schrieb:
Show 32 quoted lines
> 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