First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 80720
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: AMD64 Project <amd64@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Roland Bär <roland@pinguin.tv>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
mozilla-firefox-bin-1.0.ebuild.diff mozilla-firefox-bin-1.0.ebuild.diff patch Roland Bär 2005-02-08 01:54 0000 659 bytes Details | Diff
emerge.log Output of emerge -vd emul-linux-x86-gtklibs text/plain Roland Bär 2005-03-16 03:56 0000 53.85 KB Details
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 80720 depends on: Show dependency tree
Show dependency graph
Bug 80720 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)







View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2005-02-04 07:16 0000
firefox refuses to start, effectivly:
** (firefox-bin:8134): WARNING **: /usr/lib32/pango/1.4.0/modules/pango-basic-fc.so: cannot open share
d object file: No such file or directory
Failed to load Pango module for id: 'BasicScriptEngineFc'
(firefox-bin:8134): GLib-GObject-CRITICAL **: file gobject.c: line 1561 (g_object_ref): assertion `G_I
S_OBJECT (object)' failed

** (firefox-bin:8134): CRITICAL **: file pango-engine.c: line 68 (_pango_engine_shape_shape): assertio
n `PANGO_IS_FONT (font)' failed

** ERROR **: file shape.c: line 75 (pango_shape): assertion failed: (glyphs->num_glyphs > 0)
aborting...
/usr/bin/firefox: line 88:  8134 Aborted                 $mozbin "$@"

Reproducible: Always
Steps to Reproduce:
1. emerge emul-linux-x86-gtklibs  #emerges 1.2
2. emerge firefox
3. firefox  #broken
4. emerge =emul-linux-x86-gtklibs-1.2
5. firefox  #works


Expected Results:  
Quickfix for firefox ebuild It should depend on 
                =app-emulation/emul-linux-x86-gtklibs-1.0
and not on 
                >=app-emulation/emul-linux-x86-gtklibs-1.0

Or fix emul-linux-x86-gtklibs-1.2 


With 1.1 firefox it works also, so only 1.2 is broken

------- Comment #1 From Roland Bär 2005-02-08 01:54:48 0000 -------
Created an attachment (id=50712) [edit]
mozilla-firefox-bin-1.0.ebuild.diff

Please apply attached patch to net-www/mozilla-firefox-bin-1.0.ebuild

------- Comment #2 From Octavio Ruiz (Ta^3) 2005-02-14 14:14:58 0000 -------
Happy Workarounds using app-emulation/emul-linux-x86-gtklibs-1.2 :-)

# cd /usr/lib32
# ln -s /emul/linux/x86/usr/lib/pango pango

$ firefox

:-D

------- Comment #3 From Roland Bär 2005-02-15 01:22:20 0000 -------
Thanks, this works.
Could someone fix that in the ebuild?

------- Comment #4 From Octavio Ruiz (Ta^3) 2005-02-15 11:59:36 0000 -------
I dont think so, because this is only a workaround... not an elegant or correct
solution.

Also I found other workarounds.. 

inside /etc/env.d/50emul-linux-x86-gtklibs LDPATH is missing

LDPATH="/emul/linux/x86/lib:/emul/linux/x86/usr/lib"

and other workaround is to run this regex

:%s/\/usr\/lib32\/pango/\/emul\/linux\/x86\/usr\/lib32\/pango

to this file

/etc/pango/i686-pc-linux-gnu/pango.modules


I don't know what is the right solution, so it would be nice if some amd64 dev
take a look to this. :-)

------- Comment #5 From Tom Felker 2005-02-16 12:12:14 0000 -------
I was having this bug, and I just made the symlink as suggested, and now
Firefox seems to work.  However, realplayer 10 (installed outside portage),
which was also broken before I made the symlink, has "broken image" icons in
place of where the images for Play, Stop, Pause, etc. are.  Just thought I'd
include that in case it's relevent to whoever tries to fix this correctly.

------- Comment #6 From Octavio Ruiz (Ta^3) 2005-02-16 17:46:51 0000 -------
Please use media-video/realplayer-10.0.2 instead of manually install it. Just
unmask and keyword it. If you make this, that subject becomes relevant.. :-)

