305185 - gtk 2.8 builds are broken due to missing xft dependencies

Status: RESOLVED DUPLICATE of bug 338446

(Firefox Build System :: General, defect)

Description

[Wolfgang Rosenauer [:wolfiR]]

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.

Comment 1

[Wolfgang Rosenauer [:wolfiR]]

pangox-1.0 is also missing in LDFLAGS

Comment 2

[Wolfgang Rosenauer [:wolfiR]]

Seems that every static build suffers from this problem. Even for
MOZILLA_1_8_BRANCH.

Comment 3

[Wolfgang Rosenauer [:wolfiR]]

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

Comment 4

[Wolfgang Rosenauer [:wolfiR]]

Attachment: first try

Comment 5

[Wolfgang Rosenauer [:wolfiR]]

Comment on attachment 193921 [details] [diff] [review]
first try

this one is incomplete and wrong :-(
Have to do some more investigation.

Comment 6

[Wolfgang Rosenauer [:wolfiR]]

Attachment: gtk2.8 patch

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.

Comment 7

[Wolfgang Rosenauer [:wolfiR]]

Attachment: gtk2.8 patch (#2)

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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...

Comment 9

[Wolfgang Rosenauer [:wolfiR]]

(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.

Comment 10

[Heinrich Witt]

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

[Benjamin Smedberg]

Comment on attachment 194164 [details] [diff] [review]
gtk2.8 patch (#2)

Caillon would be better off reviewing this, no?

Comment 12

[Asa Dotzler [:asa]]

why does this not fail for our builds? 

Comment 13

[Wolfgang Rosenauer [:wolfiR]]

Asa, I wonder if you run any gtk 2.8 tinderboxen yet?

Comment 14

[Asa Dotzler [:asa]]

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.

Comment 15

[Crispin Flowerday (not receiving bug mail)]

*** Bug 310838 has been marked as a duplicate of this bug. ***

Comment 16

[Jan Klier]

(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.

Comment 17

[Wolfgang Rosenauer [:wolfiR]]

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.

Comment 18

[Wolfgang Rosenauer [:wolfiR]]

bryner, maybe you can comment/review on that?
Would be nice to have this on trunk soon.

Comment 19

[Logan Rathbone]

(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

[Marco Perez [:mpk]]

*** Bug 316065 has been marked as a duplicate of this bug. ***

Comment 21

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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...

Comment 22

[Frank Wein [:mcsmurf]]

*** Bug 319585 has been marked as a duplicate of this bug. ***

Comment 23

[bugzilla]

(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.

Comment 24

[Wolfgang Rosenauer [:wolfiR]]

(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

[J. Paul Reed [:preed]]

(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.

Comment 26

[Wolfgang Rosenauer [:wolfiR]]

How about getting it for Firefox2.
(Trunk might not need the change with all the new stuff)

Comment 27

[Jungshik Shin]

(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

Comment 28

[Wolfgang Rosenauer [:wolfiR]]

(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

[Jungshik Shin]

(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

[Marco Perez [:mpk]]

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

Comment 31

[Brent Northam]

(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

[Brent Northam]

(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 33

[Wolfgang Rosenauer [:wolfiR]]

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

Comment 34

[Ganesh]

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. 

Comment 35

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 36

[Wolfgang Rosenauer [:wolfiR]]

(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

[Nick Thomas [:nthomas] (UTC+12)]

*** Bug 334705 has been marked as a duplicate of this bug. ***

Comment 38

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(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

[Nick Thomas [:nthomas] (UTC+12)]

Bug 332170 landed a related fix to comment #30 on the trunk at 2006-04-24 11:27 PDT.

Comment 40

[Myk Melez [:myk] [@mykmelez]]

> 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

[Walter Meinl]

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

[moof]

(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

[Walter Meinl]

(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

[Darin Fisher]

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.

Comment 45

[Wolfgang Rosenauer [:wolfiR]]

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 ***