87422 - latest mozilla won't build get compile errors

Status: VERIFIED FIXED

(Core Graveyard :: Printing: Xprint, defect)

Description

[dharter]

I tried several times to build from the frozen source tree.  I even deleted
everything and restarted to make sure that I did not have any old files.  I will
attach a command line listing of the build.

Comment 1

[dharter]

Attachment: command line output form the build

Comment 2

[dharter]

Attachment: .mozconfig file

Comment 3

[James Green]

-> Xprint people.

Comment 4

[pocemit]

Does the same thing happen when you do --with-xlib --without-gtk

Comment 5

[pocemit]

the same issue is also noted in bug 86291.
gisburn: want to take a look at this?
looks like autogenerated dependencies are not working right.

Comment 6

[Roland Mainz]

1. Accepting bug, fixing the QA to [e-mail], setting milestone,
marking bug as "critical"...
2. I do not have aqny clue what's going on here. I can build the Zilla on
Solaris 7 with both Sun Workshop 6U2EA2 and gcc2.95.1. Looks like a build issue
- need help from a build expert: CC'ing [e-mail] ... ;-(

Comment 7

[dharter]

I changed the .mozconfig file by commented out the --use-xlib and adding
--use-gtk.  The build worked.  I am using the result now.  I will attach teh
working .mozconfig file.

Comment 8

[dharter]

The error still occurs when I try --with-xlib and --without-gtk.  I just tried
it with the latest source.

Comment 9

[Roland Mainz]

cls:
Is it possible that the VPATH stuff in xprint/Makefile.in does not work with the
.deps stuff in some cases ?

Comment 10

[cls]

I don't see why VPATH would have any affect.  The file that the error is being
generated on is in the current srcdir anyways.  Fwiw, I built using
--without-gtk --with-xlib --enable-toolkit=xlib without a problem.

Comment 11

[Roland Mainz]

cls:
Do you have any clue why it works for me, you, tinderbox machines and most
others - but fails on some other machines ?

Comment 12

[Roland Mainz]

Reporter:
Per [e-mail] in bug 87148:
Please check if the following produre solves your problem (and this bug... :-)
1. Wipe-out your complete tree. Everthing. Source and obj dirs... Really each
single bit.
2. Pull a fresh new source tree (via CVS or nightly tarball) and do a complete
recompile.

This should solve your issue. Recently some "Makefile.in"-fu has been changed in
Xprint land which may cause this trouble. Or not... ;-((

Comment 13

[dharter]

This may be relevant to this bug.  I am using the latest Xfree86 distribution,
4.1.0.

Red Hat News. XFree86 4.1 is in Rawhide. People using it should note, however,
that Red Hat removed libXIE.so from XFree86 4.1 when they installed it because
the XFree86 team deprecates the use of that library. Unfortunately, Mozilla
0.9.1 uses that library. As a result, libXIE.so will go back into the next
Rawhide build. However, it will not be included in future official versions of
Red Hat. Developers take note; use of that library will make your program
incompatible with future releases of Red Hat and other distributions that follow
the request of the XFree86 team.

Comment 14

[Roland Mainz]

dharter:
XIE != Xprint. Xprint's client side library is libXp.so - and Mozilla's Xprint
support only gets enabled when this library is available and useable (e.g. stub
test program in configure compiles...)...

And I am very _SURE_ that Xprint is _NOT_ obsolete... :-))

Comment 15

[pocemit]

This works for me.
I build xlib build daily...
So does gisburn...

This is probably a misconfiguration error on the users part.

Comment 16

[Vino Crescini]

I get the same problem when compiling --with-gtk --with-xlib. The xprint .deps
dir doesn't seem to get created when VPATH is set to something other than
@srcdir@, even if they're separated by a colon. I got xprint to compile
temporarily by taking out xlib sources from CPPSRCS (and ../xlib from VPATH).

Comment 17

[pocemit]

As a temp solution do --disable-xprint (or whatever is the appropriate option).
gisburn should probably take another look at this.

Comment 18

[Roland Mainz]

Stupid question: Which piece of code generates these ".deps/" dirs ?

Comment 19

[Roland Mainz]

OK... simple workaround (hack):
If gfx/src/xprint/.deps/ is missing the Makefile in xprint/ should create it
first... does that work ?

Comment 20

[Vino Crescini]

that's why it doesn't compile... the .deps directory doesn't get created by
xprint/Makefile. taking out the ../xlib part in the VPATH seems to cause the
Makefile to make the .deps dir.

Comment 21

[cls]

Ok, so I forgot about the .deps/VPATH issue when building in a srcdir.  Bah and
fie.  I liked it much better when we insisted that you only build in objdirs.

Index: gfx/src/xprint/Makefile.in
===================================================================
RCS file: /cvsroot/mozilla/gfx/src/xprint/Makefile.in,v
retrieving revision 1.22
diff -u -r1.22 Makefile.in
--- Makefile.in 2001/06/27 14:05:29     1.22
+++ Makefile.in 2001/07/05 10:58:42
@@ -64,6 +64,8 @@
 EXTRA_DSO_LDOPTS += $(MOZ_COMPONENT_LIBS) \
                $(NULL)

+MDDEPDIR       := $(MDDEPDIR)_xp
+
 include $(topsrcdir)/config/rules.mk
 
 DEFINES         += -D_IMPL_NS_GFXONXP -DUSE_MOZILLA_TYPES -DUSE_XPRINT
-D_IMPL_NS_XPRINT

Comment 22

[Roland Mainz]

Attachment: Patch

Comment 23

[Roland Mainz]

cls:
Thanks for the help!!

Filed slightly "improved" patch (added comment _why_ this MDDEPDIR stuff was
added + reference to this bug...).

Requesting r= ...

Comment 24

[Daniel (Leaf) Nunes]

r=leaf attachment 41250 [details] [diff] [review]

Comment 25

[cls]

Patch has been checked in.

Comment 26

[Roland Mainz]

leaf... wanna VERIFY this bug, please ?

Comment 27

[Daniel (Leaf) Nunes]

yay!