Arx Libertatis Bug Tracker
star_faded.png
Please log in to bookmark issues
bug_report_small.png
CLOSED  Bug report #225  -  make fails on Mac OS X at 97%
Posted Apr 19, 2012 - updated Jan 03, 2017   Shortlink: http://arx.vg/225
action_vote_minus_faded.png
0
Votes
 action_vote_plus_faded.png
icon_info.png This issue has been closed with status "Fixed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Bug report
  • Status
     
    		 Fixed
  • Assigned to
    Not assigned to anyone
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
    Guest user
  • Owned by
    Not owned by anyone
  • Estimated time
    Not estimated
  • Category
    Not determined
  • Resolution
    RESOLVED
  • Priority
    Not determined
  • Reproducability
    Not determined
  • Severity
    Not determined
  • Targetted for
    icon_milestones.png Not determined
  • OS
    icon_customdatatype.png Not determined
  • Architecture
    icon_customdatatype.png Not determined
  • Fixed in
    icon_customdatatype.png Not determined
Issue description
I have been following the instructions on the Wiki, even compiled cmake from source, tried to build from makefiles (can't find my way in XCode) http://wiki.arx-libertatis.org/Downloading_and_Compiling_under_Mac_OS_X

After running make it stops at 97%, here is what it sais: 
 [ 96%] Building CXX object CMakeFiles/arx.dir/src/window/Window.cpp.o
 [ 97%] Building CXX object CMakeFiles/arx.dir/src/window/SDLWindow.cpp.o
 [ 97%] Building CXX object CMakeFiles/arx.dir/Version.cpp.o
 Linking CXX executable arx
 Undefined symbols for architecture x86_64:
   "_main", referenced from:
       start in crt1.10.6.o
      (maybe you meant: _mainApp, _main_conversation , _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]: *** [arx] Error 1
 make[1]: *** [CMakeFiles/arx.dir/all] Error 2
 make: *** [all] Error 2
 XYZ-imac:build XYZ$


(replaced my real name with XYZ) I got the dependencies from MacPorts as suggested, running an an early 2009 24" iMac using Mac OS X 10.7.3 Lion. I could try XCode if I knew what to press, but I doubt there would be any difference.
Steps to reproduce this issue
Nothing entered.

#2
icon_reply.pngReply
Comment posted by
Guest user
May 16, 16:51
I tried running everything through XCode, here are the issues I get: http://pastebin.com/J8jaJcT9 6 warnings and 81 errors

I hope this log is more useful to you guys.
#3
icon_reply.pngReply
Comment posted by
Adrian
Nov 02, 16:00
I can confirm this problem, both with gcc compiler and clang compiler on Mac OSX 10.7.5.
#4
icon_reply.pngReply
Comment posted by
Daniel Scharrer
Nov 02, 16:17
Hi, did you try in Xcode or directly from the command-line with make?

Either way, try changing lines 138 to 143 in CMakeLists.txt from 
  1. if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
  3. 	# Required to avoid linking with SDLmain except for OS X where it is necessary
  4. 	# due to the need to have NSApplication correctly setup by SDLmain.
  5. 	set(SDL_BUILDING_LIBRARY 1)
 to just 
  1. set(SDL_BUILDING_LIBRARY 1)

and in src/core/Core.cpp remove lines 159 to 161: 
  1. #if defined(__APPLE__) && defined(__MACH__)
  2.     #include <SDL.h>
  3. #endif

Thanks.
#5
icon_reply.pngReply
Comment posted by
Guest user
icon_reply.pngNov 02, 16:40, in reply to comment #4
directly from command line. Applying your changes causes the following cmake error: 

  1. CMake Error at CMakeLists.txt:1208 (message):
  2.   No input backend available - need either SDL or DirectInput 8
  3.  
  4.  
  5. CMake Error at CMakeLists.txt:1211 (message):
  6.   No windowing backend available - need either SDL or Windows
#6
icon_reply.pngReply
Comment posted by
Daniel Scharrer
Nov 02, 17:32
What's the full output?

Did you also remove the find_package(SDL 1.2 EXACT)? That needs to stay!
#7
icon_reply.pngReply
Comment posted by
Adrian
icon_reply.pngNov 04, 12:54, in reply to comment #6
Since commit 6ec3ff7f56504e379f19d3a5e5f81b253f72e065 i get the "ld: unknown option: --as-needed" error, which i cant fix like suggested in the wiki anymore, because the content of the CMakeList.txt has changed. So i cant check the actual HEAD right now. Any idea how to get around? smileys/4.png

Daniel Scharrer wrote:
What's the full output?

Did you also remove the find_package(SDL 1.2 EXACT)? That needs to stay!


#8
icon_reply.pngReply
Comment posted by
Daniel Scharrer
icon_reply.pngNov 04, 13:28, in reply to comment #7
With the current master there is now a `SET_OPTIMIZATION_FLAGS` CMake option to disable that flag: 
  1. cmake .. -DSET_OPTIMIZATION_FLAGS=0

It *should* automatically be disabled if the linker doesn't support it, but for some reason that doesn't work on OS X - my only explanation is that CMake ends up using two different linkers for the test and the actual build smileys/4.png

Anyway, I just disabled the check completely now for OS X so you shouldn't even need to set SET_OPTIMIZATION_FLAGS anymore.
#10
icon_reply.pngReply
Comment posted by
Adrian
icon_reply.pngNov 04, 17:53, in reply to comment #8
This worked. The compiling was successfull, neverless there is a crash right after startup: 

  1. mbair_adrian:build adrian$ ./arx
  2. [I] Core:598  Starting Arx Libertatis 1.0.3-git + 4cff2
  3. [I] Application:177  changing filenames to lowercase...
  4. [I] SDLWindow:71  Using SDL 1.2.15
  5. Nov  4 18:38:48 Adrians-MacBook-Air.local arx[98896] <Error>: kCGErrorInvalidConnection: CGSNewWindowWithOpaqueShape: Invalid connection
  6. Nov  4 18:38:48 Adrians-MacBook-Air.local arx[98896] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
  7. 2012-11-04 18:38:48.891 arx[98896:107] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1002) creating CGSWindow'
  8. *** First throw call stack:
  9. (
  10. 	0   CoreFoundation                      0x00007fff8f50ef56 __exceptionPreprocess + 198
  11. 	1   libobjc.A.dylib                     0x00007fff96e75d5e objc_exception_throw + 43
  12. 	2   CoreFoundation                      0x00007fff8f50ed8a +[NSException raise:format:arguments:] + 106
  13. 	3   CoreFoundation                      0x00007fff8f50ed14 +[NSException raise:format:] + 116
  14. 	4   AppKit                              0x00007fff8c49b57b _NXCreateWindowWithStyleMask + 313
  15. 	5   AppKit                              0x00007fff8c49b3a1 _NSCreateWindow + 60
  16. 	6   AppKit                              0x00007fff8c49a7a6 -[NSWindow _commonAwake] + 2100
  17. 	7   AppKit                              0x00007fff8c499360 -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 1871
  18. 	8   AppKit                              0x00007fff8c4983af -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1502
  19. 	9   AppKit                              0x00007fff8c497d7f -[NSWindow initWithContentRect:styleMask:backing:defer:] + 47
  20. 	10  SDL                                 0x0000000106eef5cc SDL_SoftStretch + 24672
  21. 	11  SDL                                 0x0000000106eed72d SDL_SoftStretch + 16833
  22. 	12  SDL                                 0x0000000106ee2da1 SDL_SetVideoMode + 892
  23. 	13  arx                                 0x0000000106664272 _ZN9SDLWindow4initERKSs7Vector2IiEbj + 598
  24. 	14  arx                                 0x0000000106475685 _ZN7ArxGame10initWindowEP12RenderWindow + 989
  25. 	15  arx                                 0x00000001064757ce _ZN7ArxGame10InitWindowEv + 152
  26. 	16  arx                                 0x000000010646b8cc _ZN11Application10InitializeEv + 156
  27. 	17  arx                                 0x0000000106475961 _ZN7ArxGame10InitializeEv + 23
  28. 	18  arx                                 0x000000010648e223 _Z7runGamev + 579
  29. 	19  arx                                 0x000000010648ec1d main + 125
  30. 	20  arx                                 0x000000010643aa24 start + 52
  31. )
  32. terminate called throwing an exceptionAbort trap: 6

