Linux has adopted the Solaris scheme to stick to the old api-calls that assume 32bit-off_t by default. [1] But that is not only for old software binaries, the header files in the system are made in a way that they are 32bit-off_t by default as well. That makes sure that plugins and libraries fit together with older applications and other binaries.
And the same time, an urgent need comes up to support large filesystems, and the Unix98 standard does enforce it in that it requires all the basic binaries (in /bin and /usr/bin) to be compile as largefile binaries with atleast 64bit-off_t. To be able to have sources to run in both respects, it was chosen that a software flags its wish to be largefile by getting compiled as
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
which will magically shift off_t into a 64bit quanitity and also divert all calls like "open()" to their transitional 64bit sisters like "open64()" - without a need to change the sourcecode, atleast not that much. Sourcecode that is portable to freeBSD should be able to compile as largefile-code in a small-type environemt anyway.
The ability to set the size of off_t however has drawbacks whenever it comes to dynamic linking - they can make for all types of mismatches described in other sections on the site. In essence, it should be ensured that only binaries get linked that match in their call-model with respect to 32bit-off_t or 64bit-off_t.
Since some software is required to be largefile, one should give the advise to system makers to compile all newer software as 64bit-off_t, making 64bit the default. Only a handful of selected software should be picked that will run non-largefile for a need of compatibility with other older software. That can also prepare a change to a world of 64bit off_t binaries alone.
[1] the 32bit default stems from the fact that the lseek-calls were defined originally using "long" for the offset-argument. The calls were kept on the binary level and just the header files changed with the introduction of a `typedef long off_t`. Note that linux/solaris sources compiled as 64bit applications (e.g. sparc64) are therefore using a 64bit-off_t simply because the underlying type `long` is shifted into a 64bit-entity for a 64bit target-cpu. (See discussion about "64-bit and data size neutrality" leading to the widespread adoption of the LP64 model for 64bit unix machines.)