Marcin Dalecki wrote: > OK. I just took a redhat spec as configure command template. As it > turns out this > was a mistake on my part... argh! JBLD was once again the root of the > problem. > Unfortunately due to this I didn't notice that subversion packages > apr/, apr-utils/, neon/ and db4/ as it should within itself thus making > it self > containing - which is indeed fine. Much much better then autogen. > Thumbs up!
Indeed, taking a distro template (which quite understandably arranges for everything possible to be packaged as external dependencies) is the wrong approach if you want a self-contained build :-) > Contrary to the origingal apr-1.1.0.tar.bz2 the configure scripts inside > subversion honor --disable-shared and other flags properly. > If not linking against shared apr the subversion configure script > suddenly starts > to honour --disable-shared itself... OK. that explains my previous > problems. > > The only thing which makes me still a bit nervous is that apr-0.9.5 > seems a bit > of way off behind apr-1.1.0. However there seem to be no serious sec. > advisories for > apr versions newer then 0.9.4 out there... This is due to svn's binary compatibility policy. svn is somewhat unusual in that it provides and public library API's (including language bindings, hence the plethora of optional java/perl/python/etc dependencies), as well as the commandline tools. This frees alternate frontends like svk, plugins to integrate into IDEs, web frontends, and other such additions from needing to constantly chase changes to the core. Since apr 1.x is a new soname from apr 0.9.x, with incompatible ABI changes, svn is therefore not permitted (by their own rules) to migrate until they too change major version numbers. Anyway, thus far both branches of apr are maintained (apache httpd 2.0 is also still using libapr0, so I don't think there's much risk of neglect just yet). The latest apr 0.9.x release is only 3 days old, so it's not like this is an old and abandoned branch...