Re, A

Daniel Scharrer wrote:
With the current master there is now a `SET_OPTIMIZATION_FLAGS` CMake
option to disable that flag:
cmake .. -DSET_OPTIMIZATION_FLAGS=0

It *should* automatically be disabled if the linker doesn't support it, but
for some reason that doesn't work on OS X - my only explanation is that
CMake ends up using two different linkers for the test and the actual build


Anyway, I just disabled the check completely now for OS X so you shouldn't
even need to set SET_OPTIMIZATION_FLAGS anymore.


#11
icon_reply.pngReply
Comment posted by
Daniel Scharrer
icon_reply.pngNov 04, 19:27, in reply to comment #10
Hm, I feared something like that would happen as the SDL-provided main() is supposed handle OS X-specific initialization.

It seems that we need to manually link against the SDLmain library and can't on CMake to find that for us. I've updated the code in the repository to do that. Can you try again, this time without making any changes in CMakeLists.txt or Core.cpp. Thanks.
#12
icon_reply.pngReply
Comment posted by
Guest user
icon_reply.pngNov 05, 09:35, in reply to comment #11
i've reverted my changes, deleted the cmake files and run a new "cmake .." in build/, but make spits out: 

  1. Adrians-MacBook-Air:build adrian$ make
  2. [  2%] Built target _arx_arxsavetool_common
  3. [ 14%] Built target common
  4. Linking CXX executable arx
  5. ld: library not found for -lSDLmain
  6. collect2: ld returned 1 exit status
  7. make[2]: *** [arx] Error 1
  8. make[1]: *** [CMakeFiles/arx.dir/all] Error 2
  9. make: *** [all] Error 2

