libprinter.a .99 error ...?

Daniel Stone daniel at fooishbar.org
Tue Jul 12 08:18:35 EST 2005


[Culling this insane CC list.]

On Mon, Jul 11, 2005 at 10:53:42PM +0200, Felix Schulte wrote:
> On 7/11/05, Alan Coopersmith <Alan.Coopersmith at sun.com> wrote:
> > Adam Jackson wrote:
> > > The correct fix will require some time investment from Xprint people.  I have
> > > no idea how it could ever have linked in the first place, nor how the
> > > XlibConf.h change broke it.
> > 
> > Before XlibConf.h, XTHREADS was never defined when Xprt #included Xrm.c,
> > since nothing in Xprt's Imakefile defined it.  Since XlibConf.h moved the
> > XTHREAD definition from command line flag set in Makefile to #include'd
> > file that is the same for the entire tree, XTHREADS is now defined where
> > it wasn't before.   (For anything that links against libX11, that's a good
> > thing.   For anything that tries to #include libX11 sources directly, it
> > can be a problem, but that's what you get from such underhanded hackery.)
> 
> Would an #undef XTHREADS help in this case?

I think at this point it should be pretty clear to all concerned that,
by the time you're pulling stunts like this to fix builds, you're
trying to do the wrong thing in the first place.

The only other thing I've run across that shares client and server code
is XKB, which has the code behaving in different ways based on #defines,
so you can't just use libxkbfile.  And it's ugly and disgusting code,
and rewriting it all is very high on my TODO list.

To reiterate -- Xrm.c isn't available, and it won't be unless there's
absolutely no way you guys can work around it.  Even then, it's a
close-run thing.


More information about the xorg-modular mailing list