apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: Solving the off_t problem in APR 1.0
Date Tue, 27 Jan 2004 17:02:25 GMT
On Tue, Jan 27, 2004 at 10:32:20AM -0500, Greg Hudson wrote:
> On Tue, 2004-01-27 at 05:49, Joe Orton wrote:
> > > Won't that create an ABI time bomb for platforms which have no
> > > large-file support now, but acquire it in the future?
> > 
> > That's asking for a level of ABI guarantee which I don't think APR can
> > provide regardless of this apr_off_t issue.
> > 
> > Will a libapr-0.so built on RHL9 have a compatible ABI with a
> > libapr-0.so built on RHL6.2?
> Generally, yes.  Why wouldn't it?  And if it is incompatible, how can we
> ensure that they have different sonames?

I've seen enough interesting things happen with symbol versioning that
I'd not *expect* it to work.  APR already has an ABI-breaker across OS
versions in the IPv6 support. I really don't think this is an issue
worth worrying about.

> > What if the libpthread soname changed between OS versions?
> Libraries like libc and libpthread very rarely change sonames, precisely
> because it effectively breaks the ABI of every library which depends on
> them.  The libc soname change in *BSD for the off_t was extraordinary.

Well, it looks like the libc soname changed in FreeBSD 5, and has
changed regularly in OpenBSD over the last few years.  Not *so*
extraordinary on some platforms at least...

> There is a new idea afloat, incidentally: rather than fix apr_off_t at
> 64 bits, fix apr_off_t at the size off_t has at configuration time. 
> (There appears to be no off32_t, so that would have to be apr_int32_t on
> most 32-bit platforms.)  That doesn't get large-file support, but it
> does make apr_off_t independent of _FILE_OFFSET_BITS, and it doesn't
> cause an ABI change.

Sounds like a good solution for the 0.9 branch at least; note that
APR_OFF_T_FMT would need to change for that though since apr_off_t would
no longer be a long int.



View raw message