apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r589583 - /apr/apr/trunk/configure.in
Date Tue, 30 Oct 2007 17:57:58 GMT
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.


View raw message