ubuntu-389-directory-server team mailing list archive

[Chris Peterson <2052578@xxxxxxxxxxxxxxxxxx>]

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