gtk 2.8 builds are broken due to missing xft dependencies

RESOLVED DUPLICATE of bug 338446

Status

()

Core
Build Config
--
major
RESOLVED DUPLICATE of bug 338446
12 years ago
3 years ago

People

(Reporter: wolfiR, Assigned: wolfiR)

Tracking

1.8 Branch
mozilla1.8.1
x86
Linux
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8rc1 -
blocking1.8.1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

12 years ago
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

12 years ago
pangox-1.0 is also missing in LDFLAGS
(Assignee)

Updated

12 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

12 years ago
Seems that every static build suffers from this problem. Even for
MOZILLA_1_8_BRANCH.
(Assignee)

Comment 3

12 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

12 years ago
Created attachment 193921 [details] [diff] [review]
first try
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
(Assignee)

Comment 5

12 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

12 years ago
Created attachment 194062 [details] [diff] [review]
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.
(Assignee)

Updated

12 years ago
Summary: static builds fails with gtk 2.8 → static build fails with gtk 2.8
(Assignee)

Comment 7

12 years ago
Created attachment 194164 [details] [diff] [review]
gtk2.8 patch (#2)
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

12 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

12 years ago
Attachment #194164 - Flags: first-review?(jshin1987)

Comment 10

12 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 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?

Comment 12

12 years ago
why does this not fail for our builds? 
(Assignee)

Comment 13

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

Comment 14

12 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-
*** Bug 310838 has been marked as a duplicate of this bug. ***

Comment 16

12 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

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

Updated

12 years ago
Blocks: 313911
(Assignee)

Comment 18

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

Comment 19

12 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

12 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
*** Bug 319585 has been marked as a duplicate of this bug. ***

Comment 23

12 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

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

12 years ago
How about getting it for Firefox2.
(Trunk might not need the change with all the new stuff)
Flags: blocking-firefox2?

Comment 27

12 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

12 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

12 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

12 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

12 years ago
Component: Build Config → Build Config
Flags: first-review?(caillon)
Flags: blocking-firefox2?
Product: Toolkit → Core
Target Milestone: --- → mozilla1.8.1
Version: unspecified → 1.8 Branch

Updated

12 years ago
Flags: blocking1.8.1+

Comment 31

12 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

12 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

11 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+
(Assignee)

Updated

11 years ago
Blocks: 325720

Comment 34

11 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

11 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

11 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?
*** 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?)
> 

Comment 41

11 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

11 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

11 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

11 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

11 years ago
Attachment #194164 - Flags: review?(vladimir)
(Assignee)

Comment 45

11 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
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.