On Nov 9, 2007, at 10:00 PM, bob wrote:
When you say toolchain, are you referring to the compiler
and associated libraries or are you referring to OS programs
such as ls, md5, cat, etc or both?
The reason that I ask is that I have been playing different
scenarios using git 1.5.3.5 under MacOSX 10.4.10 mostly
all day and every time that
A) a file approaches or exceeds 2gig on an 'add', it
results in:
fatal: Out of memory? mmap failed: Cannot allocate memory
B) the repository size less the .git subdirectory approaches
4gig on a 'fetch' it results in:
Resolving 3356 deltas...
fatal: serious inflate inconsistency: -3 (unknown compression method)
fatal: index-pack died with error code 128
fatal: Fetch failure: ../rmwHtmlOld
Under B, building the initial repository works fine.
(I added a patch the Linus Torvalds gave out when a previous
inflate problem
was being researched.) Also, I have been looking in the source
in particular in builtin-add.c builtin-pack-objects.c and
associated headers
and see int and unsigned long being used a lot, but not any
unsigned long
longs. I have been testing on my laptop which has a 32-bit Intel
Core Duo.
Also, I have run the same tests on a dual quad-core Intel processor
which is 64 bit, (but not sure that Apple uses the 64 bits in
10.4.10). I
get the same results as above.
The zlib is at the latest revision of 1.2.3 and gcc is at 4.0.1
which from what I can tell supports large files, because 'off_t' is
8 bytes
which is the size used for a 'stat' file size.
mmap(2), which git uses by default, is subject to vm limits
(typically <2GB), regardless of large file support. file `which git`
will probably tell you that it's a Mach-O executable i386 instead of
x86_64. In order to get 64 bit binaries on Mactel boxes, you'll need
the -m64 flag for gcc. I suspect that compiling with NO_MMAP option
work as well.
__Luke
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html