Cross compiling print driver only

Hi,

Please can you try the below configuration command in the hplip-3.11.7 source.

./configure --prefix=/usr --enable-qt3 --disable-qt4 --enable-hpijs-install --enable-foomatic-rip-hplip-install --enable-foomatic-ppd-install --disable-dbus-build --disable-fax-build --libdir=/usr/lib64

If makes configure terminate with "cannot find libcups support". Try installing the "libcups-devel" package.
Let us know on the same.

Thanks & Regards,
Goutam Kodu

Hi Goutam,
I can try, but where will it bring me? I want to build a driver for my embedded MIPS platform, not a driver for the x64 build host.

Consequently, I don't want to "install" the driver on the build machine...

libcups-devel is already installed, for x64. I think I figured out that I need an entire MIPS CUPS-2 system built first, in order to build the hpcups driver.

Question: Apart from the building the problem I have, is the hpijs driver still maintained with regard to new HP devices?

Best regards
Henrik

Hi Henrik,

The configure command will configure only hpijs and create the make file which compiles the hpijs code. You can create a RPM of the compiled code if you don't want to install it. You can eliminate the option --libdir=/usr/lib64 from the configure command.

HPIJS driver is not maintained for new HP devices. As now all the distros are using CUPS there is only hpcups support. We do ship hplip rpm package with hpijs build only for RHEL 5.

Let me know if you need anything.

Thanks & Regards,
Goutam Kodu

Hi Goutam,

thanks for your explanation!

Building hpijs is not really interesting when no new printers get introduced. We have hpijs 3.9.4b in use already.

Yes, all distros use CUPS, but many embedded systems must be pretty lost, like ours. We have a Qt app running directly on the linux kernel (no desktop, no X, working directly on the frame buffer). We needed a simple print facility with a connected USB printer. For this purpose, the GhostScript + hpijs solution was ingenious: use "htmldoc" to create Postscript; feed the Postscript to GS+hpijs, and feed the output directly to the printer device. That's it. The printer ID string is read by a simple ioctrl and passed as parameter to hpijs. The entire printing module in the app, including print queue admin, is some 600 lines of C++ code.

CUPS is a monster to implement on such a system! And a monster we don't need - except for, it seems like we need it now if we want to continue the support of HP printers.

I realize there is probably not much you can do about this, but of course any "shortcut" suggestions will be appreciated!

Best regards
Henrik

bum...

Ditto this entire question, but s/MIPS/ARM/g

This is exactly what we do. .ps > gs-esp > hpijs > /dev/usb/lp0

New printer has arrived (Specifically, HP OfficeJet 100, mobile device). Old hpijs won't fly. Debian ARM binaries are now all built against too new versions of libraries, so need to do it myself.

Seems nuts to have to haul in a whole CUPS distribution that I have no need of (and the board, with only 2Mb of flash isn't going to be able to house).

I too was expecting a configure with "--enable-hpijs-install" to deliver me a hpijs binary >:-(. If we can't get this to fly we'll have to stop buying HP printers, as the old working model is discontinued.

I took up the war and built a stripped down CUPS system for MIPS. What is needed by hpcups is the libraries libcups and libcupsimage - they are "only" some 500kB in total. The basic working of imagetoraster -> hpcups -> /dev/usb/lp0 was verified.

Now, the problem is GhostScript (gs), in a version with CUPS support, to generate the raster input to hpcups. gs is obviously in "Don't Care About It" mode, when it comes to cross compiling - it's a nightmare. (Hint, for those going for it: Use the undocumented CUPSCONFIG environment var to point out the cups-config script of your cross-CUPS; otherwise gs will try to link all the libraries required by the build host's native CUPS - this will probably include things as weird as Kerberos support!).

I got a build of gs 9.04 - that doesn't work on the MIPS :( "Something" goes wrong in the interpreter, already when processing the init file, but it's off topic for this forum.

Anyway, you end up with an extremely bulky system - just have to mention the (currently) 675 .ppd files! - and you will need a method to map from printer ID to ppd file name - that bit is obviously intended to be handled by the CUPS main framework, which we won't have in an embedded environment.

So, like Nigel, we may end up dropping HP printer support entirely. And we ourselves do feel a bit "dropped" by HP in this matter.

Hi - I have had some success, maybe this will work for you too (modulo whatever the crosscompiler you need):

./configure --target=arm-unknown-linux-gnu --host=arm-unknown-linux-gnu --enable-hpijs-install --disable-network-build --disable-dbus-build --disable-fax-build --enable-hpijs-only-build --enable-static

This actually made the hpijs binary! Hurrah!

On the board itself, we have an older version of gs-esp (7.07 I think), and the following recipe works for us (hpijs in /usr/bin)

/usr/bin/gs-esp -sDEVICE=ijs -sIjsServer=hpijs -sDeviceManufacturer="HEWLETT-PACKARD" -sDeviceModel="Deskjet 460" -sOutputFile="/dev/usb/lp0" -dpox=0 -dpoy=0 -dNOPAUSE -dSAFER -dIjsUseOutputFD -dBATCH <whatever>.ps

It works. It's not speedy (well, it never was), but it does appear to work.

Alternatively, my Plan B was which you might try if the build doesn't work is to nab a binary from debian and use that:

http://packages.debian.org/sid/hpijs

This can be timeconsuming because you often have to gradually replace libfiles on your board (e.g: libgcc) to get it to work.

As a side note, interestingly the output appeared correctly on this HP OfficeJet 100 even though the DeviceModel was set to "DeskJet 460". My older hpijs driver didn't. Quite why we need to be faffing around with updating printer drivers in 2011, I find it hard to understand...

Thanks for the hints! We had the gs+hpijs solution working for years now; apart from mu recent building problem with hpijs, the main issue is that hpijs is no longer maintained with new printers.

Our here and now problem is a Deskjet 3000. As a quick hack, I added that printer to the list in hpijs::djgenericvip.h. It almost works... it's just that the bottom line of the page isn't printed correctly. This appears to be a well known issue, see https://answers.launchpad.net/hplip/+question/57765. However, the fix proposed here doesn't seem to work in my case.

Still, this would only be a fix for this particular printer. Within short time, most or all of the printers supported officially by hpijs will be EOL.