Re: libcups.dylib and network difficulties

• Subject: Re: libcups.dylib and network difficulties
• From: Alan Somers <email@hidden>
• Date: Fri, 7 Jan 2005 00:03:37 -0600
• Delivered-to: email@hidden
• Delivered-to: email@hidden

As we suspected, it's apparently a problem with the library version in Panther. I temporarily substituted the newer dylib and the app continues to operate correctly. Reverting back to the Panther version causes the problem to reappear.

I think I'll stick with the static library so that the Panther system doesn't need to be patched for my app to work. Maybe when Tiger comes out I'll create a version of the app that uses the dylib. Thanks for the assistance.

Alan

On Jan 5, 2005, at 10:53 AM, Jim Lovell wrote:

When ld(1) inserts the library dependancy into an executable it records the "install name" of the library. You can see this set in the cups/Makefile rule for libcups.2.dylib with the "-install_name" option. The otool(1) '-D' option will show you what the value is.

There have been a number of small changes in libcups' http engine since Panther so that might explain it. I integrated Michael's 1.1.23 release yesterday so you may want to update your source before doing any more testing.

Jim

On Jan 5, 2005, at 5:16 AM, Alan Somers wrote:

Does the loader not look at the path of the library as referenced in XCode? If not, it would explain a great many things, such as why debug messages were not being output after I built the CUPS library with debug turned on. I'll try it again with /usr/lib/libcups.dylib temporarily replaced with the version I built and see if it makes any difference.

I am using fairly recent CUPS code for building the library (copied from the Apple CVS sources), so I guess it's possible that something changed between the version that Panther is currently using and the newer version that fixed the problem.

I'll do some more testing in the next few days and post my findings.

On Jan 5, 2005, at 2:11 AM, Jim Lovell wrote:

Alan, comments below...

On Jan 4, 2005, at 8:28 PM, Alan Somers wrote:

On Jan 4, 2005, at 7:38 PM, Jim Lovell wrote:

There shouldn't be any differences between libcups.a and libcups.dylib. You must be building the static library yourself -- are you comparing libraries built from the same source?

What printer are you connecting to? There's an open bug about a printer returning partial results due to packet fragmentation -- might this be what you're seeing? Unfortunately we haven't been able to reproduce it as of yet. Seeing a packet trace might help...

Jim

On Jan 3, 2005, at 3:34 PM, Alan Somers wrote:

<x-tad-bigger>I have a Cocoa app (not document-based) where I'm attempting to obtain a list of the jobs (either completed or not-completed) from an IPP printer queue using the CUPS library routines and display it in a window.

When I link against libcups.dylib, I can get the local server jobs with no problems but the remote server job requests either fail with an IPP_SERVICE_UNAVAILABLE error code or I get an incomplete list. The really weird thing is that if I link against libcups.a, everything works flawlessly.

To set up the library I'm linking against, I'm adding a reference to the pertinent file to the Frameworks folder in XTools, making sure that it's associated with the target, and then building the project. Is there anything else I need to do for dylibs? Does anybody have any idea what might be different between linking dynamically vs. statically against libcups that might affect network performance?

TIA.

Alan</x-tad-bigger> _______________________________________________

I tried the libcups.dylib in /usr/lib, the 10.3.0 SDK folder, and built from source (the same source I build libcups.a with) , all with the same results. After I succeeded with libcups.a, I went back and tried the libcups.dylib version I built and the problem returned.

Did you install your libcups.2.dylib in /usr/lib? That's where the loader will be looking for it.

If it were packet fragmentation, wouldn't it normally manifest itself regardless of whether the CUPS utility code is running from a static or dynamic library?

Yes, I would think so. This certainly seems odd.

The printers are an HP DeskJet 935C and a LaserJet 5L, both using foomatic and ESP Ghostscript. The drivers I'm using are hpijs and ljet4, respectively. BTW, Mike Sweet was rather surprised by my observations when I posted them over in the cups.org newsgroups.

I just looked at your posts, I'm surprised as well. Have you tried using lpstat, as in "lpstat -h <host> -W completed"?

I don't have any packet traces, unfortunately, and I am almost ashamed to admit that I don't know what tool to use to get one.

It's easy; something like this will do it:

sudo tcpdump -l -x -X -s 2000 -i en0 dst port 631 or src port 631

(you can use 'src host <host>' instead of port numbers as well).

Jim

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Printing mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/printing/email@hidden

This email sent to email@hidden

• Prev by Date: Re: Printing ticket question, plz.
• Next by Date: PPD Product keyword for CUPS raster driver
• Previous by thread: Re: libcups.dylib and network difficulties
• Next by thread: Panther support for CUPS profile attributes?
• Index(es):
  • Date
  • Thread