On 2/11/23 19:21, Faidon Liambotis wrote:
On Sat, Feb 11, 2023 at 06:53:16PM +0100, Helge Deller wrote:
I'm not very familiar with the LFS work; could you help me understand a
bit better the need for adding this flag? Is this an MBF or something
specific to gdnsd? Why would this need to be tuned at the package level?
Read this article, it explains it quite well:
https://www.mjr19.org.uk/sw/inodes64.html
[...]
Also, is this hppa-specific? I only see FTBFS on hppa in the buildd
network but no other 32-bit architectures?
All 32-bit archiectures are affected, but they were lucky during build.
It just shows up on hppa, because I use large discs on the hppa buildd servers,
but at runtime it may fail for everyone (on 32-bit) if they use big discs.
Thank you for that link, that's helpful!
But perhaps this doesn't address my underlying question. The offending
code is:
DIR* zdhandle = opendir(rfc1035_dir);
const struct dirent* result = NULL;
result = readdir(zdhandle);
if (likely(result)) {
...
} else if (errno) {
log_err("rfc1035: readdir(%s) failed: %s", rfc1035_dir,
logf_errno());
failed = true;
}
So it's all pretty basic, and there is nothing inherrently special with
what gdnsd is doing. Is there?
Yes, it is.
"struct dirent" will become a 64-bit ready dirent struct when compiled with
FILE_OFFSET_BITS=64, and readdir() will call the readdir64() syscall instead
of the 32-bit readdir() kernel function.
If you leave it as-is, readdir() will fail if the file (dir entry) is located
above
2GB on the filesystem.
glibc will automatically choose the correct struct/call it for you if compiled
with the flags.
Why do I need to handle this in a special way in a leaf package?
See above.
Does this mean that a bug needs to be filed and
d/rules to be adjusted for every package that uses readdir()? That's a
pretty massive MBF and I don't think it would scale very well :)
Yes, correct.
That's why the debian BTS has the "LFS" tag.
There are thoughts to generally enable LFS for 32-bit buildds, but not
during the freeze...
Helge