Daniel Scharrer wrote:
Hm, I feared something like that would happen as the SDL-provided main() is
supposed handle OS X-specific initialization.

It seems that we need to manually link against the SDLmain library and
can't on CMake to find that for us. I've updated the code in the repository
to do that. Can you try again, this time without making any changes in
CMakeLists.txt or Core.cpp. Thanks.


#13
icon_reply.pngReply
Comment posted by
Daniel Scharrer
icon_reply.pngNov 05, 10:45, in reply to comment #12
Hmpf, at least it seems we aren't the only ones having this problem. Strange though, because from the looks of it my version of CMake (2.8.9) should have found libSDLmain.a by itself if it were at that location. What CMake version do you have?

Do you know where you have installed SDL? Is there a libSDLmain.a?

What is the output of 
  1. sdl-config --libs

Also, what is the output of this when run in the arx build directory after cmake: 
  1. grep SDL CMakeCache.txt

Thanks for sticking around.

This might also be relevant: http://forums.codeblocks.org/index.php?topic=9691.0
#14
icon_reply.pngReply
Comment posted by
Guest user
Sep 22, 14:40
I have some good progress to report (I originally posted this issue): The problem lies in missing SDLMain.h and SDLMain.m

Those files are needed for SDL on OS X in order to "glue" things together (.m is the extension used by Objective-C source files). You can get them from SDL's website when you download the framework. Unlike Windows and Linux there are no separate runtime and development libraries, there is just one framework and it comes with those two extra files. I followed the instructions in the Wiki to create an XCode project, then I dumped the two files into it in Sources/arx and clicked "Build" with ALL_BUILD as my target. Everything compiled fine with some warnings and the game is playable.

The conclusion is that either these files need to be included in the project or the project migrated to SDL 2 where there is no need for this "glue" code anymore. I was unable to compile from CMake because I didn't know how to add the two files to the project, I'm just randomly poking at things hoping it works. Note that SDL 2 for OS X now has separate runtima and development libraries as well, just like on Windows and Linux.

Once compilation works out of the box the next question is how to create a Mac-like package. Currently I just get the raw binaries, but on OS X applications come as one .app file that contains everything. You then drag & drop it into your applications folder and just double-click it, no isntalltion needed.
#15
icon_reply.pngReply
Comment posted by
SebastienLussier
icon_reply.pngSep 23, 05:00, in reply to comment #14
Thanks Guest (HiPish?)!

We have no one really looking at the Mac port, so your help is definitely welcome. One contributor made some small changes for Mac a while ago... See https://github.com/arx/ArxLibertatis/commit/585d934137e2e28dce5bf976ae15189f941a9f55

