Going universal binary goes haywire

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

RogueWarrior - 25 Jul 2006 23:36 GMT

Okay, I'm baffled by this one. I've got a project that compiles,
links, and runs just fine built in XCode and running on a Powerbook G4.
I make a new target for i386, compile it and link it. As soon as I
launch it or try to debug it I get the following message "Sorry, a
system error occurred at startup. This application will not be able to
run." That's it...no debugger stuff, nada. Any idea what might be
wrong?

Reply to this Message

Patrick Machielse - 25 Jul 2006 23:59 GMT

> Okay, I'm baffled by this one. I've got a project that compiles,
> links, and runs just fine built in XCode and running on a Powerbook G4.
[quoted text clipped - 3 lines]
> run." That's it...no debugger stuff, nada. Any idea what might be
> wrong?

Probably something you forgot to include in the new target, or a wrong
setting. Why do you create a new target at all, why not simply 'check
the checkbox'?

patrick

Reply to this Message

RogueWarrior - 26 Jul 2006 02:46 GMT

*sigh* and so the nightmare of updating old code begins.

Turns out the app was dying because of a failed call to Gestalt. Why
did it fail? Because it was trying to get the Gestalt of selector
'vsys'. Doesn't exist. Actually it's 'sysv'. So I've run aground on
the first of what's likely to be hundreds if not thousands of endian
problems.

Gah! Apple handled Rosetta so nicely, why couldn't they make endian
issues transparent too?

Reply to this Message

Michael Ash - 26 Jul 2006 04:04 GMT

> Gah! Apple handled Rosetta so nicely, why couldn't they make endian
> issues transparent too?

Because this would require either continuing on with a big-endian
processor or requiring everyone to use a high-level language which doesn't
expose the endianness of the CPU to the end user. Merits of the CPU switch
are debatable, but requiring you to switch to a completely different
language should obviously be even worse than making you clean up your
code. Endian-unclean isn't something you can just fix in any C-derived
language.

Signature

Michael Ash
Rogue Amoeba Software

Reply to this Message

Tom Harrington - 26 Jul 2006 04:44 GMT

> *sigh* and so the nightmare of updating old code begins.
>
[quoted text clipped - 6 lines]
> Gah! Apple handled Rosetta so nicely, why couldn't they make endian
> issues transparent too?

I'm not sure why you're having that problem. I've got code that calls
Gestalt() on both PPC and Intel and I haven't run into this. I haven't
tried 'sysv', but 'mclk' and 'ramm' seem to work without any trouble.

Signature

Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 2.0: Delocalize, Repair Permissions, lots more.
See http://www.atomicbird.com/

Reply to this Message

Patrick Machielse - 26 Jul 2006 10:26 GMT

> *sigh* and so the nightmare of updating old code begins.
>
[quoted text clipped - 3 lines]
> the first of what's likely to be hundreds if not thousands of endian
> problems.

So you're not checking the Gestalt() return value, and using invalid
data. Your bad, don't blame Apple. Code defensively...

patrick

Reply to this Message

Mac Forum / Programming / Mac Programming / July 2006

Going universal binary goes haywire