As noted before, most of these problems do only exist for systems
that provide a 64on32 option - they use 64bit file-offsets
internally on the side of the libC and OS-kernel. However, they
do export the standard library functions "lseek" and "fstat" as
32bit variants to support older binary programs. Applications can
can ask to have direct access to the largefile support with being
compiled as -D_FILE_OFFSET_BITS=64 which makes them
magically be linked to "lseek64" and "fstat64" replacement functions.
The libC happens to be a dualmode library and the C header files
play some dirty tricks to support that magic involved.
The unix98 standard mandates that the base utilities of the system must be compiled as 64bit largefile applications, and it is also best to compile libraries as 64bit largefile variants as well. However, care must be taken that library makers (and plugin writers) do ensure to not get unlucky with mixing up with application variants of a different off_t since that can easily lead to callframe mismatches or more subtle problems described in the sections before.
What can be changed about this situation?
Well, here are some options:
Add this macro to all autoconf'd software - or use the magic
define -D_FILE_OFFSET_BITS=64 if it is not autoconf'd.
Do not forget it and file bug reports to all software makers that
happen to forget about it. A tedious task, perhaps just send them
a http-reference to this website along (that might save you some breath).
Most packaging formats have a default setting for CFLAGS
to be used. Perhaps one could change this default to use 64bit on
platforms that allow 64bit file-access. A similar option was
discussed to make all autoconf'd software implicitly pick up
64bit-off_t default - perhaps with introducing an anti-option
AC_SYS_NO_LARGEFILE to suppress it.
All these suffer two problems (a) the software writers does not expect that implicit change. The same software might be compiled differently just depending on which version of the build tools are used. (b) CFLAGS are easy to override, and in packaging build-decriptions it happens to be quite often the case that the system default is either not used or actually overriden.
Therefore, this can still lead to mismatch problems with other libraries that a package depends on.
Most packaging system allow for checking the package after it has been build. It is possible to add a routine into the this post-packaging-check that looks for mismatch problems with the software around. That is also discussed in the section distro makers on this website.
This option does not make a silent change and instead it will warn software makers of problems that actually exist in a specific software environment. It is a good one to follow some time, IMO.
FreeBSD/darwin have chosen to use a 64bit largefile-access by default even on 32bit systems. They do not even offer 32bit file-access. That makes any problems of largefile mismatches impossible to happen.
A similar state can be reached on 64on32 systems by changing the default for the magic involved - just make 64bit off_t the default. With the magic involved, all new binaries will be linked to their cousins from the `transitional API`, i.e. fstat64 and friends. The old binaries are still supported as the standard 32bit "fstat" calls continue to exist.
At some point, the old 32bit export-functions can be dumped and the "fstat" and "fstat64" happen to be just aliases in the shared library export tables. That can be done some years after changing the default to 64bit off_t. Changing the default will ensure that all software starts using largefile and that it is not just forgotten to be enabled.
There might be software that will exhibit problems with 64bit off_t but that is highly improbable since most unix-compatible software had been ported at some time to a freeBSD/darwin-like system. A fix will surely be applied pretty soon. However, to change the default should be published widely - in linux perhaps when changing a major version of the software environment and telling what has been changed to justify the jump in the version number. It is easier for application makers to communicate a `compatible with / needs atleast XX version` marker than telling the customer about some `largefile compiled` software.