Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 120220

Summary: devhelp can't find libgtkembedmoz.so
Product: [Fedora] Fedora Reporter: George Karabin <gkarabin>
Component: devhelpAssignee: Jonathan Blandford <jrb>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: ddumas, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-04-20 20:38:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 114961    
Attachments:
Description Flags
cleanear workaround - exporting LD_LIBRARY_PATH in devhelp script none

Description George Karabin 2004-04-06 21:56:41 UTC 
Description of problem:

The new devhelp is embedding gecko for HTML (spiffy) but it's caused a
hiccup, at least on my box.

$ devhelp
/usr/bin/devhelp-bin: error while loading shared libraries:
libgtkembedmoz.so: cannot open shared object file: No such file or
directory


Version-Release number of selected component (if applicable):

0.9-1

How reproducible:

100%

Additional info:

I'm not sure why devhelp has the problem and epiphany doesn't. Both
are dynamically linked against /usr/lib/mozilla-1.6/libgtkembedmoz.so. 

The quick hack is to fix up ld.so.conf with the path or symlink from
mozilla lib location to something already in the standard ld.so path,
pushing it to a mozilla packaging issue. But since epiphany doesn't
have a problem, maybe there's a better way to handle it that ought to
be pushed upstream to devhelp, or maybe it's a build time option?
Comment 1 George Karabin 2004-04-06 22:10:45 UTC 
Created attachment 99164 [details]
cleanear workaround - exporting LD_LIBRARY_PATH in devhelp script

This workaround is perhaps cleaner than hacking ld.so.conf. The epiphany
wrapper script does the same thing. 

Oddly enough, after playing a bit, it appears epiphany-bin is linked to the
absolute path /usr/lib/mozilla-1.6, so exporting LD_LIBRARY_PATH probably isn't
needed there. However, devhelp-bin isn't, but the wrapper script doesn't export
the variable.
Comment 2 Colin Walters 2004-04-20 20:38:05 UTC 
Applied, thanks!