apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kean Johnston <...@sco.com>
Subject Re: Solving the off_t problem in APR 1.0
Date Wed, 28 Jan 2004 17:46:42 GMT
> That's asking for a level of ABI guarantee which I don't think APR can
> provide regardless of this apr_off_t issue.
But I agree with Greg, you can address the ABI issues as you find them. 
This is one that is easily addressed by APR.

> Will a libapr-0.so built on RHL9 have a compatible ABI with a
> libapr-0.so built on RHL6.2?  What if the libpthread soname changed
> between OS versions?  (bearing in mind that both applications using APR
> and libapr itself are-or-should-be linked against libpthread)
That is not at all an issue. If app foobar is linked against
libpthread.so.1, and so is APR, then changes to libpthread that result
in libpthread.so.2 wont affect either APR or foobar. The system
integrator / distrubution vendor just needs to make sure that they
provide both libpthread.so.1 and .2. The only time you will get into
trouble is if you recompile APR so that it links against
libpthread.so.2, and the SONAME for APR hasn't changed. In that case
you will have foobar linked to libapr.so.1, which links to
libpthread.so.2, but foorbar is still linked to libpthread.so.1. Thats
just one of those cases where people need to be careful how they
compile vital system libraries.

I dont think that problems as described above should prohibit us
from addressing the off_t issue though.

Kean

Mime
View raw message