Re: Serious problem with XCode 2.2 treating unsigned long differently ?!
Re: Serious problem with XCode 2.2 treating unsigned long differently ?!
- Subject: Re: Serious problem with XCode 2.2 treating unsigned long differently ?!
- From: Eric Albert <email@hidden>
- Date: Sun, 13 Nov 2005 11:04:53 -0800
On Nov 13, 2005, at 10:22 AM, Eric Albert wrote:
On Nov 13, 2005, at 2:48 AM, Eyal Redler wrote:
This looks like a very serious issue and I'm wondering whether anyone
has seen this problem and knows how to work around it.
After upgrading to XCode 2.2 and building my application, the
application could no longer un-archive some classes and produced the
following message in the console:
*** file inconsistency: read 'I', expecting 'L'
Looking into it I found out that the @encode directive produces a
different result for "unsigned long" under XCode 2.2 then it did
under XCode 2.1.
Please file a bug report with details of what you're encoding. The
part of the compiler which handles this was rewritten in Xcode 2.2 and
was found to be fully compatible with the previous version in very
extensive testing, but perhaps we missed a case.
Actually, I think I'm slightly off on this one. The part of the
compiler which handles this was rewritten for Xcode 2.1/gcc 4.0, and
was done so in a way that wasn't compatible with gcc 3.3 and earlier
releases. This was fixed for Xcode 2.2/gcc 4.0.1 to be backwards
compatible with gcc 3.3. Unfortunately, you seem to have some classes
which were encoded with gcc 4.0. (If you were building with gcc 3.3 in
Xcode 2.1, this is a different bug.)
I'd suggest unarchiving those classes with gcc 4.0 and re-archiving
them with 4.0.1 or 3.3, if you can do that. If not, you might have to
re-create the archives.
Hoping I have it straight this time,
Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden