Compiling for powerpc (Darwin 9/OS X 10.5)
#1
I'm trying to compile MCServer for my powerpc G4 mac mini. As you probably know, the java implementation in powerpc is awful and this server would be excellent for powerpc platforms.

However, compiling goes reasonably smooth in Xcode using GCC 4.0, but when I try to run it, I get a "bus error" which is aparently, the Mac OS equivalent of a segfault (or so I am told, could be wrong)

I'm a C Novice and don't know what to do next, is it possible this information may help somehow?

http://stackoverflow.com/questions/20694...-bus-error

Thanks,

-RTB
Reply
Thanks given by:
#2
Apparently when a program compiles and runs fine under Linux it is not guaranteed to compile and/or run on a Mac.

There have been a lot of changes since the last time a stable release was made for Mac so it's most likely broken Sad

XCode is an IDE right? Could you try attaching the debugger to MCServer to see where it crashes/segfaults/bus errors?
Reply
Thanks given by:
#3
(03-09-2012, 11:12 AM)FakeTruth Wrote: Apparently when a program compiles and runs fine under Linux it is not guaranteed to compile and/or run on a Mac.

There have been a lot of changes since the last time a stable release was made for Mac so it's most likely broken Sad

XCode is an IDE right? Could you try attaching the debugger to MCServer to see where it crashes/segfaults/bus errors?

Yeah, XCode is basically an IDE for Apple's really screwy GNU toolchain.

I'll try that and see what happens.
Reply
Thanks given by:
#4
(03-09-2012, 11:12 AM)FakeTruth Wrote: Apparently when a program compiles and runs fine under Linux it is not guaranteed to compile and/or run on a Mac.

There have been a lot of changes since the last time a stable release was made for Mac so it's most likely broken Sad

XCode is an IDE right? Could you try attaching the debugger to MCServer to see where it crashes/segfaults/bus errors?

I don't understand really what it's telling me, but it looks bad. Anyway here's a screenshot from the debugger

http://glacialsoftware.com/DEBUG.png
Reply
Thanks given by:
#5
I'd say "bus error" is not really a segfault, rather it means that access was attempted on unaligned memory. This could prove problematic, since MCS does no alignment attempts whatsoever, and I don't think there are any active developers with access to PowerPC or SPARC hardware to test it out.
Reply
Thanks given by:
#6
(03-09-2012, 05:53 PM)xoft Wrote: I'd say "bus error" is not really a segfault, rather it means that access was attempted on unaligned memory. This could prove problematic, since MCS does no alignment attempts whatsoever, and I don't think there are any active developers with access to PowerPC or SPARC hardware to test it out.

I'd be happy to provide help. I've got the hardware... and I'm also not completely programing oblivious. I'm more of a Java and C# programmer but I learn quick if you need help.
Reply
Thanks given by:
#7
I'm trying to put in some GCC attributes to force alignment. I'd need you to test it out after I get it working and commit it.

Also it'd be extremely useful if you could provide some variable values when the server crashes, such as the m_CriticalSectionPtr in the screenshot you provided.
Please try it now with rev 387.
Reply
Thanks given by:
#8
(03-09-2012, 07:20 PM)xoft Wrote: I'm trying to put in some GCC attributes to force alignment. I'd need you to test it out after I get it working and commit it.

Also it'd be extremely useful if you could provide some variable values when the server crashes, such as the m_CriticalSectionPtr in the screenshot you provided.
Please try it now with rev 387.

Actually, I got it to run on r386 just fine using a very weird trick that by all means, should appear to do nothing.

I commented out the following lines in cEvent.cpp

28: LOGWARN("WARNING cEvent: Could not create unnamed semaphore, fallback to named.");

31: ASSERT(!"This codepath is really weird, if it is ever used, please check that everything works.");

Aren't those just making log entries? It runs perfect with them commented out.

Anyhow, I made some other really small changes to get it to compile (mostly in cMonster.cpp). If you want I can upload them. I'll try build 387 for fun as well.
Same issue with 387, and same fix.
Reply
Thanks given by:
#9
Is your code taking that path in cEvent? If you uncomment those lines and put a breakpoint in them, does it hit the breakpoint? If so, that's the reason for your failure - the ASSERT() macro force-terminates the program.

If there's anything that doesn't compile, please send us the patch that makes it work for you. You can either attach a patch file to the forum post, or send me an email at <my-nick> @ <my-nick>.cz
Reply
Thanks given by:
#10
There seems to be some random crashes with the webserver still, I think I might be able to fix them. Stand by and I'll post diffs sometime soon.
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)