Large file support on 32-bit systems

[Uri Simchoni]

OK I did something like that, and the result is in the attached patch set.

Part 1 - fix the specific problem at hand
Part 2 - fix similar cases (not that I know  of bugs, but just to
maintain the  convention)
Part 3 - the patch to the build system that produced part 2. Not sure
it can be pushed as-is because it appears to be a modification to waf
itself, and also the test may be too glibc-spcific (not sure how to
detect glibc)

Basically the build patch detects config.h being included after
features.h, with two classes of exceptions:
- Files including Python.h - this is because reversing the order
yields some warnings, plus the pyconfig.h already defines
_FILE_OFFSET_BITS, plus there are some pidl-generated files which
include python before includes.h.
- Any file which has SAMBA_CONFIG_NOT_FIRST defined - this is to work
around an issue with vfs_btrfs.c. So I suppose the btrfs module has to
be reviewed carefully for issues in that regard.

Thanks,
Uri

On Thu, Jul 2, 2015 at 3:27 PM, Ralph Böhme <rb at sernet.de> wrote:
> On Thu, Jul 02, 2015 at 03:01:20PM +0300, Uri Simchoni wrote:
>> Hi,
>>
>> I detected the following large-file support bug in lib/util/util.c:
>> - I have a 32-bit system
>> - The configuration process added _FILE_OFFSET_BITS=64 into config.h
>> (that is, it detected that the system does not support large files
>> without adding something, and found the correct thing to add - so far
>> so good).
>> - However, in lib/util/util.c, <talloc.h> is included before
>> "replace.h", and this causes off_t to be 32 bits (because what matters
>> is whether _FILE_OFFSET_BITS set to 64 on the FIRST time glibc's
>> features.h is included)
>> - This causes  fcntl_lock() to fail on 32-bit x86 (i686), and all the
>> daemons fail to run because they fail to generate a lock file.
>>
>> A workaround is to add _FILE_OFFSET_BITS=64 to the external CPPFLAGS,
>> but if this is the recommended method, then configure should simply
>> fail if it cannot get large files, and not add stuff to config.h.
>>
>> Another possible fix is to switch the order of talloc.h and replace.h
>> - this is fragile and there may be other places that need fixing.
>> Still this may be the right fix because if we cannot trust config.h
>> then who knows what else we get wrong. In that case the question is
>> how to detect files in which config.h is not first.
>
> Maybe this would work:
>
> $ make clean
>
> Add something like this to the top of bin/default/include/config.h
>
> #ifdef _YIKES
> #error YIKES!
> #endif
>
> # cp /usr/include/features.h /usr/include/features.h.bak
>
> Then add something like
>
> #define _YIKES
>
> $ make
>
> Explodes right away at:
> ...
> [ 488/2643] Compiling lib/util/util.c
> In file included from ../lib/replace/replace.h:32:0,
>                  from ../lib/util/util.c:26:
> default/include/config.h:6:2: error: #error YIKES!
>  #error YIKES!
>   ^
>
> Afaict the right thing to do is to make sure "replace.h" is included
> first.
>
> -Ralph
>
> --
> SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> phone: +49-551-370000-0, fax: +49-551-370000-9
> AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
> http://www.sernet.de,mailto:kontakt@sernet.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_lfs.patch
Type: application/octet-stream
Size: 6645 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150703/e314c4b5/attachment.obj>