Closed Bug 87422 Opened 19 years ago Closed 19 years ago

latest mozilla won't build get compile errors

Categories

(Core Graveyard :: Printing: Xprint, defect, critical)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: dharter, Assigned: roland.mainz)

Details

(Keywords: qawanted)

Attachments

(3 files)

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.
Attached file .mozconfig file
-> Xprint people.
Assignee: cls → katakai
Component: Build Config → Printing: Xprint
QA Contact: granrose → Roland.Mainz
Does the same thing happen when you do --with-xlib --without-gtk
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.
Assignee: katakai → Roland.Mainz
Status: UNCONFIRMED → NEW
Ever confirmed: true
1. Accepting bug, fixing the QA to katakai@japan.sun.com, 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 cls@seawood.org ... ;-(
Severity: normal → critical
Status: NEW → ASSIGNED
QA Contact: Roland.Mainz → katakai
Target Milestone: --- → mozilla0.9.3
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.
The error still occurs when I try --with-xlib and --without-gtk.  I just tried
it with the latest source.
cls:
Is it possible that the VPATH stuff in xprint/Makefile.in does not work with the
.deps stuff in some cases ?
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.

cls:
Do you have any clue why it works for me, you, tinderbox machines and most
others - but fails on some other machines ?
Reporter:
Per jcgriggs@sympatico.ca 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... ;-((
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.
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... :-))
This works for me.
I build xlib build daily...
So does gisburn...

This is probably a misconfiguration error on the users part.
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).
As a temp solution do --disable-xprint (or whatever is the appropriate option).
gisburn should probably take another look at this.
Stupid question: Which piece of code generates these ".deps/" dirs ?
OK... simple workaround (hack):
If gfx/src/xprint/.deps/ is missing the Makefile in xprint/ should create it
first... does that work ?
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.
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
Attached patch PatchSplinter Review
cls:
Thanks for the help!!

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

Requesting r= ...
Keywords: qawanted
Patch has been checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
leaf... wanna VERIFY this bug, please ?
yay!
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.