Closed
Bug 305185
Opened 19 years ago
Closed 18 years ago
gtk 2.8 builds are broken due to missing xft dependencies
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 338446
mozilla1.8.1
People
(Reporter: wolfiR, Assigned: wolfiR)
References
Details
Attachments
(1 file, 2 obsolete files)
4.27 KB,
patch
|
roc
:
superreview+
|
Details | Diff | Splinter Review |
A static build of firefox and thunderbird (at least 1.0.x series) fails with gtk 2.8. The reason is that pangoxft is not longer in MOZ_GTK2_LIBS and so the final firefox-bin link fails with undefined references to XFT functions.
Assignee | ||
Comment 1•19 years ago
|
||
pangox-1.0 is also missing in LDFLAGS
Assignee | ||
Updated•19 years ago
|
Summary: aviary 1.0.x fails with gtk 2.8 → aviary 1.0.x build fails with gtk 2.8
Assignee | ||
Comment 2•19 years ago
|
||
Seems that every static build suffers from this problem. Even for MOZILLA_1_8_BRANCH.
Assignee | ||
Comment 3•19 years ago
|
||
Same for thunderbird. I don't understand the font rendering support completely
but I will attach a first patch which should restore the same behaviour with gtk
>= 2.8
Summary: aviary 1.0.x build fails with gtk 2.8 → static builds fails with gtk 2.8
Assignee | ||
Comment 4•19 years ago
|
||
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•19 years ago
|
||
Comment on attachment 193921 [details] [diff] [review] first try this one is incomplete and wrong :-( Have to do some more investigation.
Attachment #193921 -
Attachment is obsolete: true
Assignee | ||
Comment 6•19 years ago
|
||
This patch fixes the following problems: 1. a pango enabled build builds against pangocairo instead pangoxft if pangocairo is available (done via #define in mozilla-decoder.cpp) 2. the static build problem is fixed by adding MOZ_PANGO_LIBS to TK_LIBS - so we have to get the PANGO_LIBS also in XFT builds caillon, roc, please comment on that.
Assignee | ||
Updated•19 years ago
|
Summary: static builds fails with gtk 2.8 → static build fails with gtk 2.8
Assignee | ||
Comment 7•19 years ago
|
||
Attachment #194062 -
Attachment is obsolete: true
Looks OK to me although I don't 100% understand configure files.
For example, why are we checking "pangoxft >= 1.1.0" in one place and "pangoxft
>= 1.6.0" below? Actually why are we checking for pango at all under
--enable-xft? That's really a question for blizzard...
Assignee | ||
Comment 9•19 years ago
|
||
(In reply to comment #8) > For example, why are we checking "pangoxft >= 1.1.0" in one place and "pangoxft > >= 1.6.0" below? > Actually why are we checking for pango at all under > --enable-xft? That's really a question for blizzard... That seems to be a GTK2 prerequisite in some gfx-gtk files. So XFT is not possible anymore without Pango (at least version 1.1.0). That's also the reason why we need pango >= 1.1.0 for XFT but we for real Pango support we need functions from pango >= 1.6.0 while for Pango together with Cairo we need at least 1.10.0. But I also think that blizzard and/or Jungshik should have a look at it.
Assignee | ||
Updated•19 years ago
|
Attachment #194164 -
Flags: first-review?(jshin1987)
Comment 10•18 years ago
|
||
That's a blocker for me. All new Distris come with GTK2-2.8.x(SuSE 10 with GTK2 2.8.3 is out and Ubuntu 5.10 appears in 20051013).
Comment 11•18 years ago
|
||
Comment on attachment 194164 [details] [diff] [review] gtk2.8 patch (#2) Caillon would be better off reviewing this, no?
Attachment #194164 -
Flags: first-review?(jshin1987) → first-review?(caillon)
Updated•18 years ago
|
Flags: blocking1.8rc1?
Comment 12•18 years ago
|
||
why does this not fail for our builds?
Assignee | ||
Comment 13•18 years ago
|
||
Asa, I wonder if you run any gtk 2.8 tinderboxen yet?
Comment 14•18 years ago
|
||
Not going to block our release for a feature we don't even build. We'd consider a fully reviewed and tested patch. Use the patch approval flag if you guys get that in the next day or two.
Flags: blocking1.8rc1? → blocking1.8rc1-
Comment 15•18 years ago
|
||
*** Bug 310838 has been marked as a duplicate of this bug. ***
Comment 16•18 years ago
|
||
(In reply to comment #7) > Created an attachment (id=194164) [edit] > gtk2.8 patch (#2) > I applied this patch on top of trunk yesterday to fix my build. The logic in the configure scripts never set MOZ_PANGOCAIRO even after several attempts. However when I forced MOZ_PANGOCAIRO at the top of mozilla-decoder.cpp everything works. So there may still be a problem with the configure logic.
Assignee | ||
Comment 17•18 years ago
|
||
This patch still works for me. Please remember to regenerate your configure from the configure.in. If it still doesn't work please file your config.log.
Assignee | ||
Comment 18•18 years ago
|
||
bryner, maybe you can comment/review on that? Would be nice to have this on trunk soon.
Comment 19•18 years ago
|
||
(In reply to comment #7) > Created an attachment (id=194164) [edit] > gtk2.8 patch (#2) > I applied this patch to the official Firefox 1.5beta2 source, and everything built fine and works fine. However, I find the performance of the browser quite sluggish compared to when it was built against pangoxft from GTK 2.6.x and earlier. It tends to be slowest with DHTML or content-heavy websites, and things like switching between tabs and scrolling through webpages is a little slower. Disabling Pango as well as running it without pango (MOZ_DISABLE_PANGO=1) made it much more responsive.
Comment 20•18 years ago
|
||
*** Bug 316065 has been marked as a duplicate of this bug. ***
Gtk 2.8 ships standard on SuSE 10.0, so I bet many folks are seeing this. Updating the summary to make searching a bit easier. Any idea when this patch will be reviewed? I imagine it's difficult to keep this patch current when our trunk keeps changing...
Severity: normal → major
Summary: static build fails with gtk 2.8 → gtk 2.8 builds are broken due to missing xft dependencies
Comment 22•18 years ago
|
||
*** Bug 319585 has been marked as a duplicate of this bug. ***
Comment 23•18 years ago
|
||
(In reply to comment #19) > (In reply to comment #7) > > Created an attachment (id=194164) [edit] > > gtk2.8 patch (#2) > > > > I applied this patch to the official Firefox 1.5beta2 source, and everything > built fine and works fine. > > However, I find the performance of the browser quite sluggish compared to when > it was built against pangoxft from GTK 2.6.x and earlier. It tends to be > slowest with DHTML or content-heavy websites, and things like switching between > tabs and scrolling through webpages is a little slower. > > Disabling Pango as well as running it without pango (MOZ_DISABLE_PANGO=1) made > it much more responsive. > I haven't noticed the slowness that you have seen with this patch. The patch no longer applies cleanly though so it needs to be updated.
Assignee | ||
Comment 24•18 years ago
|
||
(In reply to comment #23) > I haven't noticed the slowness that you have seen with this patch. The patch > no longer applies cleanly though so it needs to be updated. There are really systems out there which are slowing down in overall rendering with Pango enabled. This is partly Pango related and partly the usage of Pango within Gecko 1.8. But nothing to care much about because I understood that Gecko 1.9 will change everything in that area. I could post an updated patch for 1.8.0 and 1.8 branches if wanted.
Comment 25•18 years ago
|
||
(In reply to comment #23) > I haven't noticed the slowness that you have seen with this patch. The patch > no longer applies cleanly though so it needs to be updated. I have noticed this pango-related slowdown; it's in the seconds+ range for sites with lots of dynamic stuff (Gmail was especially noticeably slow); this was actually a showstopper for FF 1.5 for me, it was so bad (the rendering would block other things, and then for some reason, mouse clicks would queue up, and it would interpret them as me wanting to move the tab, as opposed to just selecting it). I didn't do a full rebuild, but the MOZ_DISABLE_PANGO trick made it at least usable again.
Assignee | ||
Comment 26•18 years ago
|
||
How about getting it for Firefox2. (Trunk might not need the change with all the new stuff)
Flags: blocking-firefox2?
Comment 27•18 years ago
|
||
(In reply to comment #9) > (In reply to comment #8) > > For example, why are we checking "pangoxft >= 1.1.0" in one place and "pangoxft > > >= 1.6.0" below? > > > Actually why are we checking for pango at all under > > --enable-xft? That's really a question for blizzard... > > That seems to be a GTK2 prerequisite in some gfx-gtk files. So XFT is not > possible anymore without Pango (at least version 1.1.0). I don't understand this. Wolfgang, are you building with '--enable-pango'? Otherwise, it shouldn't be an issue unless there's something I don't know about in gtk 2.8
Assignee | ||
Comment 28•18 years ago
|
||
(In reply to comment #27) > > That seems to be a GTK2 prerequisite in some gfx-gtk files. So XFT is not > > possible anymore without Pango (at least version 1.1.0). > > I don't understand this. Wolfgang, are you building with '--enable-pango'? > Otherwise, it shouldn't be an issue unless there's something I don't know about > in gtk 2.8 I'm building with --enable-pango, but it fails without --enable-pango, too. Because: 1. gtk2.8 doesn't have the XFT dependencies itself and so they are missing in the linker calls. A static build fails immediately and a dynamic build fails at application startup. 2. Somewhere is a pango dependency in the XFT code: http://lxr.mozilla.org/mozilla1.8/source/gfx/src/gtk/nsDeviceContextGTK.cpp#68
Comment 29•18 years ago
|
||
(In reply to comment #28) > I'm building with --enable-pango, but it fails without --enable-pango, too. > Because: > 1. gtk2.8 doesn't have the XFT dependencies itself and so they are missing > in the linker calls. A static build fails immediately and a dynamic build > fails at application startup. > 2. Somewhere is a pango dependency in the XFT code: > > http://lxr.mozilla.org/mozilla1.8/source/gfx/src/gtk/nsDeviceContextGTK.cpp#68 Thanks. I didn't realize that there's such a dependency. With that, everything makes sense. That also explains why you check pango >= 1.1.0 for xft-only and pango >= 1.6.0 for pango-enabled.
Comment 30•18 years ago
|
||
I don't know if this helps, but I've been able to unbreak the build for Firefox and Seamonkey by adding the following section to mozilla/browser/app/Makefile.in as well as mozilla/xpfe/bootstrap/Makefile.in : ifeq ($(MOZ_ENABLE_XFT),1) LIBS += -lXft endif
Updated•18 years ago
|
Flags: first-review?(caillon)
Flags: blocking-firefox2?
Product: Toolkit → Core
Target Milestone: --- → mozilla1.8.1
Version: unspecified → 1.8 Branch
Updated•18 years ago
|
Flags: blocking1.8.1+
Comment 31•18 years ago
|
||
(In reply to comment #30) > > ifeq ($(MOZ_ENABLE_XFT),1) > LIBS += -lXft > endif > Yeah, this is breaking for me on Ubuntu 5.1 Breezy Badger, as anticipated in a previous comment. The workaround here seems to get me through the build, but after launching the binary and using for 2-3 seconds I crash: ./run-mozilla.sh: line 131: 29141 Segmentation fault "$prog" ${1+"$@"}
Comment 32•18 years ago
|
||
(In reply to comment #31) > > Yeah, this is breaking for me on Ubuntu 5.1 Breezy Badger, as anticipated in a > previous comment. The workaround here seems to get me through the build, but > after launching the binary and using for 2-3 seconds I crash: > > ./run-mozilla.sh: line 131: 29141 Segmentation fault "$prog" ${1+"$@"} > Correction, this crash was related to an extension (ForecastFox 0.8.5.1). All is fine now with the build workaround.
Assignee | ||
Comment 33•18 years ago
|
||
Comment on attachment 194164 [details] [diff] [review] gtk2.8 patch (#2) This is going to be a 1.8branch only thing and setting review to caillon (as per bsmedberg's comment) and sr to roc for the change in gfx/src/gtk
Attachment #194164 -
Flags: superreview?(roc)
Attachment #194164 -
Flags: review?(caillon)
Attachment #194164 -
Flags: superreview?(roc) → superreview+
Comment 34•18 years ago
|
||
Please let me know when this patch will be checked in. I have to get this one first and have to fix the bug 325720 for AIX.
Assignee | ||
Updated•18 years ago
|
Attachment #194164 -
Flags: review?(caillon) → review?(vladimir)
I don't really want the pangocairo stuff exposed yet -- especially not in any automatic way, as this patch does. Let's just fix only the pangox/pangoxft issue -- there should be no reason to link with or include pangocairo if it's not being used.
Assignee | ||
Comment 36•18 years ago
|
||
(In reply to comment #35) > I don't really want the pangocairo stuff exposed yet -- especially not in any > automatic way, as this patch does. Let's just fix only the pangox/pangoxft > issue -- there should be no reason to link with or include pangocairo if it's > not being used. The pangocairo stuff isn't used if --enable-pango is _not_ defined but the change is needed if --enable-pango is wanted. So is it really a problem? I can change the patch to fix the pangoxft thing so that it builds at least with newer GTK versions but I think it's no problem to use pangocairo for the --enable-pango case?
Comment 37•18 years ago
|
||
*** Bug 334705 has been marked as a duplicate of this bug. ***
(In reply to comment #36) > (In reply to comment #35) > > I don't really want the pangocairo stuff exposed yet -- especially not in any > > automatic way, as this patch does. Let's just fix only the pangox/pangoxft > > issue -- there should be no reason to link with or include pangocairo if it's > > not being used. > > The pangocairo stuff isn't used if --enable-pango is _not_ defined but the > change is needed if --enable-pango is wanted. > So is it really a problem? > I can change the patch to fix the pangoxft thing so that it builds at least > with newer GTK versions but I think it's no problem to use pangocairo for the > --enable-pango case? No, there is a problem; we do not yet depend on pangocairo, only pangoxft. We should not be pulling in any pangocairo stuff at all. If another set of libraries needs to be pulled in, then we should pull those in directly, and not rely on pkg-config to give them to us as part of pulling in pangocairo. (This is sounding like a pango bug -- why is pangoxft pkgconfig not pulling in Xft libs?)
Comment 39•18 years ago
|
||
Bug 332170 landed a related fix to comment #30 on the trunk at 2006-04-24 11:27 PDT.
Comment 40•18 years ago
|
||
> No, there is a problem; we do not yet depend on pangocairo, only pangoxft. We
> should not be pulling in any pangocairo stuff at all. If another set of
> libraries needs to be pulled in, then we should pull those in directly, and not
> rely on pkg-config to give them to us as part of pulling in pangocairo. (This
> is sounding like a pango bug -- why is pangoxft pkgconfig not pulling in Xft
> libs?)
>
Comment 41•18 years ago
|
||
Wolfgang, I found after the checkins for bug333640 (linking with -z defs) additional linking trouble for building the trunk with --enable-default-toolkit=gtk2 These problems are related to this bug here but I think not totally the same. Maybe bug325720 comes closer (at least I found very similar solutions). Do you mind to have a look at bug338446 and leave a comment there, would be nice, thanks
Comment 42•18 years ago
|
||
(In reply to comment #40) On my native NetBSD build, just selecting pango at all accidentally links against pangoxft's symbols, but doesn't actually link in the library. Oops. IMHO, the way to fix this is in mozilla/configure to not have $PKG_CONFIG --whatever "pango >= 1.6.0 pangoft2 >= 1.6.0" but rather $PKG_CONFIG --whatever "pango >= 1.6.0 pangoxft >= 1.0.0" as, on my system at least, this pulls in both the ft2 and xft libs.
Comment 43•18 years ago
|
||
(In reply to comment #42) > On my native NetBSD build, just selecting pango at all accidentally links > against pangoxft's symbols, but doesn't actually link in the library. Oops. > IMHO, the way to fix this is in mozilla/configure to not have > $PKG_CONFIG --whatever "pango >= 1.6.0 pangoft2 >= 1.6.0" > but rather > $PKG_CONFIG --whatever "pango >= 1.6.0 pangoxft >= 1.0.0" > as, on my system at least, this pulls in both the ft2 and xft libs. > On my x86 linux-systems this is needed as well but not enough, when I only patch configure as you stated I still see: symbol lookup error: /usr/lib/mozilla-firefox/components/libgfx_gtk.so: undefin ed symbol: pango_xft_get_font_map when I start ff, though it builds fine (not static) I have to add $(MOZ_PANGO_LIBS) to EXTRA_DSO_LDOPTS in gfx/src/gtk/Makefile.in Then it works (see https://bugzilla.mozilla.org/attachment.cgi?id=222512 for the trunk)
Comment 44•18 years ago
|
||
No trunk patch; not going to block FF2 beta1 for this. It also looks like this might not be necessary for the 1.8 branch since the changes are pango-specific.
Flags: blocking1.8.1+ → blocking1.8.1-
Assignee | ||
Updated•18 years ago
|
Attachment #194164 -
Flags: review?(vladimir)
Assignee | ||
Comment 45•18 years ago
|
||
disabled pango case was handled by bug 332170 enabled pango case will be handled by bug 338446 so closing this one as duplicate *** This bug has been marked as a duplicate of 338446 ***
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•