Xlib-toolkit Mozilla crashes while printing via Xprint

VERIFIED FIXED in mozilla0.9.3


Core Graveyard
Printing: Xprint
17 years ago
10 years ago


(Reporter: Roland Mainz, Assigned: Roland Mainz)



Firefox Tracking Flags

(Not tracked)



(2 attachments)



17 years ago
Xlib-toolkit Mozilla5 crashes while printing via Xprint module due shared use of
xlibrgb.so - two modules are overwriting global variables in that module...

Sharing xlibrgb.so between two modules is currently not possible as it has
global variables which cannot be shared between two modules (bug 85527 ("Turn
xlibrgb into a shared library") will fix that by introducing a new API which
uses a "handle" to reference these global variables - this allows to share the
xlibrgb.so library by using different handles for different ${DISPLAY}s ...).

Comment 1

17 years ago
Swapping QA<-->bug owner...
Assignee: katakai → Roland.Mainz
QA Contact: Roland.Mainz → katakai
Target Milestone: --- → mozilla0.9.3

Comment 2

17 years ago
Accepting bug...

Comment 3

17 years ago
Created attachment 39940 [details] [diff] [review]
Patch for 2001-06-24-08-trunk

Comment 4

17 years ago
Attached patch for mozilla/gfx/src/xprint/Makefile.in - this patch solves this
issue and adds a warning (for _me_) to that file to avoid that mistake a 3rd

Requesting r=cls@seawood.org

Comment 5

17 years ago

Comment 6

17 years ago
CC:'ing mkaply for checkin into tree...

Comment 7

17 years ago
Fix checked in

Comment 8

17 years ago
No really, I checked it in.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 9

17 years ago
This broke on HPUX. Here is the error:

aCC -ext +p +DA1.1 +DS2.0    -DNDEBUG -DTRIMMED -I/opt/gtk+/include 
-I/opt/glib/lib/glib/include -I/opt/glib/include -I/usr/include/X11R6 -b -Wl,+s 
-L../../../dist/bin -o libgfxxprint.sl  xlibrgb.o xprintutil.o 
xprintutil_printtofile.o nsDeviceContextXP.o nsFontMetricsXlib.o 
nsRenderingContextXP.o nsGfxFactoryXP.o nsXPrintContext.o nsRegionXlib.o 
nsGCCache.o    -lXp -lXext -lX11 -L../../../dist/bin -lxpcom -L../../../dist/bin 
-L/builds/tinderbox/SeaMonkey/HP-UX_B.10.20_Clobber/mozilla/dist/lib -lplds4 
-lplc4 -lnspr4    -Wl,-Bsymbolic -L../../../dist/bin -L../../../dist/lib -lgkgfx 
-L../../../dist/bin -lxpcom -L../../../dist/bin 
-L/builds/tinderbox/SeaMonkey/HP-UX_B.10.20_Clobber/mozilla/dist/lib -lplds4 
-lplc4 -lnspr4   -lm -lc_r    
aCC: error 1913: `xlibrgb.o' does not exist or cannot be read
Resolution: FIXED → ---

Comment 10

17 years ago
OK... I do not understand this. Why does every platform except HP-UX find that
xlibrgb.o ??

CC:'ing jdunn as the HP-UX guru - and as a _cry_ for help...

Comment 11

17 years ago
You use VPATH for xlibrgb, and in config/rules.mk they mention
that VPATH doesn't work on all platforms.  I am looking now
but can't figure out why HP doesn't like it.  If I find anything 
I will let u know

Comment 12

17 years ago
oops ignore that last comment.  I am looking at this

Comment 13

17 years ago
Ok, I still don't fully understand what is going on, but maybe
one of you will.

When we make, we go into xlibrgb and xlibrgb.o is created.
We then go into xprint and based on VPATH we check to see
if xlibrgb.o is up to date... since it was just built in
../xlibrgb it is so we don't rebuild it.  We then go to link
and aCC can't find xlibrgb.o because it wasn't made in ./

Now if you delete ../xlibrgb/xlibrgb.o and do a gmake in xprint
xlibrgb.o is NOT up to date, it rebuilds xlibrgb but it does
it in the xprint directory and then the lib is linked correctly.

So that is it in a nutshell but don't ask me why it isn't
doing what you guys want it to do.

Comment 14

17 years ago
jdunn wrote:
> We then go into xprint and based on VPATH we check to see
> if xlibrgb.o is up to date... since it was just built in
> ../xlibrgb it is so we don't rebuild it

Ohh... yes... BING!! :-)
This is the problem. It should never gmake in xlibrgb/ unless Xprint uses
xlibrgb.so (e.g. xlibrgb shared library). Very tricky... ;-(

cls - do you have any idea how to avoid that gmake looks into the "wrong" (e.g.
xlibrgb/) dir instead of the "right" (xprint/) dir for *.o files ?


17 years ago
Blocks: 85527

Comment 15

17 years ago
Created attachment 40182 [details] [diff] [review]
Better patch for 2001-06-25-08-trunk

Comment 16

17 years ago
Attached a new patch. This time I am using ../xlibrgb/xlibrgb.c instead of
This is only a workaround until bug 85527 get's implemented or someone finds a
solution for this linker-picks-wrong-*.o-file-via-VPATH-issue...

Requesting r=cls or r=jdunn

Comment 17

17 years ago
This works for me (on hpux)... r=jdunn@netscape.com

The only thing I am going to ask (cuz I don't know) is,
should xprint/Makefile.in be something like...
          $(srcdir)/../xlibrgb/xlibrgb.c \

Probably not, but just thought I would ask

Comment 18

17 years ago
sr=cls for lack of a better alternative.  I still don't like the patch and I
think  that xlib's use of global symbols needs to be fixed independent of
becoming a shared lib.

jdunn,  the additional $(srcdir) is not necessary (and can cause problems) as
it's really the OBJS that we care about (CSRCS with a .o suffix) and the .o will
always be relative to the current build directory. 

Comment 19

17 years ago
Thanks !!

I agree with you - this is a hack until I'll "land" a better solution for this
issue. This is the next item on my list after I am "done" with MathML-support in
Xlib-toolkit/Xprint(=soon, ~~ next week)...

Comment 20

17 years ago
OK fix is in again
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 21

17 years ago
I've succeeded to build Mozilla with xlib...
Verified today.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.