Thread (12 messages) flat view 12 messages, 4 authors, 2016-06-15

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

From: Johannes Sixt <hidden>
Date: 2016-06-15 22:44:34

Mike Ralphson schrieb:
2008/5/7 Johannes Sixt [off-list ref]:
quoted
 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help