On 2015-10-31 18:48, Michael Felt wrote: > On 2015-09-08 12:50, Stefan Hett wrote: >> Hi, >> a while ago I've been pointed by Bert to the fact that APRUtil 1.5.4 >> includes Expat 1.95.7 which is rather old (from October 2003). According >> tohttp://www.libexpat.org/ there has been another 1.95 release with >> mostly bugfixes (1.95.8 in July 2004) and the latest one is 2.1.0 (from >> March 2012). > I would like to repspond positively on this suggestion that "something" be > done. > It could be updated, and fortunately expat is not a package with frequent > (security) updates, > but it is external. What may have been good before is perhaps not as correct > anymore. > > a) expat needs to be closer to mainstream: there are many features > in expat that have been introduced since then. > The embedded expat is not packaged as an internal (aka static) library - but > appears as a separate library. > > I ran into this problem when packaging something else that needed the latest > and greatest (i.e., 2.0.1 as base). > > My solution is to repackage apr, apr-util and httpd after removing > the internal expat - so that I have latest and greatest for both - and can > update it, > in principle - separate from apr. > > I would vote to make external expat the default and/or just remove expat from > apr. >
In case you build apache from source, there is already an option to build apr-util against expat-2.0.1, no need to change the bundled one. Use `--with-expat=$path/to/libexpat' as configure arg to apr-util and you are done. I suspect most every distribution / project building binary packages will overwrite the bundled expat explicit. E.g. FreeBSD [1], RHEL (and derivates like CentOS and ScientificLinux [2]). [1] https://svnweb.freebsd.org/ports/head/devel/apr1/Makefile?view=markup [2] http://ftp1.scientificlinux.org/linux/scientific/7x/SRPMS/vendor/apr-util-1.5.2-6.el7.src.rpm -- HTH, olli
