But I agree with Greg, you can address the ABI issues as you find them. This is one that is easily addressed by APR.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? 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
