Disable large file support on old glibc

[sjmulder]

On glibc <2.23 fts.h doesn't support the feature:

https://sourceware.org/bugzilla/show_bug.cgi?id=11460

In file included from src/nnn.c:78:0:
/usr/include/fts.h:41:3: error: #error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
 # error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"

[N-R-K]

This was discussed here: #1678 (comment)

I don't think we want to keep adding workarounds for buggy libc behavior which have been fixed for almost a decade now.

[N-R-K]

I don't think this is a public header for us to be including.

[sjmulder]

I wasn't aware of this but indeed feature_test_macros(7) documents this. I can shuffle includes around a bit to avoid this if you're not against this PR a priori.

[N-R-K]

It's upto @jarun to make the call. I personally don't think trying to work around a decade old glibc bug is worth it, especially since glibc maintainers now recommend defining it unconditionally.

[sjmulder]

I understand the perspective but the one extra ifdef keeps nnn working on legacy platforms where system utilities like this remain useful. Note that RHEL 7 is still under extended lifecycle support. I'll keep it working in pkgsrc while I can but it would be nice if vanilla nnn kept working too.

[jarun]

I am fine with this. We should try to keep nnn working on older systems.

[N-R-K]

then unconditionally include one of the base headers like stddef.h to get the effects of features.h

This sounds okay.

That would assume it's okay to delay _FILE_OFFSET_BITS until after stddef.h

Unfortunately, I don't think this will work. From the feature_test_macros manpage:

"NOTE: In order to be effective, a feature test macro must be defined before including any header files"

[sjmulder]

_FILE_OFFSET_BITS is indeed checked by features.h, so a bit of a chicken and egg problem here.

[sjmulder]

I can't think of a way to do this correctly without a configure script. Unless you do I propose we close this PR and I think of something better (or leave it as is).

[N-R-K]

We have a bit of pseudo configure script going on in the Makefile over here

nnn/Makefile

Lines 189 to 190 in 86d883e

	# test if we are on Mac OS X and get X.Y.Z OS version with system binary /usr/bin/sw_vers
	MACOS_VERSION := $(strip $(shell command -v sw_vers >/dev/null && [ "`sw_vers -productName`" = "Mac OS X" ] && sw_vers -productVersion))

If you can do something like this without too much baggage (we don't want to slow down the build step noticeably) then that seems acceptable to me.

[N-R-K]

Here's a command that you can use to test glibc version in the makefile if you're still interested in pursuing this:

printf "#include <stdlib.h>\n#if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 23)\nYES\n#else\nNO\n#endif\n" | cc -E - | tail -n1

[sjmulder]

It's your call to make - the advantage is that nnn can still run older targets such as CentOS 7, at the cost of a bit of preprocessor crud. Functionally there's no degradation on platforms where nnn already works.

[jarun]

I am fine with this. We should try to keep nnn working on older systems.

[jarun]

Closing this since this is working for a very long time.