$12256 / $11500
Hi all,
Today I cloned the flare-game repository to my Mac running 10.6.8, and I've been running into some issues running the executable I've compiled from the source. When I try and build the executable using Cmake it can't find SDLmain, and I'm not yet familiar enough with Cmake to know how to correct that problem. So instead I cd'ed to the toplevel of the flare-game directory and invoked gcc directly using the command:
g++ -o flare src/*.cpp src/*.c -lSDL -lSDLmain -lSDL_image -lSDL_mixer -lSDL_ttf -framework Cocoa
The executable compiles and links without a problem, but when I launch it, the game immediately crashes with an abort trap error. Here's the stdout log:
>No joysticks were found.
>Using joystick #0.
>Mix_LoadMUS:
>Failed to open pDevice->interface via open.
>flare(4360,0x7fff7005fcc0) malloc: *** error for object 0x100785c30: pointer being freed was not allocated
>*** set a breakpoint in malloc_error_break to debug
>Abort trap
Has anyone else experienced this issue, or is it something at my end?
This website's content is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Could you compile again with the "-g" switch? This will enable debugging symbols in the binary. Then you could start it with a debugger "gdb -ex r ./flare". That will run flare in the debugger and once flare crashes the internal state is preserved. Could you then type "backtrace full" ? This would reveal the whole internal state of flare and would be a great help.
Two random thoughts. Unfortunately I'm not that great at figuring out build environments.
So when I build on OSX I use XCode. To use the Cocoa framework it requires SDLMain.m and SDLMain.h files. Maybe those come with a template in XCode, or I found them in some "setting up an SDL project with XCode" tutorial online. I wonder if your error has to do with the Cocoa binding. But I figure that would happen at the linking level if anything?
Also, you may want to try using the SDL.framework version 1.2.13 instead of the latest 1.2.15. I use 1.2.13. Several things changed in 1.2.15 including major changes for OSX 10.7 and removing support for PPC. Possibly the error has to do with that.
Hm, interesting... I tried compiling with the -g switch enabled (and again the executable compiled and linked without any visible problem or error, even when running gcc with the -v option) and ran the executable through gdb, but when I tried generating a backtrace I got "No stack." I tried recompiling/reinstalling the most recent SDL and all the satellite libraries from source, but no change. I should note here that I've successfully compiled/linked/run various SDL projects before using gcc directly on this same system, but I've never encountered this problem before, so I'm rather mystified.
Next I tried building with XCode as Clint suggested, and that build runs perfectly, even with the 1.2.15 SDL.framework. So I guess I'll be using XCode after all, although I was hoping to avoid that since the apparent lack of git SCM support in XCode 3.2.6 means I'll have to manually add new files from my local copy of the repository to the XCode project.
I'm still going to play around and see if I can't find and fix whatever silent problem is causing the abort trap when using gcc directly, but for now XCode works fine.
Especially let us know if it turns out to be something in the Flare engine code -- like us doing something incorrect with some SDL init or default value.
I have (I believe) the same problem with cmake + make on OSX 10.8.3. I can configure with cmake, and make will build all of the objects but fail at linking:
Linking CXX executable flare
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
(maybe you meant: _SDL_main)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [flare] Error 1
make[1]: *** [CMakeFiles/flare.dir/all] Error 2
make: *** [all] Error 2
@Soren: I've played around a bit with CMake, and I've come up with a non-ideal but working solution to the problem. In line 182 of CMakeLists.txt:
Target_Link_Libraries (flare ${CMAKE_LD_FLAGS} ${SDL_LIBRARY} ${SDLMIXER_LIBRARY} ${SDLIMAGE_LIBRARY} ${SDLTTF_LIBRARY} ${SDLMAIN_LIBRARY})
replace ${SDLMAIN_LIBRARY} with SDLmain:
Target_Link_Libraries (flare ${CMAKE_LD_FLAGS} ${SDL_LIBRARY} ${SDLMIXER_LIBRARY} ${SDLIMAGE_LIBRARY} ${SDLTTF_LIBRARY} SDLmain)
The problem seems to be that CMake, for whatever reason, fails to automatically locate SDLmain on OS X (see line 177-180 in CMakeLists.txt), so you have to link it explicitly in the list of target link libraries. Like I said above, I'm not familiar enough with CMake to know why or how CMake fails to find SDLmain, but the solution above works correctly for me.
Hmm, interesting. Did you see any cmake bugs while looking into this? It seems like the original should work, but I don't know much about cmake.
By the way, I should mention that my first issue was slightly different, and was due to me derping and using the runtime SDL binaries. Downloading the SDL 1.2.15 source and compiling that got me to the exact same problem artisticdude had (I'm on OS X 10.8.3). Changing ${SDLMAIN_LIBRARY} to SDLmain resolved the problem, allowing me to compile FLARE.
I commented on the SDL 1.2.15 issues bug - I notice all of the ones Clint mentioned, however 1.2.15 does actually work with retina displays (although slow as hell on anything other than 640x480).
As far as I can see, the SDLMAIN_LIBRARY variable is never set prior to the code at lines 178-180, so cmake always ends up assigning an empty string to the variable, no matter what.
The only way I can think of to get around this without having to go in and manually edit the CMakeLists.txt file every time would be to filter for what OS we're installing on, i.e. something like:
If (APPLE)
Set (SDLMAIN_LIBRARY "SDLmain")
Endif (APPLE)
This should work if the core SDL library has already been successfully located, as SDLmain should be in the same location as the other SDL files. Frankly though, I'm rather surprised that cmake doesn't automatically include SDLmain if appropriate when locating the core SDL library.
The cmake problem exists on AmigaOS 4 in the same, or similar form. I use the interactive mode of cmake to get around it.