Joe Orton wrote:
Here's an updated patch:
Index: configure.in
===================================================================
--- configure.in (revision 583792)
+++ configure.in (working copy)
@@ -1456,6 +1456,21 @@
fi
AC_MSG_RESULT($off_t_value)
+# Regardless of whether _LARGEFILE64_SOURCE is used, on 32-bit
+# platforms _FILE_OFFSET_BITS will affect the size of ino_t and hence
+# the build-time ABI may be different from the apparent ABI when using
+# APR with another package which *does* define _FILE_OFFSET_BITS.
+# (Exactly as per the case above with off_t where LFS is *not* used)
+#
+# To be safe, hard-code apr_ino_t as 'unsigned long' iff that is
+# exactly the size of ino_t here; otherwise use ino_t as existing
+# releases did. To be correct, apr_ino_t should have been made an
+# ino64_t as apr_off_t is off64_t, but this can't be done now without
+# breaking ABI.
+ino_t_value=ino_t
+APR_CHECK_TYPES_COMPATIBLE(ino_t, unsigned long, ino_t_value="unsigned long")
+AC_MSG_NOTICE([using $ino_t_value for ino_t])
is it too early to actually compare ino_t to apr_uint64_t at this phase?
In theory there will be embedded 32 bit int+long cases we should consider.
Index: include/apr.hw
===================================================================
--- include/apr.hw (revision 583792)
+++ include/apr.hw (working copy)
@@ -346,6 +346,8 @@
#endif
typedef int apr_socklen_t;
+typedef apr_uint64_t apr_ino_t;
+
I'm 99% certain that on win32 ino_t was always 32 bits, but I'm off
to validate that assumption.
Until 2.0 we obviously can't change the number of bits in apr_ino_t, period.
