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?
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.
Applied, thanks!