Bug 5525

Summary: modular build of Xprt
Product: xorg Reporter: Drew Parsons <dparsons>
Component: Build/ModularAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high    
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
patch to build working modular Xprt none

Description Drew Parsons 2006-01-07 03:38:31 UTC 
This patch enables a working version of Xprt, the Xprint server, to be built.

The Xprt binary was built under this patch using
./autogen.sh --prefix=/opt/xorg-modular/ --enable-xprint=yes --disable-glx 
--disable-dri --enable-lbx


By "working" I mean that firefox can connect to it and print.  The quality
produced is poor since FreeType is not included with this patch.

The aim of this patch is to produce a print-only server, equivalent to the Xprt
produced from the Xorg 6.* code.  This is controlled by -DPRINT_ONLY_SERVER,
used in ./Xprint and also referenced in mi/miinitext.c.  Some discussion has
gone over the idea of a unified print+video server.  This patch does not address
that; it would need to be handled by removing -DPRINT_ONLY_SERVER from
Xprint/Makefile.am and having it set conditionally in dix-config.h controlled by
configure.ac.  It (a unified server) would I think have to switch on
LOADABLEPRINTDDX, referenced in mi/miinitext.c, as well as XPRINT to be switched
on in dix/main.c (causing both InitOutput and PrinterInitOutput to be invoked).

Most of this patch affects the Xprint subdirectory, but some changes were also
made to cfb/Makefile.am.inc to get to compiler.h (defining ldl_u), needed by the
PCL driver.  Following the approach in the old imakefile system, and used here
in many places, a dummy compiler.h is created in cfb*/ which #includes the
actual file.  This dummy file is not deleted by "make clean"; I understand this
drawback applies to other instances, e.g. cfbglrop8.c, also created in cfb.
This compiler.h is #included in cfbmskbits.h and is switched on by defining
XFREE86.  This doesn't seem so clean, but the alternative is to add #if
defined(XPRINT) to cfbmskbits.h, which is a little messy, and the old build did
use -DXFREE86 to include it.

With regards to the autogen step, is there any way to get lbx automatically
included with --enable-xprint?
Comment 1 Drew Parsons 2006-01-07 03:41:37 UTC 
Created attachment 4261 [details] [review]
patch to build working modular Xprt

Xprint/pcl-mono also needs to be added.  It contains a single Makefile.am:

xserver/xorg/Xprint/pcl-mono/Makefile.am:
#################################################
noinst_LTLIBRARIES = libpcl.la

PCL_DRIVER = -DXP_PCL_MONO

include ../pcl/Makefile.am.inc
#####################################################

(cf. the new xserver/xorg/Xprint/pcl/Makefile.am)
Comment 2 Adam Jackson 2006-01-07 09:54:34 UTC 
why does Xprint need LBX?  that's totally nonintuitive.
Comment 3 Adam Jackson 2006-01-07 10:02:36 UTC 
applied, going to chase down the LBX thing though.  thanks!
Comment 4 Drew Parsons 2006-01-08 01:16:40 UTC 
It may well be that Xprint doesn't "need" LBX (I don't know what LBX is myself).

While trying to get a working Xprt binary, one of the problems I came up against
was that client->devPrivates was NULL but was being dereferenced in
xext/xprint.c::XpContextOfClient, leading to a segfault. I learnt that it was
set to NULL in dix/main.c because "totalClientSize == sizeof(ClientRec)".  The
definition of ClientRec is in include/dixstruct.h, #included in dix/dispatch.c
and has various optional parts conditional #if LBX, XCSECURITY, XAPPGROUP etc.

At the same time I was using the old Xprint build (from xprint.mozdev.org) to
check which -Ddefines were missing. The old build of dispatch.c used "-DLBX
-DXAPPGROUP    -DXCSECURITY", and put it into libdix.a, which was later linked
into Xprt.

My old Xprt build actually compiled dispatch.c twice (both with -DLBX), once for
libdix.a, and later in xc/programs/Xserver/GL/mesa for libGLcore.a. libGLcore.a
was also linked into Xprt (I haven't tested Xprint with GL in the modular build
yet).

So I can't say that Xprint "needs" LBX, I was just keeping the build environment
as consistent as possible to what it was in the monolithic build.
Comment 5 Adam Jackson 2006-04-04 05:58:15 UTC 
*** Bug 4174 has been marked as a duplicate of this bug. ***
Comment 6 Jeremy Kolb 2006-04-04 06:31:00 UTC 
Apparently I filed 4174 but I don't remember, so I'm removing myself from CC.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.