------- Comment #7 From Ian Ellis 2005-03-09 22:21:47 0000 -------
Problem's still here.  I had applied the dirty hack:
# cd /usr/lib32
# ln -s /emul/linux/x86/usr/lib/pango pango

but it came back to haunt me when I upgraded to 2005.0.  So we still need a real fix.

------- Comment #8 From Ian Ellis 2005-03-09 22:31:08 0000 -------
Also, from what I can gather it's a combination of xorg-6.8.2 and
emul-linux-x86-gtklibs-1.2 that's the problem.

------- Comment #9 From Marcus D. Hanwell 2005-03-15 11:35:31 0000 -------
This should be fixed now in CVS, app-emulation/emul-linux-x86-gtklibs-1.2-r1
creates the necessary symlinks. Please emerge it (~amd64) and let me know if it
solves your problems. If not please reopen this bug.

------- Comment #10 From Ian Ellis 2005-03-15 12:36:06 0000 -------
Works here.  Thanks =]

------- Comment #11 From Ian Ellis 2005-03-15 12:38:25 0000 -------
P.S. Might be a good idea to mark v1.2(-r0) as testing rather than stable.

------- Comment #12 From Jannick Kuhr 2005-03-15 14:49:35 0000 -------
Works here too. Thanks. Possibly it's a good idea to mark it amd64, since it
seems to work much better than the most recent stable one...

------- Comment #13 From Roland Bär 2005-03-16 03:56:24 0000 -------
Created an attachment (id=53612) [edit]
Output of emerge -vd emul-linux-x86-gtklibs 

Well, seams to work elsewhere, but 

roland@ferrari /usr $ file /usr/lib32
/usr/lib32: symbolic link to `../../emul/linux/x86/usr/X11R6/lib32'
roland@ferrari /usr $ file /usr/lib32/pango
/usr/lib32/pango: broken symbolic link to
`../../emul/linux/x86/usr/lib32/pango'
roland@ferrari /usr $ file /emul/linux/x86/usr/lib32/pango
/emul/linux/x86/usr/lib32/pango: directory
roland@ferrari /usr $

I'm still using 2004.3 profile, and somehow during resoluting of pango symlink
it first resolves /usr/lib32 and then the relativ symlink doesn't work any more

Would like to suggest to make an absolute path in symlink.

------- Comment #14 From Marcus D. Hanwell 2005-03-16 04:10:51 0000 -------
You have this line in your emerge output,

>>> /emul/linux/x86/usr/lib32 -> lib

Can you check that /emul/linux/x86/usr/lib32 is a symlink to /emul/linux/x86/usr/lib? If it is then the new ebuild detects that pango and gtk-2.0 are in fact directories and so does not create any symlinks. If it is not then there is a problem with your emul-* installation.

------- Comment #15 From Roland Bär 2005-03-16 05:34:01 0000 -------
Yes, /emul/linux/x86/usr/lib32 -> lib, but no help ...

I then unmerged all emul-linux-x86-* packaged, did rm -fr /emul (Some lonesome files, mainly X11 related were still in), then emerge mozilla-firefox-bin 

=> Works (!)

Thanx

------- Comment #16 From Roland Bär 2005-03-29 05:18:23 0000 -------
Sorry, after updating to 2005.0 profile (Makefile-profile_update-2005.0)
this problem has re-apppeared. See http://www.pinguin.tv/firefox-2.txt

I let this "as-is" now for further analyse requests...

------- Comment #17 From Michael Ploujnikov 2005-03-29 08:58:01 0000 -------
Indeed, the problem re-appeared in 2005.0 for me too.
I solved it with the symlink to /emul/linux/x86/usr/lib/pango.

------- Comment #18 From Octavio Ruiz (Ta^3) 2005-03-29 11:54:01 0000 -------
Try reemerging app-emulation/emul-linux-x86-gtklibs-1.2-r1 ?

I switched to 2005.0 a long time ago, so I had this problem with 2005.0.

