Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Re: [Omniprint-user] espgs-7.05.5(omni-0.7.1): could not load libomni.so

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: John T Copeland <johnc AT neto.com>
  • To: Jason Flatt <jasonflatt AT wizard.com>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Re: [Omniprint-user] espgs-7.05.5(omni-0.7.1): could not load libomni.so
  • Date: Wed, 25 Dec 2002 10:20:35 -0600

Jason,
See my answers below.


Jason Flatt wrote:

FYI, I'm removing the omni people from this replay as I suspect that they will be uninterested in SMGL stuff.

Of course.


On Tuesday 24 December 2002 05:23 pm, John T Copeland wrote:

Jason, Mark,
A follow up and final on this. I finally got my printer to work
properly. I did the following to get there.
1) Downloaded omni-0.7.2. Configured, compiled, installed AOK.
libomni.so showed up in /opt/omni/lib. Mark, I had a small proplem
here. I deleted all the printers in devices.mak except Panasonic, and
the compile failed with some error related to Hewlett Packard. I add HP
back to devices.mak and compile went OK.
2) Downloaded espgs-7.05.5 from the CVS, did a makesrcdist, replaced my
version in /var/spool/sorcery. An install(cast -r -c) of espgs then
configured, compiled, and installed OK.
3) Reviewed all my cupsomatic and PPD stuff
4) Printed a simple text file OK
5) Tried the test print in CUPS, and it failed looking for a particular
font.
6) Investigation showed the standard ghostscript fonts had disappeard.
Probably because espgs install had done away with them.
7) Installed(cast -r -c) ghostscript-fonts-std, and the CUPS test ,
print a test page, worked.

Jason, it appears the espgs spell needs to be upgraded for the omniprint
driver. You copy?
JohnC



In attempting to provide solution(s) for you (and others who would be interested in persuing a similar path), I have come up with some questions for you:

1) Did you build Omni from the source tar, or from CVS?

From the tarball on the Omni download site. espgs from CVS because of Omni related errors in the tarball.

2) Did you use GCC 2 or 3?

3.2.1

3) Did you answer "y" to including Omni in ESPGS, or not?

Yes, which adds the Omni interface, but not the Omni library, to the espgs device list.

4) Did you build Omni as an integral part of ESPGS, ie: copied the Omni


source into the appropriate place within the espgs source, or as a separate packag

As a separate package, it was a manual, ./setup, ./make install, ./makelocal install. The tarball contains the ability to build/install the library, and patches(the additon of a "omni.c" function and code mods to call it) for various versions of ghostscipt so the build of ghostscipt will add omni to the device table. espgs has the "omni.c" availabe for the omni configure option, while ghostcript does not.

5) Are you suggesting that there may need to be some sort of trigger which causes ghostscript-fonts-std to be recast after espgs, or was that just a fluke?

Not sure. I had previously installed the fonts at the same time I installed ghostscript(not espgs) in my first attempt to get my printer up, and somewhere along the way the fonts disappeared, so I simply did a re-cast. It does appear that the fonts are required, and may need to be a required dependency of espgs. I simply don't know that much about ghostscript and how it relates to CUPS. ghostscript probably does't relate to CUPS, except indirectly if required by cupsomatic. In the case of omni(and my Panasonic KX-P2124 printer) and the CUPS 'print a test page' function the fonts were required. Probably not be required with other printers, or non-omni supported printers, since Omni uses the ghostscript framework and is dependent on it.


My plan is to create a separate spell for Omni and a dev/cvs spell for espgs. If Omni does not work correctly (or at all) with the way it is currently implemented (as an integral part of espgs), then I will remove it.

The key here is that if the Omni option is selected in espgs, then the Omni library is required, which is a separate download than espgs. Only the interface to the Omni library(libomni.so), not the total Omni functionality, is included as an integral part of espgs as it is currently implemented. As the espgs spell is currently implemented, if the omni option was selected, only a configure/compile/install of the Omini library tarball would need to be added. The tarballs is already downloaded as you know. I used CVS only to fix the Omni interface bugs reported in the IBM Omni website.

Of course all the cupsomatic stuff further complicates the printer issue. I don't know how much of a burden the proper integration of all this printer stuff is to SMGL users, but it is a significant problem, as printing always was/is. Jason, this is a really tough problem for users and a tough problem for spell writing. One could argue that ghostscript(espgs) is an optional dependency of CUPS if a users printer is not a postscript printer(which most aren't). So you can see that s CUPS capability has to integrate CUPS, PPD's, cupsomatic, ghostscript(if it integrally supports your printer), and espgs perhaps for Omni.

I don't believe it is possible to put all this together in a simple(or even a comlicated simple) spell. Omni supports a lot of printers and others will be added as time marches on, so I think Omni needs to be part of SMGL if it can be installed properly as a part of espgs.

Also it would be nice if this functionality for non-postscript printers and CUPS could somehow be cookbooked for SMGL users.

Dependency Hell continues unabated.




JohnC






Archive powered by MHonArc 2.6.24.

Top of Page