Re: svn commit: r1897021 - /apr/apr/branches/1.8.x/
On Fri, Jan 14, 2022 at 1:59 AM William A Rowe Jr 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 These should have disappeared with r1897209. > +T apr__pool_unmanage And this one with r1897210. Cheers; Yann.
Re: svn commit: r1897021 - /apr/apr/branches/1.8.x/
On Sat, Jan 15, 2022 at 4:37 AM Yann Ylavic wrote: > > On Sat, Jan 15, 2022 at 2:00 AM William A Rowe Jr wrote: > > > At this point I question the relevance of releasing 1.7.1 at all, I > think most people will be interested in 1.8.0 and I'd advise distros > to upgrade to that too. Who will be using 1.7.1? What is the rationale > for releasing both and how confusing will that be?' > Hopefully Ivan can address the Windows apr_file_t (as suitable) soon > enough, in this case could we release 1.8.0 only? My expectation is it lives 1 1/2 hot seconds before there is something more interesting. But, if 1.8.0 release fails, it is a smart fallback, that's all. As devs, I understand our hesitancy to offering fallbacks, but there are consumers to consider.
Re: svn commit: r1897021 - /apr/apr/branches/1.8.x/
On Sat, Jan 15, 2022 at 2:00 AM William A Rowe Jr wrote: > > On Fri, Jan 14, 2022 at 5:07 AM Yann Ylavic wrote: > > > > On Fri, Jan 14, 2022 at 1:59 AM William A Rowe Jr 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. Yes I see your point for macro -> function. > > 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? What I'm thinking is to revert r1863234 in 1.7.x, thus back to r1863233's apr_pools.h code do: Index: include/apr_pools.h === --- include/apr_pools.h(revision 1863233) +++ include/apr_pools.h(working copy) @@ -799,6 +799,16 @@ APR_DECLARE(void) apr_pool_lock(apr_pool_t *pool, #endif #define apr_pool_join(a,b) +#ifdef apr_pool_find +#undef apr_pool_find +#endif +#define apr_pool_find(mem) (NULL) + +#ifdef apr_pool_num_bytes +#undef apr_pool_num_bytes +#endif +#define apr_pool_num_bytes(p, rec) ((apr_size_t)0) + #ifdef apr_pool_lock #undef apr_pool_lock #endif -- So yes, that's two new macros so any (new) code using them when !APR_POOL_DEBUG would build with 1.7.1 but not 1.7.0, though it would _run_ with both apr-1.7.[01].so (no ABI change). > > See https://apr.apache.org/versioning.html > > What's the actual reservation about 1.8.0? (After a prompt 1.7.1)? No reservation if we are able to release faster than we used to lately.. I also advocate for people who work on the APR code, for their changes to be integrated (as much/reasonable as possible) in the version they actually use. > > > > > +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. That's no different than other arch/private yet exported functions, but yes introducing it in a patch release makes an app build with 1.7.1 not runnable with apr-1.7.0.so. This function serves a real bugfix though, apr threads had real pool lifetime issues before that (raised by the httpd tests suite built/run under AddressSanitizer). I don't remember all the details of the change but possibly for this particular apr__pool_unmanage() introduction it's only about apr_thread_detach() correctness, so the other option might be to APR_ENOTIMPL there in 1.7.1, or leave a known defect, not sure it helps more.. At this point I question the relevance of releasing 1.7.1 at all, I think most people will be interested in 1.8.0 and I'd advise distros to upgrade to that too. Who will be using 1.7.1? What is the rationale for releasing both and how confusing will that be? Hopefully Ivan can address the Windows apr_file_t (as suitable) soon enough, in this case could we release 1.8.0 only? Cheers; Yann.
Re: svn commit: r1897021 - /apr/apr/branches/1.8.x/
On Fri, Jan 14, 2022 at 5:07 AM Yann Ylavic wrote: > > On Fri, Jan 14, 2022 at 1:59 AM William A Rowe Jr 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.
Re: svn commit: r1897021 - /apr/apr/branches/1.8.x/
[plus [1] and [2] links..] On Fri, Jan 14, 2022 at 12:06 PM Yann Ylavic wrote: > > On Fri, Jan 14, 2022 at 1:59 AM William A Rowe Jr 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? > > > +T apr__pool_unmanage > > That one is for internal use only (from [2]), not APR_DECLAREd so > should be fine? [1] https://svn.apache.org/r1863234 [2] https://svn.apache.org/r1884103
Re: svn commit: r1897021 - /apr/apr/branches/1.8.x/
On Fri, Jan 14, 2022 at 1:59 AM William A Rowe Jr 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? > +T apr__pool_unmanage That one is for internal use only (from [2]), not APR_DECLAREd so should be fine? Regards; Yann.
Re: svn commit: r1897021 - /apr/apr/branches/1.8.x/
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 +T apr__pool_unmanage Preserving whatever has changed on 1.8.x branch for ABI breaking changes. On Thu, Jan 13, 2022 at 6:36 PM wrote: > > Author: wrowe > Date: Fri Jan 14 00:36:06 2022 > New Revision: 1897021 > > URL: http://svn.apache.org/viewvc?rev=1897021&view=rev > Log: > Branch 1.8.x due to ABI-breaking commits > > Begin 1.8.x development from here, with no need to roll anything back > from this branch. The 1.7.x branch will need breaking backports all > rolled back. > > > Added: > apr/apr/branches/1.8.x/ (props changed) > - copied from r1897020, apr/apr/branches/1.7.x/ > > Propchange: apr/apr/branches/1.8.x/ > -- > --- svn:ignore (added) > +++ svn:ignore Fri Jan 14 00:36:06 2022 > @@ -0,0 +1,52 @@ > +Makefile > +config.cache > +config.log > +config.nice > +config.status > +configure > +libtool > +apr-config > +apr-*-config > +apr-config.out > +LibD > +LibNTD > +LibR > +LibNTR > +Debug > +DebugNT > +Release > +ReleaseNT > +*.ncb > +*.opt > +*.plg > +apr.exp > +exports.c > +export_vars.[ch] > +.libs > +.deps > +*.la > +libapr.rc > +*.aps > +*.plg > +*.dep > +*.mak > +*.rc > +BuildLog.htm > +*.stc > +*.stt > +*.sto > +*.vcproj > +*.vcproj.* > +autom4te.cache > +ltcf-c.sh > +build-outputs.mk > +.make.dirs > +*.bb > +*.bbg > +*.da > +coverage > +apr*.pc > +apr.spec > +libtool.exe > + > + > > Propchange: apr/apr/branches/1.8.x/ > -- > --- svn:mergeinfo (added) > +++ svn:mergeinfo Fri Jan 14 00:36:06 2022 > @@ -0,0 +1,4 @@ > +/apr/apr/branches/1.4.x:1003369,1101301 > +/apr/apr/trunk:733052,739635,741862,741866-741867,741869,741871,745763-745764,746310,747990,748080,748361,748371,748565,74,748902,748988,749810,760443,767895,775683,782838,783398,783958,784633,784773,788588,789050,793192-793193,794118,794485,795267,799497,800627,809745,809854,810472,811455,813063,821306,829490,831641,832904,835607,888669,892028,892159,892435,892909,896382,896653,899905,901088,902077,902090,908427,910419,910597,917819,917837-917838,923311,923320,925965,929796,930508,931973,932585,936323,951771,960665,960671,979891,983618,989450,990435,1003338,100,107,1055657,1072165,1078845,1081462,1081495,1082177,1083038,1083242,1084662,1086695,1088023,1089031,1089129,1089438,1099348,1103310,1183683,1183685-1183686,1183688,1183693,1183698,1213382,1235047,1236970,1237078,1237507,1240472,1340286,1340288,1340470,1341193,1341196,1343233,1343243,1367050,1368819,1370494,1372018,1372022,1372093,1372849,1376957,1384764,1389077,1400200,1402868,1405985,1406690,1420106,1420109,1425 > > 356,1428809,1438940,1438957-1438959,1442903,1449568,1456418,1459994,1460179-1460180,1460182,1460184,1460241,1460399,1460405,1462738,1462813,1470186,1470348,1475509,1478905,1478954,1480067,1481186,1481262,1481265,1484271,1487796,1489517,1496407,1502804,1510354,1516261,1523384,1523479,1523484,1523505,1523521,1523604,1523613,1523615,1523844-1523845,1523853,1524014,1524031,1528797,1528809,1529488,1529495,1529515,1529521,1529668,1530786,1530800,1530988,1531554,1531768,1531884,1532022,1533104,1533111,1533979,1534882,1535027,1535157,1536744,1538171,1539374,1539389,1539455,1539603,1541054,1541061,1541486,1541655,1541666,1541744,1542601,1542779,1543033,1543056,1548575,1550907,1551650,1551659,1558905,1559382,1559873,1559975,1561040,1561260,1561265,1561321,1561347,1561356,1561361,1561394,1561555,1571894,1575509,1578420,1587045,1587063,1587543,1587545,1588878,1588937,1589982,1593611,1593614-1593615,1593680,1594684,1594708,1595549,1597797,1597803,1604590,1604596,1604598,1605104,1610854,1611023,1 > > 611107,160,167,1611120,1611125,1611184,1611193,1611466,1611515,1611517,1625173,1626564,1634615,1642159,1648830,1664406,1664447,1664451,1664471,1664769-1664770,1664775,1664904,1664911,1664958,1666341,1666411,1666458,111,1667420-1667421,1667423,1667900-1667901,1667903,1667914-1667916,1667962,1669077,1671292,1671329,1671356,1671386,1671389,1671513-1671514,1671957,1672354,1672366,1672495,1672575,1674566,1675644,1675656,1675668,1675967,1675970,1675982,1676013,1683521,1685929,1696140,1696767,1722547,1722557,1726928,1727020,1727160,1727175,1727199,1728957,1732582,1733451,1733594,1733694,1733706,1733708,1733775,1734816,1736552,1738791,1738925,1750374,1755709,1755740,1755746,1755758,1755954,1761279,1762326,1774712,1774973,1775069,1776994,1776998,1788334,1788337,1788929,1789947,1789998,1790045,1790200,1790296,1790302-1790304,1790330-1790331,1790436,1790439,1790444,1790446,1790488,1790521,1790523,1790569,1790632,1791598,1791718,1791728,1792620-1792622,1792625,1792961,1792963,179426 > > 6,1797415,1798105,1805380,1806296,1807975,1808039,1808836,1808910,1809649,1810452,1813286,1813330,1814239-1814240,1814326,1814329,18