On Wed, Feb 16, 2005 at 05:09:37PM -0800, Thomas Bushnell BSG wrote: > > That would be RC bug #295175 in the xfree86-common package. I don't imagine > > gnucash would've fared any better under these circumstances without the > > libtool update, either.
> Ah, ok! I'm glad you are up on these things; I would not have guessde > to look there. I'll just wait until that gets into unstable on all > the arch's and then maybe we can see what gnucash problems remain. Note that it's not sufficient for the fixed package to reach unstable, the buildd admins also (and more importantly) need to clean up the build chroots by manually reconciling the status of the xfree86-common package. > > Though it might be nice if gnucash's configure script called, and used the > > output from, the AC_PATH_X macro if it's going to be including X11/Xlib.h > > (and why does a GNOME application need to directly include X headers, > > anyway?). > See, gnucash is big and complicated. :) > gnucash installs its own Xlib error handler. Oh, well, ick then. :) > > Yes, libtool updates are not as nice as they ought to be -- frequently > > complicated by upstreams' use of questionable practices where autoconf > > macros (aclocal.m4) are concerned. I still haven't gotten gnucash playing > > nicely with libtool 1.5, FWIW, after several iterations... > Thanks for trying. :) Maybe once the xfree86-common problems are > stamped out by Branden, gnucash 1.8.10-7 won't have a severe an issue > with the older libtool. It looks like it, though now that I've figured out what was keeping me from updating to libtool 1.5 (and speaking of questionable upstream practices), I'm surprised to see that your changes in -7 don't run afoul of the fact that acinclude.m4 includes a complete local copy of the libtool autoconf macros... In any case, I have things mostly working here with libtool 1.5 now; the update process is basically: sed -i -n -e'/g-wrap.m4/,$p' acinclude.m4 && libtoolize --force --copy \ && aclocal-1.4 -I macros && autoconf looks like there's some manual fiddling that has to be done in po/Makefile.in.in as well; I'll send you a full patch privately once I have it building all the way through. > Upstream reports that no 1.8 releases should be expected for things > like the build system; Yeah, a reasonable policy, though it would be nice if they used sane build scripts for any future releases on the 1.8 branch. Is the gnome-2 branch already using libtool 1.5? > It is possible that these problems will stymie work on 1.8.10 for > Debian, at least, not before sarge release. If that's true, I can > hobble together an interim version based on the old version in woody, > which backports the important bugfixes since then, but I would rather > avoid such a procedure if possible. I think the path to getting 1.8.10 into sarge is fairly straightforward from here. -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
