On Fri, Jan 14, 2022 at 5:07 AM Yann Ylavic <ylavic....@gmail.com> wrote: > > On Fri, Jan 14, 2022 at 1:59 AM William A Rowe Jr <wr...@apache.org> wrote: > > > > A quick review of nm against libapr-1.so between 1.7.0 and 1.7.x > > indicates that 1.7.1 > > isn't releasable as-is. Any hints? > > > > +T apr_pool_find > > +T apr_pool_join > > +T apr_pool_lock > > +T apr_pool_num_bytes > > Those come from r1863234 [1], possibly we can let them as empty macros > in 1.7.x and still add the ones for apr_pool_join() and > apr_pool_num_bytes() which were missing for !APR_POOL_DEBUG? > Yet it might make apps using them from 1.7.1 (w/o #ifdef > APR_POOL_DEBUG) not compilable with 1.7.0 (though still ABI compatible > with all 1.7.x), but no one would be able to use them as function > pointers for instance, which would be a ABI/runtime breakage. Could > that hurt actually?
Worse, a macro -> function without a major bump? That's awkward. Remember the .so remains loadable throughout apr-1.so lifespan. Afraid this has to be rejected outright on apr-1.7. There are contracts with our developers that they can load the 1.7.0 .so in place of a binary built against 1.7.2 and **nothing bad can happen** (other than the 'whoops - you wanted that bug fix.) The binaries won't fail to load. This sets us up for failure, and why put macro stubs here if they will be no-ops? What purpose is this serving to break what has been a pretty reliable solution in developers' hands? See https://apr.apache.org/versioning.html What's the actual reservation about 1.8.0? (After a prompt 1.7.1)? > > +T apr__pool_unmanage > > That one is for internal use only (from [2]), not APR_DECLAREd so > should be fine? Still, exported on linux, curious how to avoid that. Even as an internal, not an issue in 1.8.0, an issue on 1.7.x branch now.