------- Comment #19 From Michael Ploujnikov 2005-03-29 16:08:55 0000 -------
Ok with emul-linux-x86-gtklibs-1.2-r1 firefox-bin works as that ebuild creates
the  pango symlink.
I'm wondering, wouldn't it be more appropriate if this is fixed in a way
similar to what Octavio Ruiz (Ta^3) suggested. The symlink seems a bit hacky
just for firefox to work. Of course, I don't know what other apps might or
might not depends on this symlink.

------- Comment #20 From Marcus D. Hanwell 2005-03-29 16:44:07 0000 -------
The fix supplied in app-emulation/emul-linux-x86-gtklibs-1.2-r1 works, and also
fixes issues with several other 32 bit apps (acroread 7 springs to mind), and
so represents the cleanest available solution. Not sure why the symlink is
nuked during upgrade, but it can be reestablished by reemerging the appropriate
emul lib.

I consider this issue fixed, if others have this issue I will ask for a note to
be added to the upgrade guide about emerging emul libs after the upgrade.

------- Comment #21 From Roland Bär 2005-03-30 00:06:18 0000 -------
Ok, re-emerging emul-linux-x86-gtklibs-1.2-r1 only has solved this issue.
ACCEPT_KEYWORDS="~amd64" emerge emul-linux-x86-gtklibs
firefox, acroread work again. 

So the update to 2005.0 breaks this, we need to re-emerge above package.

This should be added to the upgrade guide.

------- Comment #22 From Ian Ellis 2005-03-31 09:04:16 0000 -------
Please refrain from using commands such as ACCEPT_KEYWORDS="~amd64" emerge
emul-linux-x86-gtklibs.  For more information see this post in the forums:
http://forums.gentoo.org/viewtopic-p-1060314.html#1060314

Even if you know what you're doing and know how to avoid the problems it can
cause, mentioning it can lead other users to try it and break their systems.

------- Comment #23 From Roland Bär 2005-04-01 03:04:33 0000 -------
Sorry, as noted in comment 20 this issue is principially fixed in 1.2-r1,
but 1.2-r1 is still marked as "~amd64". So without (re)emerging that masked
version, this package renders useless, no firefox-bin, no acroread.

Can you give other advise, avoiding ~amd64 keyword, to get 1.2-r1 emerged 

------- Comment #24 From Marcus D. Hanwell 2005-04-01 03:15:49 0000 -------
If you sync you will find that I have in fact marked
emul-linux-x86-gtklibs-1.2-r1 stable (a few days ago now), as it fixes these
issues. So you will not have to use anything in ~amd64 now.

------- Comment #25 From Ian Ellis 2005-04-01 13:33:08 0000 -------
In the future, just use the package.keywords file to mix stable and testing
branches:
http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=3#doc_chap2

------- Comment #26 From Herbie Hopkins (RETIRED) 2005-04-03 15:34:37 0000 -------
*** Bug 86828 has been marked as a duplicate of this bug. ***

------- Comment #27 From Roland Bär 2005-04-18 02:07:18 0000 -------
Sorry, this "exactly" appears again with the 2.0 series of emul-linux-x86-*
ebuilds 

------- Comment #28 From Herbie Hopkins (RETIRED) 2005-04-18 03:49:53 0000 -------
I just commited emul-linux-x86-gtklibs-2.1 to CVS which should solve this
problem (again). Please upgrade and be sure you run etc-update. Let me know if
this fixes it for you.

------- Comment #29 From Roland Bär 2005-04-18 04:36:36 0000 -------
Ok, emul-linux-x86-gtklibs has fixed it again.

------- Comment #30 From Elias Faraclas 2006-12-08 17:04:32 0000 -------
(In reply to comment #29)
> Ok, emul-linux-x86-gtklibs has fixed it again.
> 

It appears that this is an issue again.  I am using
emil-linux-x86-gtklibs-2.10.6.3 and anything 32-bit is screaming about pango
and I can't read anything.  I noticed that the error is that it can't find the
pango/1.4.0 libs when in fact pango/1.5.0 is the one that exists.  Can anyone
help?

First Last Prev Next    No search results available      Search page      Enter new bug