It should have been, eh.. another hack that GLIBC has but it’s transparent on FreeBSD… ok let summarize for who doesn’t know.
On 32-bit systems (the ones that used to be the most common, like x86 and ppc, and spac32), you can open a file just if it’s smaller than 2GiB, that because the offset in the file is represented by a long, so it’s 32-bit and so maxes out at 2GiB. To avoid this, there’s the “largefile” support, that should break binary compatibility but let opening files bigger than 2GiB.
Today is quite usual yo have files bigger than 2GiB… we have DVDs of (about) 4GiB and HDDs up to 320GB, so largefile support is logically enabled quite everywhere, but .. glibc doesn’t enable it by default, as FreeBSD does.

The result is that programs must enable it by themselves defining _FILE_OFFSET_BITS=64, usually calling AC_SYS_LARGEFILE in a script to let the configure find out what is needed.
Unfortunately, not all the programs do this, and also when they do, there are cases that makes them broken anyway.

amne yesterday made me notice that flac, lame and oggenc doesn’t use largefile.. and this is bad. flac is now fixed, I just needed to add AC_SYS_LARGEFILE call and a little hack to make sure that config.h is included everywhere. lame is fixed, too, also if it made me wondering for a bit because the call was already there, and the config.h was already included… it turned out that lame was using a custom without adding largefile definitions. From lame to toolame, the step was great… the latter doesn’t use autoconf, so I just worked that around appending flags in the ebuild.

Also, alsa-utils, that was already worked around in 1.0.9-r1, have now a proper fix for 1.0.10_rc1 (yeah I added all the 1.0.10_rc1 ebuilds yesterday, hardmasked for now), that I sent upstream and I hope it will be fixed for next version.

This is going to be a long day, a long day for sure.