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. Regards, joe
