[PATCH] xprint is broken in xserver git

[Drew Parsons]

On Wed, 2007-08-22 at 11:24 +1000, Drew Parsons wrote:

> 
> > Error message:
> > 
> > ../../config/libconfig.a(dbus-core.o): In function `teardown':
> > dbus-core.c:(.text+0x8a): undefined reference to `dbus_connection_unref'
> > ../../config/libconfig.a(hal.o): In function `get_prop_string':
> > hal.c:(.text+0x19b): undefined reference to `libhal_device_get_property_string'
> 
> There it is, just as I thought - the bug is carried in to Xprt via
> libconfig.a.  So I think that makes a "clean" solution (in the sense of
> keeping hal/dbus out of Xprint) tricky, since it would imply building
> two libconfig.a, one with hal support and one without.  We not want to
> go to that kind of trouble, in which case the workaround is to just add
> the simple dummy functions, which you did in your patch.
> 
> The alternative is to have Xprint (and Xdmx) build their own libconfig.a
> locally, and remove $CONFIG_LIB from XPRINT_EXTENSIONS in configure.ac
> (and adding -lconfig explcitly to xprint/Makefile.am). This is not
> particularly difficult to do, it just means creating some symlinks to
> the source files in ./config/.
> 
> I'm inclined to prefer the second solution, creating an Xprint-specific
> libconfig.a, since that's logically (or aesthetically?) more correct.
> I'm not sure about Xdmx, however. Does hal/dbus support make sense in
> Xdmx?
> 


I've had a go at implementing this second option, building a local
libconfig.a.  The trouble is that config/config.c checks if
CONFIG_DBUS_API and CONFIG_HAL are defined, which they are in
include/dix-config.h.  So their definition cannot be undone with an
Xprint-specific command-line (-UCONFIG_HAL can be given, but it's
overridden by dix-config.h). The only solution that stays on this path
is to add a check within config.c to see if PRINT_ONLY_SERVER or
somesuch is defined (a similar problem is in fact handled this way in
mi/miinitext.c, which has to be compiled locally for Xprint).  

So the two options become

1) adding a small, ugly but harmless hack to the Xprint code to manage
HAL support which it does not in fact use

2) adding a small but logically tricky hack to config.c, enabling an
Xprint-specific libconfig.a to be compiled.  

In the interests of keeping the non-Xprint code unmangled and tidy for
the rest of you, I'll apply the first option, based on Maarten's patch.
Xprint will just have to carry the extra code (well, it can always be
compiled separately with HAL support switched off, if you're that
worried about memory bloat).

Drew