apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucian Adrian Grijincu" <lucian.griji...@gmail.com>
Subject Re: Tagging 1.2.* Sat night or Sun a.m.
Date Thu, 11 Oct 2007 18:15:17 GMT
On 10/11/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> Lucian Adrian Grijincu wrote:
> >
> > Do my patches against configure.in, apr.hnw and apr.hw fixing the
> > apr_ino_t ( http://issues.apache.org/bugzilla/show_bug.cgi?id=43417 )
> > issue have a chance of getting accepted (aka should I try to test them
> > on other configurations to see whether they break something on some
> > systems)?
> Not according to folks interpretation of our versioning policy, it seems
> this patch must wait for 2.0.0.  You would be breaking ABI for anyone
> building against a 32 bit APR build.
> If folks can prove APR 1.0.0 forward have promised that it's internally
> always built _FILE_OFFSET_BITS=64 then I'd entertain changing the type,

As far as I can see (from the 1.2.x tag head) APR is built by default
with _FILE_OFFSET_BITS=32. Also there is a desire to prevent ABI
changes when _FILE_OFFSET_BITS is defined as 64.

Actually there's a 0.9.4 to 0.9.5 change that is documented as such
(see the CHANGES file):

  *) Define apr_off_t as long rather than as off_t on platforms with a
     32-bit off_t to prevent incompatibility with packages such as
     Perl which redefine the size of off_t via _FILE_OFFSET_BITS on
     some platforms.  [Ben Reser <ben reser.org>]

So either that change broke the rules (if these rules were applicable
back when the change was made) or my proposed changes are compatible
with the rules.

I'm doing the same thing: trying to find a type that is compatible
with ino_t with the flags with which apr is built and typedef
apr_ino_t to that compatible type.

> (an external included-headers apparent bug as opposed to an internal bug)
> but again according to folks interpretation of the versioning policy,
> this would have to be based on apr_off_t or a type we already declare,
> as we cannot add an apr_ino_t until 1.3.0.

has this line:

typedef apr_uint64_t              apr_ino_t;

so the type is present in the current 1.2.x head.


View raw message