Re: Error: dsNoPk5 (22): package 5 not present
Re: Error: dsNoPk5 (22): package 5 not present
- Subject: Re: Error: dsNoPk5 (22): package 5 not present
- From: Sailor Quasar <email@hidden>
- Date: Thu, 9 Oct 2003 10:27:49 -0400
On Thursday, October 9, 2003, at 09:08 AM, Chris Ridd wrote:
I just released a new version of MacSword (www.macsword.com) an open
source bible study and research tool. I had tested it quite thoroughly
however a small handful of users (mostly using 10.2.8) have been
getting an error something like "ERROR!
execle(/Applications/MacSword/MacSword.app/Contents/MacOS/MacSword)
returned, err=22" which apparently is a "dsNoPk5 (22): package 5 not
present". Could someone please enlighten me as to what this error is
and how I could go about fixing it.
In this case, err refers to the Unix errno value. If you are
distributing
your program in a Stuffit archive, it is quite likely that the users
getting
this error are using Stuffit 8.0, which doesn't mark programs as
executable,
which causes this error. Stuffit 7 and 8.0.1 don't have this problem.
Alternatively, think different (sorry!) and distribute your program
inside a
compressed disk image (dmg).
I find it interesting that those of us searching desperately for
answers on error codes are still coming up with ancient and venerable
definitions that were laid to rest with System 6... dsNoPk5 meant that
the 'PACK' resource with ID 5 in the old System file could not be
found, and it was a fatal system error (anyone still remember the bomb
dialog?). For the curious, 'PACK' 5 was the Transcendental Functions
Package (from the old IM: OSUtils; "Provides routines that support
trigonometric, logarithmic, exponential, and financial functions, and a
random number generator.").
I find it mildly disturbing that someone running MacOS X searching for
an answer about an error code would end up with something THIS legacy.
The error code is still defined as this in Carbon/MacErrors.h (and
there is still an error code dsNoPk1, which is even worse because there
never WAS a 'PACK' 1 resource to my knowledge). When was the last time
you saw a system error 9 that was dsLineAErr (illegal A-Trap) instead
of EBADF (invalid file descriptor)? Last I checked, we didn't access
system routines through A-traps anymore. And I should also like to
point out that this is a Cocoa list... why are Cocoa developers looking
for error codes and coming up with Carbon legacy stuff? I think it's
really about time the framework version of Carbon removed these
definitions and instead referenced /usr/include/errno.h for those who
still end up there.
For the easily amused, take a glance near the bottom of
Carbon/MacErrors.h sometime. Some of the error descriptions in there
are rather amusing, especially if you look at them from a more modern
point of view.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.