Closed Bug 305185 Opened 14 years ago Closed 13 years ago

gtk 2.8 builds are broken due to missing xft dependencies

Categories

(Firefox Build System :: General, defect, major)

1.8 Branch
x86
Linux
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 338446
mozilla1.8.1

People

(Reporter: wolfiR, Assigned: wolfiR)

References

Details

Attachments

(1 file, 2 obsolete files)

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.
pangox-1.0 is also missing in LDFLAGS
Summary: aviary 1.0.x fails with gtk 2.8 → aviary 1.0.x build fails with gtk 2.8
Seems that every static build suffers from this problem. Even for
MOZILLA_1_8_BRANCH.
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
Attached patch first try (obsolete) — Splinter Review
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
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
Attached patch gtk2.8 patch (obsolete) — Splinter Review
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.
Summary: static builds fails with gtk 2.8 → static build fails with gtk 2.8
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...
(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.
Attachment #194164 - Flags: first-review?(jshin1987)
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 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)
Flags: blocking1.8rc1?
why does this not fail for our builds? 
Asa, I wonder if you run any gtk 2.8 tinderboxen yet?
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-
*** Bug 310838 has been marked as a duplicate of this bug. ***
(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.
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.
Blocks: 313911
bryner, maybe you can comment/review on that?
Would be nice to have this on trunk soon.
(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.
*** 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
*** Bug 319585 has been marked as a duplicate of this bug. ***
(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.
(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.
(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.
How about getting it for Firefox2.
(Trunk might not need the change with all the new stuff)
Flags: blocking-firefox2?
(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
(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
(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. 

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
Flags: first-review?(caillon)
Flags: blocking-firefox2?
Product: Toolkit → Core
Target Milestone: --- → mozilla1.8.1
Version: unspecified → 1.8 Branch
Flags: blocking1.8.1+
(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+"$@"}
(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.

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+
Blocks: 325720
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. 
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.
(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?
*** 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?)
Bug 332170 landed a related fix to comment #30 on the trunk at 2006-04-24 11:27 PDT.
> 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?)
> 

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
(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.
(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)
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-
Attachment #194164 - Flags: review?(vladimir)
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: 13 years ago
Resolution: --- → DUPLICATE
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.