apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Results on 1.2.8/0.9.13, roll apr-iconv?
Date Thu, 07 Dec 2006 06:20:06 GMT
Thanks everyone for their critical eyes and testing on 1.2.8/0.9.13, the
results for the releases were unanimous, and I add my own +1 to all of
the packages.

Unfortunately, the initial .mak/.dep file creations for win32 were wrong for
apr-util v 0.9.13 package, and the -win32-src.zip packages for apr-iconv were
also created incorrectly by me with hardcode local paths.  Since this is a
trivial post-release packaging snafu, I've simply re-extracted the .mak+.dep
files and replaced the affected .zip's in /dist/apr/ for windows source users.

The apr-iconv issues go a bit deeper though - there is alot of warning noise
building apr-iconv on VC2005.  It seems time to refresh those packages so that
users of the modern compiler can use it without incident.

I'd like to plan to go ahead a roll apr-iconv packages by early next week.
In the case of 0.9.13 this includes the fixes for windows compilation, and
a small fix to the ucs2 byte order mark (it was added to streams only on
continuation of stream, it should have only been added on start-of-stream).

The same fixes apply to 1.2.0 - but here is where I could use a hand (knowing
how crazy my schedule's been).  We didn't correctly tag the resulting .so for
unix as libapriconv-1.so (missing -1) in earlier versions.  It's NOT binary
compatible with libapriconv[-0].so and this is a bad thing.  Fixing it results
in a behavioral/expectation change, thus moving 1.1 -> 1.2.

I realize next-to-nobody is trying to build apr-iconv-1 on unix, and even
for windows by 2.0 I'd like it to be gone in favor of citrus.  But that said,
it's still out there, and we may as well lug it along for one last technically
correct release before archiving the effort.  Any volunteer to help on the
unix build side?


View raw message