[SOLVED] Bus error on Mac OS 10.7

SheeldaSheelda
edited October 2011 in Help request
Hi,

First of all, thanks for making this library which sounds amazing. If I can solve my problem, I'm probably going to use it for a while.
Sadly, I got a bus error when trying to get the pointer returned by orxObject_CreateFromConfig. If I remove the assignment, it works perfectly.

This line causes the fault. 
orxOBJECT* object1 = orxObject_CreateFromConfig("Object1");

I use the precompiled version for Mac (I'm under Mac OS 10.7). As I don't like xcode so much, I'm trying to use the library through a makefile. My .ini configuration file is the same as in the first tutorial. However orxd doesn't help and crashes as well.

Here are my compile lines: 
g++ -W -Wall -g -ggdb -O0 -arch i386 -c src/main.cc -o src/main.o

g++ -W -Wall -g -ggdb -O0 -arch i386 -lorx  -shared src/main.o -o test.so

Do you have any idea to solve my problem ? Maybe some g++ flags I forgot ? (I already tried -D__orxDEBUG__ etc.)

Thanks in advance.

Ps: I cannot provide a valgrind report for now because of compiling issue on Mac OS Lion (crap why did I upgrade ?)

Comments

  • newton64newton64
    edited October 2011
    Hm. I haven't used Orx on a Mac, nor have I ever received a bus error...that's really a new one.

    Your code... 
    orxOBJECT* object1 = orxObject_CreateFromConfig("Object1");
    ...is pretty much the most basic and frequently-used line out there, so something really exceptional must be happening. This is a complete shot in the dark, but can you try replacing "-arch i386" with "-m32"? My reading is that there's a slight semantic difference between the two.

    I don't honestly expect it to make a world of change, but your program/Makefile look really straightforward, so it's worth a shot...?
  • SheeldaSheelda
    edited October 2011
    Thanks for your suggestion! But I just tried, no changes. I don't even know if there's any difference between the two but I'm despairing ;)
    Maybe I should compile the library for my x86_64 architecture. I'll let you know if it's better.
  • newton64newton64
    edited October 2011
    Yeah, I read there was a trivial semantic difference between the two, had no idea whether it was at all significant. Oh well.

    Have you tried running the tutorials? They're on the download page under orx-tutorial-mac1.3rc0.zip, I believe.

    (EDIT: I see you used the .ini file from the tutorial, but do the programs themselves run? Also, do you know if you're running your application as an Orx plugin, or as a stand-alone application?)
  • SheeldaSheelda
    edited October 2011
    Yes, the precompiled tutorial programs run (which is not the case if I compile them by myself). Also I'm compiling my test program as a shared library and I use the same orx binary to launch my plugin as for the tutorials.
  • iarwainiarwain
    edited October 2011
    Hi Sheelda and welcome here!

    Your problem looks a lot the one I had when I decided to switch from gcc 4.4 to gcc 4.5 on linux and mingw. Unfortunately those two versions of gcc don't create objects that are binary compatible.

    My guess is that the same thing is happening here. I'm still on OS X 10.6 which uses the darwin10 gcc 4.2.1. Do you know which version you're using?

    If this turns out to be the problem, there's an actual easy solution albeit a bit tedious. As I presume it won't be easy to use an older version of gcc on 10.7, you'll have to sync orx's SVN (which is the way to go as the latest release is getting pretty old anyway :) ) and recompile orx and all its dependencies.
    Luckily you shouldn't have to make any code change, simply open the project files and recompile them. That should be about 15 mins of work if everything goes well. :)

    There are some dependencies you don't need to care of. Here's the list of the ones you need to recompile:

    - Box2D: the XCode project file is in extern/Box2D_2.1.3/build/Xcode
    - libsndfile: the XCode project file is in extern/libsndfile-1.0.22/build/Xcode
    - SOIL: the XCode project file is in extern/SOIL/build/XCode
    - GLFW: the XCode project file is in extern/glfw-2.7/build/Xcode

    And finally orx itself whose project file is in code/build/mac/xcode and is named orx-embedded (not the regular orx one!).

    There's only one version to compile for all the external dependencies, whereas you'll have to compile all 3 versions of orx.

    Then you should be all set! Let me know if you try it and that was the issue or not. :)

    Sorry for the inconvenience!
  • SheeldaSheelda
    edited October 2011
    Hi, thanks for your help!
    I'm trying to compile the trunk version of orx (with xcode 4), every externals have been recompiled but I get this error when linking the library (orx and orx-embedded produce the same error):
    Undefined symbols for architecture i386:
  "_orxPlugin_JOYSTICK_Init", referenced from:
      __registerFunction_JOYSTICK in orxJoystick.o
  "_orxPlugin_DISPLAY_Init", referenced from:
      __registerFunction_DISPLAY in orxDisplay.o
  "_orxPlugin_SOUNDSYSTEM_Init", referenced from:
      __registerFunction_SOUNDSYSTEM in orxSoundSystem.o
  "_orxPlugin_MOUSE_Init", referenced from:
      __registerFunction_MOUSE in orxMouse.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status

    Everything has been compiled for the i386 architecture so I don't think it's the problem. Ex. for orxJoystick.o, nm effectively says _orxPlugin_JOYSTICK_Init is undefined, and I couldn't find this symbol in any other object file.

    I've looked into the sources but I lost myself into your macros ;)

    EDIT:
    OK, I think I found what's going on. __orxIPHONE__ is defined, comming from TargetConditionals.h (Apple file). I'm looking for a way to change the targeted OS in xcode.

    EDIT:
    I couldn't find how to change the targeted OS so I just replaced the #define __orxIPHONE__ by __orxMAC__ (please don't heart me :laugh:).
    I got a brand new error:
    ld: bad codegen, pointer diff in b2Shape::b2Shape()to global weak symbol vtable for b2Shapefor architecture i386
