Summary: | app-text/acroread-7.0.1.1 coredumps on start-up. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jason McGuiness <gentoo-bugs> |
Component: | New packages | Assignee: | Printing Team <printing> |
Status: | RESOLVED WORKSFORME | ||
Severity: | blocker | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | My emerge info. |
Description
Jason McGuiness
2005-08-23 12:14:15 UTC
Created attachment 66676 [details]
My emerge info.
Note that this is probably the same bug as listed in 97801, "https://bugs. gentoo.org/show_bug.cgi?id=97801". In fact that package should also be marked as "testing" as it is also certainly not stable. The only acroread that I find is stable is v5.10, which is, ironically, hard masked.... I have been successfully using 7.0.0.2-r2 since it was marked stable about a month ago. However, after upgrading recently to 7.0.1.1 I hit this bug. Furthermore, even when I unmerge 7.0.1.1 and then emerge 7.0.0.2-r2 I now encounter the coredump with 7.0.0.2-r2. search in the forums for this looks like many people got this problem and this seems to be solved when you remove your ~/.adobe dir see this http://forums.gentoo.org/viewtopic-t-349418-highlight-acroread.html reopen if you still have problems. For all acroread-7.* release I had to change export GCONV_PATH="/usr/lib/gconv" to export GCONV_PATH="/emul/linux/x86/usr/lib/gconv" in the beginning of the acroread script. I wonder how it could work for someone (under amd64) otherwise. Modifying the GCONV_PATH in the acroread script made it work for me. Thanks. |