GNOME Bugzilla – Bug 162003
vte configure.in X checking can fail
Last modified: 2007-01-22 14:26:25 UTC
Please describe the problem: vte's code for finding the X libraries munges with the results of AC_PATH_XTRA in unnecessary and incorrect ways. The premise for this munging is that "On some OSs, AC_PATH_XTRA doesn't work right(?)...". Nevermind that on such an operating system, gtk, libgnomeui, and a host of other programs wouldn't compile, so it's unlikely that a user of said operating system would get to the point of building vte. As to what specifically can go wrong: vte uses the internal variables ac_x_includes and ac_x_libraries to reset X_CFLAGS and X_LIBS instead of using the values resulting from AC_PATH_XTRA. The AC_PATH_XTRA macro does not set those internal variables in all cases; for instance, if x_includes and x_libraries are set in config.site, it simply uses those values and does not compute its own. Please remove the eleven lines following AC_PATH_XTRA (from "X_CFLAGS=" to "fi") and the preceding comment, and all should be well again. Steps to reproduce: 1. Create a config.site which sets x_includes and x_libraries. 2. Configure vte. Actual results: The freetype test fails due to CFLAGS and LIBS having incorrect values for the X flags. Expected results: Does this happen every time? Other information:
r1492: 2007-01-22 Chris Wilson <chris@chris-wilson.co.uk> Hack'n'slash my way through doing a bit of weeding. Fixed: - Bug 345514 – -no-undefined doesn't work with latest libtool - Bug 162003 – vte configure.in X checking can fail – though this may cause other regressions! - Bug 314669 – Please specialize AC_PATH_XTRA * configure.in: Export LIBTOOL_EXPORT_OPTIONS for -no-undefined on windos. Add to rather than override X_CFLAGS, X_LIBS AC_PATH_XTRA - Find X11 using XFlush() rather than XtMalloc(). Print configuration details. * src/Makefile.am: Conditional compilation of backends.