largefile (LFS) issues

[glensc]

looks like ninja build on 32bit system is not largefile safe:

ninja: error: stat(build/build.o): Value too large for defined data type
ninja: error: stat(build/depfile_parser.o): Value too large for defined data type

the files are residing on 64bit-enabled inode (xfs, inode64 enabled since 2.6.35, see here):

➔ LC_ALL=C ls -li build/build.o build/depfile_parser.o misc/ninja_syntax.py
4846763977 -rw-r--r-- 2 glen users 790700 Oct 14 00:08 build/build.o
4846763974 -rw-r--r-- 2 glen users  58240 Oct 14 00:08 build/depfile_parser.o
4309918606 -rw-r--r-- 1 glen users   5428 Jun 28 02:37 misc/ninja_syntax.py

what's worse, build system does not abort but continues with ignoring such errors:

+ ninja -v
ninja: error: stat(misc/ninja_syntax.py): Value too large for defined data type
[1/26] src/inline.sh kBrowsePy < src/browse.py > build/browse_py.h
[2/26] re2c -b -i --no-generation-date -o src/depfile_parser.cc src/depfile_parser.in.cc
[3/26] re2c -b -i --no-generation-date -o src/lexer.cc src/lexer.in.cc
...
[13/26] ccache i686-pld-linux-g++ -MMD -MT build/eval_env.o -MF build/eval_env.o.d -g -Wall -Wextra -Wno-deprecated -Wno-unused-parameter -fno-rtti -fno-exceptions -fvisibility=hidden -pipe -Wno-missing-field-initializers '-DNINJA_PYTHON="python"' -O2 -DNDEBUG -DUSE_PPOLL -O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i686 -fasynchronous-unwind-tables -mtune=pentium4 -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2  -c src/eval_env.cc -o build/eval_env.o
ninja: error: stat(build/build.o): Value too large for defined data type  
ninja: error: stat(build/depfile_parser.o): Value too large for defined data type  
[14/26] ccache i686-pld-linux-g++ -MMD -MT build/graph.o -MF build/graph.o.d -g -Wall -Wextra -Wno-deprecated -Wno-unused-parameter -fno-rtti -fno-exceptions -fvisibility=hidden -pipe -Wno-missing-field-initializers '-DNINJA_PYTHON="python"' -O2 -DNDEBUG -DUSE_PPOLL -O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i686 -fasynchronous-unwind-tables -mtune=pentium4 -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2  -c src/graph.cc -o build/graph.o  

[evmar]

I have never seen 64-bit inodes before! But it appears they're just part of the newer LFS API? (Ninja doesn't care about file sizes so it's a little confusing that this is part of "largefile" support.)

Upon reading http://www.tcm.phy.cam.ac.uk/sw/inodes64.html , it sounds like it should just work if you compile a 64-bit binary. Are you on a 32-bit system?

[glensc]

yes, that is 32bit userspace. for autoconf build systems it's just sufficient to add AC_SYS_LARGEFILE to your configure.ac

[glensc]

and no, you should not compile 64bit binary, just need to compile 64bit file access pointers (off_t) on 32bit systems (ix86)

[glensc]

if you wish to reproduce this and do not have 1TB filesystem filled with files, you can try method described here: https://bugs.php.net/bug.php?id=68209

[evmar]

I see, thanks for explaining. (I see you mentioned a 32-bit system in your original report, sorry for missing it.)

According to http://people.redhat.com/berrange/notes/largefile.html we can add -D_LARGEFILE_SOURCE to our compile flags and it should work on systems that support it. Could you try that? You'll need it somewhere around here https://github.com/martine/ninja/blob/master/bootstrap.py#L108 and here https://github.com/martine/ninja/blob/master/configure.py#L146 .

PS for Nico: it appears OSX has a similar 64-bit inode variant, but it's handled more implicitly
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/stat64.2.html

[glensc]

any ideas about errors not triggering build failure?

[evmar]

I just opened #830 about that.

[arekm]

-D_LARGEFILE_SOURCE (stat will be wrapper to stat64) and -D_FILE_OFFSET_BITS=64 (off_t and ino_t will be 64bit) - both are needed. Only _LARGEFILE_SOURCE is not enough. On Linux/glibc at least.

[nico]

(the binaries at https://github.com/martine/ninja/releases are built with LFS support I believe)

[glensc]

@nico no, there is no 32bit binary for linux, only 64bit, where the problem doesn't exist. at least for 1.5.1 which seems to be latest

[nico]

Oh right, I remember now not uploading the 32bit binary here since I figured nobody would need it :-) There's one with LFS support at curl https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/master/ninja-linux32?format=TEXT | base64 --decode > ninja32 though, I think.

[nico]

(…and I think just adding -D_FILE_OFFSET_BITS=64 to CFLAGS while running ninja's configure.py is enough if I remember correctly. The commit log of http://src.chromium.org/viewvc/chrome?revision=243436&view=revision supports my memory.)

Is there anything for ninja itself to do here (other than failing when stat() fails, which Evan filed another issue for)?

[glensc]

i think ninja should include both flags as you pointed out yourself. referenced a patch just now

[nico]

It's only needed for 32bit linux though, and I'd think that almost nobody uses that on build machines.

[glensc]

well, if it's not in ninja upstream, sooner or later some other linux distro will report it again. unless they find this ticket that you strongly refuse to accept any patch :) i use "it" to build 32bit version of chromium on my linux distro.

[glensc]

why this is still not merged?

[jackpot51]

This issue is still present. 32-bit builds are still common for libraries like mesa, which uses ninja and must have 32-bit libraries in order to support 32-bit games.

[MagicalTux]

I use overlayfs which cause inode numbers to be large (64bits) values, which causes ninja to fail by default when running in 32bits env.

Adding -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 to CFLAGS allowed to have ninja works anyway, but this should probably be fixed in ninja I think (configure.py should detect 32bits env and add the appropriate cflags).

[vcunat]

Probably fixed by #2203
but it would be nice to release it.