Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Going universal binary goes haywire

1 view
Skip to first unread message

RogueWarrior

unread,
Jul 25, 2006, 6:36:56 PM7/25/06
to
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?

Patrick Machielse

unread,
Jul 25, 2006, 6:59:33 PM7/25/06
to
RogueWarrior <in...@northernlights3d.com> wrote:

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

RogueWarrior

unread,
Jul 25, 2006, 9:46:26 PM7/25/06
to
*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?

Michael Ash

unread,
Jul 25, 2006, 11:04:44 PM7/25/06
to
RogueWarrior <in...@northernlights3d.com> wrote:
>
> 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.

--
Michael Ash
Rogue Amoeba Software

Tom Harrington

unread,
Jul 25, 2006, 11:44:51 PM7/25/06
to
In article <1153878386....@m79g2000cwm.googlegroups.com>,
"RogueWarrior" <in...@northernlights3d.com> wrote:

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.

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

Patrick Machielse

unread,
Jul 26, 2006, 5:26:50 AM7/26/06
to
RogueWarrior <in...@northernlights3d.com> wrote:

> *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.

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

patrick

0 new messages