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

From: Mike Ralphson <mike.ralphson@gmail.com>
Date: May 7, 2008, 14:20 UTC
Message-ID: <e2b179460805070720o4028a841t6eabe9c1668a7a9f@mail.gmail.com>
In-Reply-To: <4821AB32.8090700@viscovery.net>

2008/5/7 Johannes Sixt <j.sixt@viscovery.net>:

Show 24 quoted lines

> Mike Ralphson schrieb:
>
> > 2008/5/7 Johannes Sixt <j.sixt@viscovery.net>:
>  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?

Welcome aboard!

I was seeing test failures in t5302-pack-index.sh

Specifically tests 9 and 20 # 9: index v2: force some 64-bit offsets with pack-objects # 20: create a stealth corruption in a delta base reference

These tests seem to be skipped these days if off_t isn't large enough, I preferred the passing tests to the skipped ones. Maybe it isn't an issue in the real world.

Mike