On Fri, 31 Jan 2014 13:28:48 -0800 Carl Worth <cwo...@cworth.org> wrote:
> Lauri Kasanen <c...@gmx.com> 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. - Lauri _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
