Need check for large file support

[tp-m]

I think we should have some kind of replacement for AC_SYS_LARGEFILE. This is something very common, but there may be more things in future.

So question is how/where to best do this.

1. Just always check for it and add the required defines/flags to global/project args, and enable by default.

2. Provide a method in meson main

3. Add a new sys module or such and add a method there

4. Anything else?

[nirbheek]

My opinion is that large file support is always available these days (was introduced in 1996), so we should just enable it without checking for it.

The other question is whether there are legitimate uses where people don't want to enable large file support even when it is available. I don't think there are, but it's possible that there are such uses. We can either add support for disabling it from the start, or just always enable it and change it back if people complain.

[nirbheek]

As a data point, this is a Linux-only quirk (probably for backwards-compat in glibc). Bionic, FreeBSD, and Darwin always enable large file support. However, even on Linux if you disable large-file support, stat and friends will try to return 64-bit inode values and you will get EOVERFLOW.

[jpakkane]

Probably the only OS that does 32 bit file sizes is Windows and if you are using Windows native system calls you already know what you are doing.

[nirbheek]

Yes, on Windows you have to use _fseeki64 because fseek only takes a long: https://msdn.microsoft.com/en-us/library/75yw9bf3.aspx

The thing is on Linux you need to still set compiler flags to get large-file support; specifically you need to set _FILE_OFFSET_BITS and _LARGE_FILES. The details are in the AC_SYS_LARGEFILE macro. Without this, open() returns EOVERFLOW when you try to open large files with gstreamer on 32-bit Linux.

[tp-m]

For what it's worth AC_SYS_LARGEFILE also adds

#ifndef _DARWIN_USE_64_BIT_INODE
#define _DARWIN_USE_64_BIT_INODE
#endif

to config.h (unconditionally, mind). Don't know if it's still needed these days or not.

[nirbheek]

Actually, I now remember that all versions of OS X are now 64-bit so it doesn't matter for Darwin.

[tp-m]

So what shall we do about this? I think just enabling it unconditionally based on platform is fine, with or without checking. But where does this go implementation-wise? just add to global args?

[nirbheek]

I think unconditionally based on platform is fine without checking. We can change it if people complain about their precious ancient-kernel-or-libc broken 32-bit platforms.

Implementation-wise, it would go in global C and C++ args, but I haven't decided exactly which part of the code is best for adding it. For instance, we definitely want these to also be added when building C code generated by Vala, and also when doing compiler checks.

[nirbheek]

Reference material found by @tp-m

http://www.unix.org/version2/whatsnew/lfs20mar.html#1.1
https://github.com/JoseGalRe/Heimdall/blob/master/cmake/LargeFiles.cmake
https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html