Hi Santiago,
On 1/24/23 20:07, Santiago Vila wrote:
El 24/1/23 a las 18:48, Helge Deller escribió:
Package: indent
Version: 2.2.12
Tags: hppa, patch, lfs, FTBFS
The indent package has a bug in the script "regression/TEST"
which starts with "#/bin/sh" instead of a correct
shebang which would be "#!/bin/sh". This leads to a FTBFS on
the hppa architecture when running virtualized in qemu-user.
Secondly it would be nice if the indent tool would be built
with large file support. Adding future=+lfs to DEB_BUILD_MAINT_OPTIONS
allows that.
Both are fixed with attached patch. Please apply for next upload.
Thanks for the report and the patch.
I'm curious about the LFS issue: Is it really a good idea to have a .c
file larger than 2GB? I did a quick search and found this tweet:
LFS is not just the 2GB limit (_LARGEFILE_SOURCE) when opening files.
I see in src/backup.c the readdir() glibc call is used, which
may fail randomly on big filesystems when built as 32bit binary.
See e.g: https://www.mjr19.org.uk/sw/inodes64.html
For that the define _FILE_OFFSET_BITS=64 is needed to work reliable.
https://twitter.com/cristalopes/status/776569616692752384
The largest C++ file we found in GitHub has 528Mb, 57 lines of code.
Contains the first 50,847,534 primes, all hard coded in an array.
So: What would be the rationale for adding LFS support to the indent program?
"Just in case"?
_FILE_OFFSET_BITS=64, needed for readdir() call.
Another question: I see there are now several ways to enable LFS. In procmail
I had this in debian/rules:
CFLAGS := $(shell dpkg-buildflags --get CFLAGS) $$(getconf LFS_CFLAGS)
Is that equivalent to using future=+lfs or are there any differences?
Yes, your above code should work:
(sid_hppa)deller@pacific:~/$ getconf LFS_CFLAGS
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
Those are the defines which are needed.
Btw, if you add the "_TIME_BITS=64" define too, your are even 64-bit ready...
Thanks!
Helge
