103371 - Xprint module uses |nsDeviceContextXlib| in non-Xlib builds

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Chris Waterson]

xprint appears to have somewhat wedged the build system right now.

1. I cannot do a debug ``static'' build, because xprint relies on the xlib
   port of gfx. But the GFX/xlib is not built by default, even though
   xprint is.

2. Fixing that makes the build complete, but then we abort() on startup
   trying to create an nsDeviceContextXlib.

How on earth does this run in the dynamic build? gisburn, please unwedge.

Comment 1

[Brendan Eich [:brendan]]

And what are naked aborts doing in our code?  I heard from mcafee about his
rejection of abort() calls during code review of gisburn patches, but we
couldn't find the bug in question.  How did this code get checked in, who r='d
and sr='d?

/be

Comment 2

[Roland Mainz]

> 1. I cannot do a debug ``static'' build, because xprint relies on the xlib
>   port of gfx. But the GFX/xlib is not built by default, even though
>   xprint is.

I've build a StaticBuild Mozilla ~two weeks ago (GTK+ toolkit)... no problems
there...

Which configure options do you use ?

> 2. Fixing that makes the build complete, but then we abort() on startup
>   trying to create an nsDeviceContextXlib

??

This should not happen. If you get a |nsDeviceContextXlib| in your build then
you're building nsDeviceContextXlib.cpp - which is definately not part of Xprint
module.

Note that (AFAIK) you cannot build multiple toolkits (Xprint module is _NOT_ a
toolkit) into one StaticBuild binary (e.g. something like "configure --with-xlib
--with-qt --with-gtk"). This works with normal (shared libs) builds because only
one set of toolkit module shared libs gets linked to dist/bin/components/ - but
I assume that in a StaticBuild all available toolkit modules would be registered
- causing lots of havoc (which is not a Xlib nor Xprint module specific
issue...).

----

Accepting bug...

----

BTW: What is a "boondogglery" ?

Comment 3

[Roland Mainz]

waterson:
I cannot reproduce your problem here on Solaris7/SPARC with Sun Workshop 6
Update 2.
I created a StaticBuild Mozilla with "configure --enable-mathml --enable-svg
--enable-crypto --enable-optimize --enable-static --disable-shared
--disable-mailnews 2>&1 | tee -a buildlog_ws6_gtk_static.log; time nice -n 12
gmake 2>&1 | tee -a buildlog_ws6_gtk_static.log".
(I fixed bug 101896 because it caused my StaticBuild to fail linking
mozilla-bin... grrr...)

1. Checking the build log if |nsDeviceContextXlib| gets build:
-- snip --
% cat buildlog_ws6_gtk_static.log | grep "^nsDeviceContext"
nsDeviceContext.cpp
nsDeviceContextPS.cpp
nsDeviceContextGTK.cpp
nsDeviceContextSpecFactoryG.cpp
nsDeviceContextSpecG.cpp
nsDeviceContextXP.cpp
-- snip --
(answer: no)

2. gfx/src/xlib/ contains only "Makefile" (no object files)

3. Looking for symbols/strings in mozilla-bin:
-- snip --
% strings -a mozilla-bin | fgrep -i nsDeviceContextXlib
__1cTnsDeviceContextXlibQGetXlibRgbHandle6M_pnO_XlibRgbHandle__
__1cTnsDeviceContextXlibQGetXlibRgbHandle6M_pnO_XlibRgbHandle__
__1nTnsDeviceContextXlib_:U
nsDeviceContextXlib.h
__1nTnsDeviceContextXlib_:U
nsDeviceContextXlib.h
-- snip --

AFAIK the only piece of code which uses |nsDeviceContextXlib| is
http://lxr.mozilla.org/mozilla/source/gfx/src/xlib/nsFontMetricsXlib.cpp#785
In theory it may be required to fully implement a class even when only one
already implemented method is used. 
Ouch... ;-(

AFAIK there is an easy fix for that (hint for me: |nsIXlibRgbHandleGetter|),
I'll file a patch once I have a new, working tree (1day from now).

Comment 4

[Roland Mainz]

Attachment: Patch for 2001-10-08-08-trunk

Comment 5

[Roland Mainz]

Here's the patch. The fix is to create a common baseclass (nsDeviceContextX) for
{nsDeviceContextXlib|nsDeviceContextXp} to get rid of module-specific cast
stunts (we're now casting to |nsDeviceContextX| in those cases).

Requesting r=/sr= ...

Comment 6

[hacker formerly known as [e-mail]]

Now I'm hitting:

../../dist/lib/components/libgfxxprint.a(nsDeviceContextXP.o): In function
`nsDeviceContextXp::InitDeviceContextXP(nsIDeviceContext *, nsIDeviceContext *)':
nsDeviceContextXP.o(.text+0x31e): undefined reference to
`nsFontMetricsXlib::FreeGlobals(void)'
nsDeviceContextXP.o(.text+0x328): undefined reference to
`nsFontMetricsXlib::EnablePrinterMode(int)'

and

../../dist/lib/components/libgfxxprint.a(nsDeviceContextXP.o): In function
`nsDeviceContextXp::CreateRenderingContext(nsIRenderingContext *&)':
nsDeviceContextXP.o(.text+0x374): undefined reference to
`nsRenderingContextXp::nsRenderingContextXp(void)'
../../dist/lib/components/libgfxxprint.a(nsDeviceContextXP.o): In function
`nsDeviceContextXp::CheckFontExistence(nsString const &)':
nsDeviceContextXP.o(.text+0x438): undefined reference to
`nsFontMetricsXlib::FamilyExists(nsIDeviceContext *, nsString const &)'


Try building with gcc. I'm wondering if WS is optimizing out these unused
functions and gcc isn't.

Comment 7

[hacker formerly known as [e-mail]]

Scratch that. I typo'd in yesterday's Makefile.in change so the XLIB_LCPPSRCS
weren't being built.  The static build works now. r=cls

Comment 8

[Chris Waterson]

sr=waterson

Comment 9

[Håkan Waara]

This patch was checked in by cls at 01:50

Comment 10

[Roland Mainz]

Marking bug as FIXED.

waterson, can you VERIFY, please ?

Comment 11

[Tracy Walker [:tracy]]

verified