Command /Developer/usr/bin/llvm-g++-4.2 failed with exit code 1

    I found the solution on this topic, maybe this will help somebody. In the project settings (for every target), set:
    Inline Method Hidden to Yes
    Symbol Hidden by default to No

    And my original problem is resolved too ! Thank you guys :)
    Please let me know if you want me to make a distribution for Mac OS 10.7
  • iarwainiarwain
    edited October 2011
    Excellent, I'm glad you solved that problem! I'm sure this will be very helpful to a lot of people, myself included.

    Btw, I was about to check your issue on my side as I didn't know you solved it on yours and I stumbled upon the SOLVED tag while replying to someone else. The reason for thst is that we don't get email notifications when a post is edited, so don't hesitate to post new replies instead of editing your last message this way people will get notified of your new discoveries. :)

    Defining manually __orxMAC__ is totally fine but I'd still like to fix the platform automated guess so that others won't run into the same problem later on. If you feel like helping me with that, please drop me a line by email or in PM.

    As for the release package for 10.7, that'd be great but I'll contact you again when I'll be making a new release. It might take a while as doing the whole packaging/release takes me about 6 hours as nothing is automated and getting motivated for that is getting harder and harder. ;)
  • iarwainiarwain
    edited October 2011
    Ah, and yes, sorry about the macros, I get lost there myself too but they were written this way to still allow IDEs to find the original symbols for autocompletion purposes (weirdly enough IDEs have hard time finding symbols if they're defined inside a macro ;)) and still keep a minimal performance impact while calling those callbacks (on x86 the extra cost in release is a single mov/j). Add to that the possibility of having those callbacks resolved at runtime (plugins/hotload) or at compile time without having to change any code beside a define and you obtain those horrific macros! ;)
  • SheeldaSheelda
    edited October 2011
    Sorry about the editing thing, I didn't think about the notification emails!

    I'm looking at the platform selection issue, the bad thing is if you create a Mac OS project (a tried with a "console utility"), and include the "TargetConditional" header, TARGET_OS_IPHONE is still defined. So it's probably not just a project setting to change. I'll let you now if I find a way to get out of this (by replying ! ;)).

    About your macros, I'm more impressed than disgusted ! It's very instructive to read this kind of code.
  • SheeldaSheelda
    edited October 2011
    I found the solution on the source code of TargetConditionals.h.

    When you include the header, TARGET_OS_MAC and TARGET_OS_IPHONE are always defined. The only thing that differ is there values (here).

    Here is the fix:
    #ifdef __APPLE__
#include <TargetConditionals.h>

#if TARGET_OS_IPHONE
#define orxIPHONE
#elif TARGET_OS_MAC
#define orxMAC
#endif

#endif /* __APPLE__ */
  • iarwainiarwain
    edited October 2011
    No worries about the edit/notifications, that was more to let you know that if you might have extra long delays in some replies by editing as notifications aren't sent, nothing more. :)

    Thanks for the TARGET_OS_IPHONE info! Apparently what I have written for guessing if we're on iPhone or not has been broken since 10.6 and I didn't even realize! Oops! ^^ I'll update the SVN tonight.
  • joncjonc
    edited November 2011
    Hi, I'm pretty new to orx, but love it so far. Just wanted to say thanks Sheelda and iarwain for this info. This was invaluable in my switch to OS 10.7 & xcode 4.2.
  • iarwainiarwain
    edited November 2011
    Hi jonc and welcome here!

    Glad it helped you. We should probably add a FAQ to orx's wiki and put that info there. I'll try to start a FAQ in a few days but I seriously lack of time lately. :/
Sign In or Register to comment.