That SDL.h include is not there anymore in the latest code, so I guess someone cleaned that up. SDL1 is doing nasty stuff (#define main SDL_main)... And I guess it might explain why it worked before and is broken now? Anyway, your solution might be cleaner, but I haven't done much research. We need to make sure that it works with CMake.

So this is just to say that you are more than welcome to help us with the Mac support smileys/2.png

Thanks!

Guest user wrote:
I have some good progress to report (I originally posted this issue): The
problem lies in missing SDLMain.h and SDLMain.m

Those files are needed for SDL on OS X in order to "glue" things together
(.m is the extension used by Objective-C source files). You can get them
from SDL's website when you download the framework. Unlike Windows and
Linux there are no separate runtime and development libraries, there is
just one framework and it comes with those two extra files. I followed the
instructions in the Wiki to create an XCode project, then I dumped the two
files into it in Sources/arx and clicked "Build" with ALL_BUILD as my
target. Everything compiled fine with some warnings and the game is
playable.

The conclusion is that either these files need to be included in the
project or the project migrated to SDL 2 where there is no need for this
"glue" code anymore. I was unable to compile from CMake because I didn't
know how to add the two files to the project, I'm just randomly poking at
things hoping it works. Note that SDL 2 for OS X now has separate runtima
and development libraries as well, just like on Windows and Linux.

Once compilation works out of the box the next question is how to create a
Mac-like package. Currently I just get the raw binaries, but on OS X
applications come as one .app file that contains everything. You then drag
& drop it into your applications folder and just double-click it, no
isntalltion needed.


#16
icon_reply.pngReply
Comment posted by
HiPhish
icon_reply.pngSep 23, 07:10, in reply to comment #15
Yes, it was me, I now finally bothered to sign up here smileys/2.png I'll be glad if I can help with Mac support, so if you guys work out a solution let me know and I will try and compile it. Once I figure out how to create app bundles we can upload a proper Mac version and i can throw the old Wine wrapper away.
#17
icon_reply.pngReply
Comment posted by
Daniel Scharrer
Sep 23, 16:16
That SDL.h include is not there anymore in the latest code, so I guess someone cleaned that up.


It's now in Startup.cpp as main was moved there.

SDL1 is doing nasty stuff (#define main SDL_main)... And I guess it might explain why it worked before and is broken now?


The worst part is that the way to link SDLmain differs between the various SDL distributions (offical framework, macports, ...) - see http://arx.vg/46d05d / Bug report 517 - problem finding libs to link wicth installed through MacPorts (Building on Mac OS X) for the last related change. It looks like FindSDL.cmake isn't able to figure it out for everyone, so we would have to bundle our own copy of SDLmain.m/.h and compile&link that - and I'd rather not bundle code from external projects if it can be avoided.

SDL 2 really is the only proper solution here, as that does away with this whole SDLmain mess. It's on my TODO list, but I'm currently on vacation, so won't get to it for a few weeks at least. If anyone else is keen to port AL to SDL 2: I think we should keep the SDL 1 backend for now to support non-bleeding-edge Linux distros, but can add a second SDL 2 backend (it's not a lot of code anyway). Once we move to require (parts of) C++11, we can also reevaluate the need for SDL 1 support.
#18
icon_reply.pngReply
Comment posted by
HiPhish
icon_reply.pngSep 23, 16:32, in reply to comment #17
Daniel Scharrer wrote:
...


What should I do then? Should I upload my naked binaries unofficially where I had the Wine wrapper previously for the time being and wait until AL transitions to SDL 2? At that point AL should then be able to compile out of the box.
#19
icon_reply.pngReply
Comment posted by
Daniel Scharrer
Sep 23, 16:40
Yeah, sure - any binary is probably better than no binary. Or keep working on an 'official' app bundle by manually adding SDLmain to Xcode (it only needs to compile for you for that).

At that point AL should then be able to compile out of the box.


"Should", yeah. But it turned out to be more complicated with SDL 1, let's hope that there aren't any more surprises with SDL 2...
#20
icon_reply.pngReply
Comment posted by
HiPhish
icon_reply.pngSep 23, 17:06, in reply to comment #19
I already had to add SDLMain.h/.m to XCode to get it to compile to naked binaries, so this approach should be filed under "unofficial" build, like my Wine wrapper, even when I produce a proper app bundle. For now I'm at least glad I can play at all, for some reason the later versions of AL didn't work in Wine anymore. I don't know if the problem was on Wine's or AL's end, but that's off topic anyway.
#21
icon_reply.pngReply
Comment posted by
HiPhish
Sep 25, 21:37
I have more progress to report, I was told how to package binaries properly. Turns out it's very simple: add ".app" to the main folder and then inside that folder provide the proper folder structure and an info.plist file so the OS knows what to do with the package. This process can be automated using CMake: http://www.cmake.org/Wiki/CMake:Bundles_And_Frameworks#Bundle_only I don't know how to use CMake, but I saw that inside your CMake script you have a flag for OS X, so it should be possible to add this. Here is how OpenMW does things, maye it can be of use: https://github.com/zinnschlag/openmw/blob/master/CMakeLists.txt#L268 https://github.com/zinnschlag/openmw/blob/master/CMakeLists.txt#L301

For now I have replaced my old Wine wrapper with the package, containing a basic info.plist with the current version, icon and category (Game - Role Playing). A plist is essentially an XML file containing information for the OS about how to treat the bundle. If you want I can write a more detailed one for future releases. Also, we need a proper size icon (512 x 512), I was only able to find a small one and upscaled it. It doesn't look well, but it gets the job done. The icon itself looks nice, so if someone has still the vectors for it they can just export is at the right size.

Until the SDL 2 transition gets finished I'll try keeping up with official releases. If someone can get the makefile things done that would be great, otherwise I'll keep packaging manually. Someone should also change the "Wineskin wrapper" in the downloads section to "unofficial build" in order to not confuse people.
#22
icon_reply.pngReply
Comment posted by
Daniel Scharrer
Jan 03, 10:08
SDLmain is no longer needed with SDL 2 and arx should build fine.

Please open separate bug reports for any remaining issues.

The issue was updated with the following change(s):
  • This issue has been closed
  • The status has been updated, from New to Fixed.
  • The resolution has been updated, from Not determined to RESOLVED.
  • This issue's progression has been updated to 100 percent completed.