On Sat, Feb 11, 2023 at 08:43:07PM +0100, Helge Deller wrote: > Actually, most packages already enable LFS by default (e.g by checking and > using the _FILE_OFFSET_BITS=64 possibility, or by using future=+lfs), so there > are not so many packages left....
OK, so I made some tests in order to enable this in gdnsd. FTR, I also found out there is a way to do this it in an upstreamable way as well, which would mean adding AC_SYS_LARGEFILE to configure.ac. I then tried to build it on i386. The build succeeded, but the test suite failed, and in particular the 011upthresh/037up_thresh.t and ./018admin/044admin.t tests. Upon further examination, it looks like the failures are related to the mon plugin, emitting "state file [...] deleted, clearing any forced states..." instead of "(re-)loading state file ...". The former comes from admin_deleted_file(), which in turn is called from admin_timer_cb(), guarded behind an "if (afw->attr.st_nlink)", which takes a different code path under _FILE_OFFSET_BITS=64. "afw" is an ev_stat structure, from libev. libev in its manpage, ev(3), documents this: "When using the library from programs that change the ABI to use 64 bit file offsets the programs will fail. In that case you have to compile libev with the same flags to get binary compatibility. This is obviously the case with any flags that change the ABI, but the problem is most noticeably displayed with ev_stat and large file support. The solution for this is to lobby your distribution maker to make large file interfaces available by default (as e.g. FreeBSD does) and not optional. Libev cannot simply switch on large file support because it has to exchange stat structures with application programs compiled using the default compilation environment." 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). This is all new to me, so let me know if I'm mistaken in my understanding or reasoning here. Regards, Faidon