70473 - xpcom registration of libgfxxprt.so fails

Status: VERIFIED FIXED

(Core Graveyard :: Printing: Xprint, defect)

Description

[Roland Mainz]

Building a Mozilla with ./configure --enable-toolkit=xlib --with-xprint breaks
libgfxxprt.so (module cannot be loaded causing weired crashes). After some
hunting it seems that xpcom registration breaks:
-- snip --
% export LD_LIBRARY_PATH=$PWD:$LD_LIBRARY_PATH
% ./regxpcom
[snip]
**************************************************
nsNativeComponentLoader:
SelfRegisterDll(/bigtmp/moz_2001-02-26-08-Mtrunk/dist/bin/components/libgfxxprt.so)
Load FAILED with error: ld.so.1: ./regxpcom: fatal: relocation error: file
/bigtmp/moz_2001-02-26-08-Mtrunk/dist/bin/components/libgfxxprt.so: symbol
__1cRDeviceContextImplEInit6Mpv_I_: referenced symbol not found
**************************************************
[snip]
-- snip --

Seems libgfxxprt.so misses __1cRDeviceContextImplEInit6Mpv_I_ == unsigned
DeviceContextImpl::Init(void*)

CC: blizzard the Xlib-toolkit guru.

Comment 1

[Roland Mainz]

Looking at nsXPrintContext.h and nsXPrintContext.cpp - and comparing it with
nsDeviceContextPS.cpp - it looks like Xprint is totally out-of-sync with other
print stuff...

Question to [e-mail]: Can you have a quick look at the Xprint stuff
(/gfx/src/xprint/) and tell me what exactly has been changed in the last time,
please ?
Is this only the missing DeviceContextImpl implementation in nsXPrintContext -
or does it require more work ?

Last-but-not-least: Requesting permission from [e-mail] to overtake
the _whole_ Xprint dir (/gfx/src/xprint/) and fix this myself...

Comment 2

[dcone (gone)]

I will look.. but I have never even looked at that code.  

Comment 3

[Roland Mainz]

Thanks !!

Do you need an explanation how Xprint works ?

Comment 4

[Masaki Katakai]

If gtk is used for toolkit, did you see the problem?
Anyway, --enable-toolkit=xlib is usable now???

Comment 5

[Roland Mainz]

> If gtk is used for toolkit, did you see the problem?

There is bug 68441 which looks like a side-effect of this issue described
here...
... I never tested GTK+ builds since Moz 0.8... ;-(

> Anyway, --enable-toolkit=xlib is usable now???

--enable-toolkit=xlib works (except those issues where I have files bugs for) -
Xprint+Xlib_toolkit does build but failes like described here...

Comment 6

[Roland Mainz]

Based on permission from [e-mail] via PM: Overtaking Xprint
(mozilla/gfx/src/xprint/) module for one week to update (better: Full update of
all files - no patches) it - attemping to kill all known (Xprint client side)
bugs I am aware of...

Q. to Don Cone: I need the information whether Xprint module is only missing the
DeviceContextImpl implementation in nsXPrintContext or if there is more todo to
get the module to work again. Thx!
You don't need to touch the code - I can do that... :-)

Comment 7

[Roland Mainz]

Fixed.

Comment 8

[Roland Mainz]

Mhhh... why wasn't this marked as "fixed" !? Anyway... marking as fixed.

katakai - do you verify please ?

Comment 9

[Masaki Katakai]

I can not see the problem on my build with --enable-toolkit=xlib.
Marked this as VERIFIED.