Hi Helge, On Sun, Feb 26, 2023 at 01:06:16PM +0100, Helge Deller wrote: > > So, from what I can tell, this is not something that I can fix locally > > within gdnsd right now. AIUI what would need to happen is that libev > > would need to be build with LFS support first, which would mean > > rebuilding it with future=+lfs, breaking its ABI in the process, > > requiring an ABI bump, and in turn a transition during which all of its > > reverse dependencies will need sourceful uploads as to be modified to > > also pass future=+lfs/-D_FILE_OFFSET_BITS=64, and then to be rebuilt > > themselves (and possibly also affecting their reverse-dependency chains > > as well). > > Correct. Not something which is possible now. > > But I have another idea. > We don't need to touch libev for now. > Instead the only thing which currently may fail is the readdir() in > src/zsrc_rfc1035.c. If we get this call to use the 64-bit variant we > are done. > > Attached is a proposed patch. It just changes this specific readdir() > and is independend of libev. > I've sucessfully tested it on the hppa architecture, and I hope it > compiles the same way on all other platforms too. > Could you check?
I don't think that's right. I think there are two independent LFS issues with current builds of gdnsd: 1) the readdir() call in the rfc1035 zonefile parser (src/zsrc_rfc1035.c) 2) the stat() calls, via ev_stat_init etc., in the mon and extfile plugins. These two issues are in different parts of gdnsd, and independent from each other. (1) is contained within gdnsd, and thus building with future=+lfs, as you originally suggested, addresses this issue. Your readdir64() patch also addresses this issue, and is functionally the same in that regard: AIUI with _FILE_OFFSET_BITS=64, glibc implements readdir() with a readdir64() system call. However, (2) is not self-contained, with stat structures crossing an ABI boundary (libev's). Hence why the test suite (legitimately) fails when building with future=+lfs. My understanding is that patching (1) with the patch you attached, but not building with future=+lfs, ill effectively still create a binary that does not have large file/inode support, as the stat() calls that the mon/extfile plugins make, will not work on 64-bit inode filesystems. Does this make sense? Faidon
