Bug 429345

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!