On Sat, 1 Feb 2014 11:36:07 +0200 Lauri Kasanen <[email protected]> wrote:
> On Fri, 31 Jan 2014 13:28:48 -0800 > Carl Worth <[email protected]> wrote: > > > Lauri Kasanen <[email protected]> writes: > > >> 32-bit use is on the increase due to Steam; avoid any surprises > > >> and make Mesa LFS-aware. > > ... > > >> AC_PROG_MKDIR_P > > >> +AC_SYS_LARGEFILE > > > > Hi Lauri, > > > > Can you describe a bit more what failure modes you encounter without > > AC_SYS_LARGEFILE in place? I just haven't dealt with this macro, (nor > > the resulting compiler options), before and am wanting to understand > > things a bit better. > > It uses the experience gathered in autoconf to enable large file > support on all platforms. For 32-bit Linux, it adds -D_LARGEFILE_SOURCE > and -D_FILE_OFFSET_BITS=64. For other platforms, other magic is used. > On 64-bit linux, it is a no-op. > > This means that all IO calls automatically and transparently handle > files above 2gb. Without this, you get a cap at 2gb for both read and > write, which can be quite unexpected. > > I hit this in some submitted memory traces from 32-bit platforms. They > were capped at exactly UINT_MAX bytes. This code is not in mesa, but > it's not hard to imagine other dumps, or perhaps reading a big binary > shader exceeding 2gb. > > > > Ping. Having this done in autoconf is much better than the current > > > hardcoding done in vmware svga build files. > > > > Does that suggest that the patch should also be removing some of these > > hard-coded options? > > Yes. I didn't do it, because I've no way to test the SVGA driver. Typo, s/UINT/INT/. - Lauri _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
