Closed Bug 87422 Opened 19 years ago Closed 19 years ago
latest mozilla won't build get compile errors
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.
-> 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 firstname.lastname@example.org, 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 email@example.com ... ;-(
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 firstname.lastname@example.org 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
cls: Thanks for the help!! Filed slightly "improved" patch (added comment _why_ this MDDEPDIR stuff was added + reference to this bug...). Requesting r= ...
Patch has been checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
leaf... wanna VERIFY this bug, please ?
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.