[Mesa-dev] [PATCH] configure: Enable large file support for the 32-bit platforms

Lauri Kasanen cand at gmx.com
Sat Feb 1 02:21:26 PST 2014


On Sat, 1 Feb 2014 11:36:07 +0200
Lauri Kasanen <cand at gmx.com> wrote:

> On Fri, 31 Jan 2014 13:28:48 -0800
> Carl Worth <cworth at cworth.org> wrote:
> 
> > Lauri Kasanen <cand at 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.

Typo, s/UINT/INT/.

- Lauri


More information about the mesa-dev mailing list