Joe Orton wrote:
On Mon, Oct 29, 2007 at 02:48:57PM -0500, William Rowe wrote:
Joe Orton wrote:
No, unless you know of a platform where ino_t is defined to be anything
other than a 32-bit unsigned long *and* varies by _FILE_OFFSET_BITS?
Otherwise configure is just testing for hypothetical platforms, which is
a waste of cycles.
You missed my point. Take RandomOS Version 6.0 - build APR, no variant for
_FILE_OFFSET_BITS, it's equivilant to unsigned int.
Now run an upgrade to RandomOS V7.0, voila, it picks up long off_t semantics
and 32 more ino_t bits, whoopie!
That is not related to the change in question. There are a variety of
different ways in which APR can potentially change ABI when rebuilt
after an OS upgrade, but the use of ino_t is not one of them.
Just to be clear, I'm saying - no rebuild of APR. ABI is unchanged. The
consumer of the library is broken. Our apr.h should be (or become) rich
enough to survive such headaches. But with more important issues, I'll
drop this one on the floor rather than belabor the point.
Bill
