Bugzilla – Bug 429345
CUPSToOmni: Fatal error: unable to load "libHP_LaserJet_8000.so"
Last modified: 2010-11-27 21:26:07 UTC
Trying to add a printer to my openSUSE 11.0 x86_64 system works, but I'm unable to print anything. Digging into the /var/log/cups/error_log file I see the msg CUPSToOmni: Fatal error: unable to load "libHP_LaserJet_8000.so" by doing the following the problem is resolved: $ echo /usr/lib64/ghostscript/Omni >> /etc/ld.so.conf $ ldconfig Should the ghostscript-omni package be adding this library path to /etc/ld.so.conf? ================================== System Details ================================== $ rpm -qa | grep omni ghostscript-omni-8.62-17.1 $ rpm -ql ghostscript-omni | grep libHP_LaserJet_8000.so /usr/lib64/ghostscript/Omni/libHP_LaserJet_8000.so /usr/lib64/ghostscript/Omni/libHP_LaserJet_8000.so.2 /usr/lib64/ghostscript/Omni/libHP_LaserJet_8000.so.2.0.0 $ tail -n25 /var/log/cups/error_log I [23/Sep/2008:16:52:07 -0600] Saving printers.conf... I [23/Sep/2008:16:52:07 -0600] New printer "8000" added by "root". I [23/Sep/2008:16:52:43 -0600] Started "/usr/lib64/cups/daemon/cups-driverd" (pid=27322) E [23/Sep/2008:16:52:43 -0600] [cups-driverd] Unable to open driver directory "/usr/lib64/cups/driver": No such file or directory I [23/Sep/2008:16:52:43 -0600] Started "/usr/lib64/cups/daemon/cups-deviced" (pid=27324) I [23/Sep/2008:16:52:47 -0600] [Job 1] Adding start banner page "none". I [23/Sep/2008:16:52:47 -0600] [Job 1] Adding job file of type application/postscript. I [23/Sep/2008:16:52:47 -0600] [Job 1] Adding end banner page "none". I [23/Sep/2008:16:52:47 -0600] [Job 1] Queued on "8000" by "ken". I [23/Sep/2008:16:52:47 -0600] [Job 1] Started filter /usr/lib64/cups/filter/pstops (PID 27381) I [23/Sep/2008:16:52:47 -0600] [Job 1] Started filter /usr/lib64/cups/filter/pstoraster (PID 27382) I [23/Sep/2008:16:52:47 -0600] [Job 1] Started filter /usr/lib64/cups/filter/CUPSToOmni (PID 27383) I [23/Sep/2008:16:52:47 -0600] [Job 1] Started backend /usr/lib64/cups/backend/ipp (PID 27384) E [23/Sep/2008:16:52:48 -0600] [Job 1] CUPSToOmni: Fatal error: unable to load "libHP_LaserJet_8000.so", g_module_error returns "libHP_LaserJet_8000.so: cannot open shared object file: No such file or directory" E [23/Sep/2008:16:52:48 -0600] [Job 1] CUPSToOmni: No pages printed! E [23/Sep/2008:16:52:48 -0600] PID 27383 (/usr/lib64/cups/filter/CUPSToOmni) stopped with status 1! I [23/Sep/2008:16:52:48 -0600] Hint: Try setting the LogLevel to "debug" to find out more.
This should not happen as the library path is compiled into the relevant library libomni.so.2.0.0 of ghostscript. And AFAICS the binary CUPSToOmni also knows about this path and uses g_module_open() (not dlopenm(3)) to load the libraries. On i386 this is boole:/> strings /usr/lib/cups/filter/CUPSToOmni | grep /Omni /usr/lib/ghostscript/Omni boole:/> ldd /usr/lib/cups/filter/CUPSToOmni | grep /Omni libomni.so.2 => /usr/lib/ghostscript/Omni/libomni.so.2 (0xb7d14000) libOmniXMLLibrary.so.0 => /usr/lib/ghostscript/Omni/libOmniXMLLibrary.so.0 (0xb7ba8000) and this had work at least on 10.3. A possible explanation could be that there has been a change in the libglib and libgmodule. Michael?
Michael? Please provide an answer on my question.
Michael? Would you please provide an answer about this bug?
*** Bug 430711 has been marked as a duplicate of this bug. ***
I'm not aware of any big changes in libgmodule, so all I can suggest is installing debuginfo packages and setting breakpoints at g_module_open to see what's going on.
This issue was present in SLED11 beta1, but has been fixed in SLED11 beta2. I am able to print to HP JetDirect printers in SLED11 beta2.
This is very interesting, it would be nice to know whats the difference between beta1 and beta2 .. Thorsten, do you know more about?
No, I don't track GNOME or glib or whatever libraries. Toolchain had no changes.
(In reply to comment #6 from Joseph Marton) > This issue was present in SLED11 beta1, but has been fixed in SLED11 beta2. I > am able to print to HP JetDirect printers in SLED11 beta2. > In that case, can I close this?
Hmmm .. I'd like to know *why* this now works. This because this may help to fix this problem not only in SLES11 but also in openSuSE 11.0 and also avoud this problem in openSuSE 11.1 *and* all SP of the SLES11. Otherwise we may run onto the same problem without knowing *why*.
In beta3 I am unable to print again. Trying to print from OOo I simply get "Error while printing" and nothing prints. From within Gedit's Print dialog both printers I've setup are greyed out and the status says "Rejecting Jobs." Would you like me to upload some logs to see if this is the same issue again or a different issue?
(In reply to comment #11 from Joseph Marton) > In beta3 I am unable to print again. Trying to print from OOo I simply get > "Error while printing" and nothing prints. From within Gedit's Print dialog > both printers I've setup are greyed out and the status says "Rejecting Jobs." > Would you like me to upload some logs to see if this is the same issue again or > a different issue? How did you add your printer? If this is with system-config-printer, it's possible you're hit by bug 433634.
Ah, looks like what I'm seeing is indeed bug 433634 and bug 437176. So please disregard comment 11. :-)
I hate bugzilla ping pong bounces ... @Federico: is the problem of libglib2 now fixed that is that compiled in paths for detection of shared object files will be handled by libglib2. @Johannes: please can you test this drivers?
I am afraid, currently I have no time to do driver tests (see bug #438867).
Please read http://en.opensuse.org/Bugs/Definitions#Bug_Severities
I have this same bug (I suppose) with opensuse 11.1. See: http://lists.opensuse.org/opensuse/2009-01/msg00452.html Is there a workaround (as this one does not seem to be solved)?? I need printing badly.
NEEDINFO on federico (see comment #16)
Ping! Federico? Any news about comment #16 ?
Well - g_module_open is a curious method; it tries perhaps too hard sometimes. eg. it will load .la files if it can find them - so potentially the behaviour is different with or without -devel packages installed: that could be one potential source of problems. L1 de Braal - any chance of an 'strace -f' log of cups; not that sure how to generate that - but something like: strace -f -o /tmp/log -p `pidof cupsd` as root might do it - then attach /tmp/log.
I'd like to understand why this: %if %suse_version >= 1030 mkdir %{buildroot}/etc/ld.so.conf.d echo %{_libdir}/ghostscript/Omni > %{buildroot}/etc/ld.so.conf.d/ghostscript-omni.conf %endif and %if %suse_version >= 1030 %config /etc/ld.so.conf.d/ghostscript-omni.conf %endif seemingly have no effect in the RPM. It seems quite clear at some point these files were put there so the file could be dlopen'ed properly.
Does this mean that my current workaround in ghostscripts spec file is useless? I've done this change on Thu Jan 8 16:13:06 CET 2009 and suspected that this will work due the initial report. OK it requires the include line within /etc/ld.so.conf but AFAIK there is no difference between adding a line to /etc/ld.so.conf or an include file.
(In reply to comment #24) > Does this mean that my current workaround in ghostscripts spec file > is useless? I've done this change on Thu Jan 8 16:13:06 CET 2009 > and suspected that this will work due the initial report. OK it > requires the include line within /etc/ld.so.conf but AFAIK there > is no difference between adding a line to /etc/ld.so.conf or an > include file. No, I was looking at the wrong source/spec combo, so new versions should work. However, I also looked at 10.3 to see what might have changed. There was no libHP_LaserJet_8000.so shlib in the 10.3 ghostscript-omni package. In fact on 10.3 the ghostscript-omni package contained no .so shlibs. Given that, I'm not sure claiming that g_module_* changed is right since on 10.3 no omni libs from the omni package were actually being loaded. FWIW I could find no substantive non-windows changes in that area of glib for at least the past 2 years.
11.0 is obsolete now and there was not enough information for this bug to get fixed. I'll close this as NORESPONSE. If you can still reproduce it in 11.3 or a milestone of 11.4, please reopen the bug and move it to the appropriate product. Thanks!