Looking through the upstream bug reports, all I found was: https://github.com/389ds/389-ds-base/issues/5962 which doesn't seem immediately related.
Adding the include to the relevant file (slap.h) seems to have addressed the compilation error and allows for simply rearranging the includes in the source file as you suggested. Frankly, I'm still unsure why that specific include bypasses the compilation error at all, but I've attached a new diff. ** Patch added: "389-ds-base_2.4.4+dfsg1-1_2.4.4.+dfsg1-1ubuntu1-2.debdiff" https://bugs.launchpad.net/ubuntu/+source/389-ds-base/+bug/2052578/+attachment/5745324/+files/389-ds-base_2.4.4+dfsg1-1_2.4.4.+dfsg1-1ubuntu1-2.debdiff -- You received this bug notification because you are a member of Ubuntu 389 Directory Server, which is subscribed to 389-ds-base in Ubuntu. https://bugs.launchpad.net/bugs/2052578 Title: 2.4.4+dfsg1-1 is FTBFS on armhf in Noble Status in 389-ds-base package in Ubuntu: Triaged Bug description: build fails with: ldap/servers/slapd/back-ldbm/db-bdb/bdb_layer.c: At top level: ldap/servers/slapd/back-ldbm/db-bdb/bdb_layer.c:429:26: error: unknown type name ‘off64_t’; did you mean ‘off_t’? 429 | bdb_seek43_large(int fd, off64_t offset, int whence) | ^~~~~~~ | off_t The source properly detects when to define _LARGEFILE64_SOURCE but I think this is an ordering issue of the define and a standard library header include. I can recreate this on an armhf machine by including <stdio.h> before the LFS define. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/389-ds-base/+bug/2052578/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-389-directory-server Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-389-directory-server More help : https://help.launchpad.net/ListHelp
