Hello Faidon,
On 2/20/23 09:38, Faidon Liambotis wrote:
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."
Ah - ok.
The libev is a problem ATM.
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?
Helge
diff -up ./src/zsrc_rfc1035.c.org ./src/zsrc_rfc1035.c
--- ./src/zsrc_rfc1035.c.org 2023-02-26 11:49:06.574001459 +0000
+++ ./src/zsrc_rfc1035.c 2023-02-26 11:50:00.918521407 +0000
@@ -17,6 +17,7 @@
*
*/
+#define _LARGEFILE64_SOURCE /* allow readdir64() */
#include <config.h>
#include "zsrc_rfc1035.h"
@@ -256,10 +257,10 @@ bool zsrc_rfc1035_load_zones(ltree_node_
zf_threads_t* zft = zf_threads_new(gcfg->zones_rfc1035_threads);
bool failed = false;
- const struct dirent* result = NULL;
+ const struct dirent64* result = NULL;
do {
errno = 0;
- result = readdir(zdhandle);
+ result = readdir64(zdhandle);
if (likely(result)) {
if (result->d_name[0] != '.') {
struct stat st;
