What is the easiest way to install on a Mac?

[OmniStudent]

Excellent, thanks Amaz! I've added Belugion (=OmniStudent). If anyone else would like to get added, please come forward.

Thankyou, wrote a small wiki page to test my permissions.

[OmniStudent]

So it looks like leveldb and freetype work without problems; gettext might work if include and library paths were changed because Homebrew does not install this in /usr/local, so as not to clash with OS X's built-in BSD gettext.

LuaJIT on the other hand is a complete disappointment on OS X and leads to an executable that immediately crashes.

P.S. I've uploaded a new Minetest git build with LevelDB and Freetype enabled. And I've added a script to mtmake-osx for massaging dynamic libraries with dylibbundler.

Great work, I've tried the binary and everything seems fine. Pity about LuaJIT http://luajit.org/index.html, but from my first glance it looks like this hasn't been updated for osx in a while (only 10.3 and 10.4 are mentioned in the install instructions). On the other hand, I can install it through brew, so I guess its up to date.

[Morn76]

Thankyou, wrote a small wiki page to test my permissions.

To upload a new ZIP, go to releases and edit the latest release. Update the text and click the close button next to the existing ZIP to delete it. Then drag a new ZIP on the rectangle below that. (Somehow this dragging only seems to work in Chrome. Or maybe my adblockers in Firefox were the problem.) You will see a tiny upload progress bar. Then just click "Save" or whatever it says at the bottom.

It should also be possible to keep the code in the repo updated by pulling from minetest/minetest to you local repo and then pushing to mdoege/minetest. But I haven't tried that yet. At the moment I am more interested in mtmake-osx and improved builds. :-)

Great work, I've tried the binary and everything seems fine. Pity about LuaJIT http://luajit.org/index.html, but from my first glance it looks like this hasn't been updated for osx in a while (only 10.3 and 10.4 are mentioned in the install instructions). On the other hand, I can install it through brew, so I guess its up to date.

Well, maybe the LuaJIT issue can be fixed. But the crash dump and error message were unhelpful and did not make the problem look like an obvious mistake. I also wonder if there are data execution prevention mechanisms in OS X as it was reported for Windows with LuaJIT. Who knows, this might just be a security feature in OS X that was tripped.

But I think for the moment LevelDB is a more important feature anyway. Subjectively, a LevelDB map seems to have less random Mesecons and door lag than SQLite. It just feels smoother overall to me, less stuttery. So I would always convert a laggy map to LevelDB first and see if that improves anything.

[Morn76]

P.S. OmniStudent, please make sure your copy of mtname-osx is updated before you create a new ZIP for GitHub though, because builds are supposed to include freetype and leveldb now.

[OmniStudent]

P.S. OmniStudent, please make sure your copy of mtname-osx is updated before you create a new ZIP for GitHub though, because builds are supposed to include freetype and leveldb now.

Thankyou, but it will probably be a while until I contribute a zip. Right now I'm just having too much fun trying to build a player "AI".

[Morn76]

Thankyou, but it will probably be a while until I contribute a zip. Right now I'm just having too much fun trying to build a player "AI".

No problem, I just wanted to point that out. Maybe you should clone mtmake-osx instead of downloading the ZIP, so you can simply do "git pull" before you build. Nested git repositories seem to work, you just have to be more mindful of which directory you are in before you 'git pull'.

I've added gettext support to the builds, which required a patch for FindGettextLib.cmake. So now LuaJIT is the only holdout.

[Morn76]

Now LuaJIT works too!http://luajit.org/install.html has this little nugget of information:

If you're building a 64 bit application on OSX which links directly or indirectly against LuaJIT, you need to link your main executable with these flags:
-pagezero_size 10000 -image_base 100000000

Figuring out how to make CMake use those flags was the bigger problem, actually. :-)

Nice, so now the Mac build (as soon as I upgrade the actual binary) will have the same options as our other builds.

[OmniStudent]

You're amazingly fast Morn76! How much coding experience do you have?

[Morn76]

You're amazingly fast Morn76! How much coding experience do you have?

I think this is more about Googling skills than amazing coding ability. :-) The fixes are all out there somewhere. That said, I've not really had significant prior experience with cmake or Xcode and I've never really used C++ for anything in practice, so I'm a bit proud of myself here that it all works so far.

But perhaps the most important new development for the Minetest Mac port is actually Homebrew. Unlike Fink and Macports, Homebrew does not seem to suck as much and all our dependencies are supported and up to date. That makes everything so much easier.

I suppose now I could best the other builds by including hiredis too? Does anyone actually use redis or is this another of those contests to see who has the biggest, largest, mightiest... ah, umm, database backend? :-)

[Morn76]

Alright, redis is now included too. I've played a bit with the redis backend with Minetest on Linux first. It was surprisingly painless to use I must say. I was expecting having to set master passwords and the like as with mysqld.

Now the only remaining wart I can see with the OS X build is that I can only run it when compiled as Debug, which is also the xcodebuild default. When I compile as Release ("xcodebuild ARCHS="x86_64" -configuration Release"), MT crashes with a segmentation fault:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

Process:         minetest [41454]
Path:            /Volumes/VOLUME//Users/*/Downloads/*/minetest.app/Contents/MacOS/../Resources/bin/minetest
Identifier:      celeron55.minetest
Version:         20140425.3a6d6e4 (20140425.3a6d6e4)
Code Type:       X86-64 (Native)
Parent Process:  launchd [138]
Responsible:     minetest [41454]
User ID:         501

Date/Time:       2014-04-26 22:35:40.437 +0200
OS Version:      Mac OS X 10.9.2 (13C1021)
Report Version:  11

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libunwind.dylib                  0x00007fff854a4a81 libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncodingFrameless(unsigned int, unsigned long long, libunwind::LocalAddressSpace&, libunwind::Registers_x86_64&, bool) + 565
1   libunwind.dylib                  0x00007fff854a233b libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncoding(unsigned int, unsigned long long, libunwind::LocalAddressSpace&, libunwind::Registers_x86_64&) + 41
2   libunwind.dylib                  0x00007fff854a22e1 libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::step() + 113
3   libunwind.dylib                  0x00007fff854a19f2 _Unwind_RaiseException + 166
4   libc++abi.dylib                  0x00007fff8eaacc4a __cxa_throw + 107
5   minetest                         0x00000001052edea1 con::Connection::Receive(unsigned short&, SharedBuffer<unsigned char>&) + 1745

Hmm. Apparently the main difference between Release and Debug (apart from debug symbols being included of course) seems to be the level of optimization. Maybe Debug has extra protection against bad memory access too?

In terms of performance the difference between Release and Debug should not be that big (this isn't the 1990s anymore where debug builds were much slower), so it boils down to a size difference: 8.8 MB vs 10.3 MB

It would be nice to solve this, but now we are really getting into proper coding/debugging territory. So I think we might have to stick with Debug for a while…

P.S. When I revert to the vanilla config (no LuaJIT/Freetype/Gettext/LevelDB/Redis) and build as Release, I can at least get to the main menu. The game still crashes when I start a world, but in the full build, it crashes immediately on launch. So the crashes I observed seem to be at least somewhat related to optional components like LuaJIT.

The map loading crash looks like this:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

Process:         minetest [45565]
Path:            /Volumes/VOLUME//Users/*/Downloads/*/minetest.app/Contents/MacOS/../Resources/bin/minetest
Identifier:      celeron55.minetest
Version:         20140425.3a6d6e4 (20140425.3a6d6e4)
Code Type:       X86-64 (Native)
Parent Process:  launchd [138]
Responsible:     minetest [45565]
User ID:         501

Date/Time:       2014-04-26 23:56:11.174 +0200
OS Version:      Mac OS X 10.9.2 (13C1021)
Report Version:  11

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libunwind.dylib                  0x00007fff854a4a81 libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncodingFrameless(unsigned int, unsigned long long, libunwind::LocalAddressSpace&, libunwind::Registers_x86_64&, bool) + 565
1   libunwind.dylib                  0x00007fff854a233b libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncoding(unsigned int, unsigned long long, libunwind::LocalAddressSpace&, libunwind::Registers_x86_64&) + 41
2   libunwind.dylib                  0x00007fff854a22e1 libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::step() + 113
3   libunwind.dylib                  0x00007fff854a19f2 _Unwind_RaiseException + 166
4   libc++abi.dylib                  0x00007fff8eaacc4a __cxa_throw + 107
5   minetest                         0x000000010c2374f7 ServerMap::ServerMap(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, IGameDef*, EmergeManager*) + 2343

[OmniStudent]

You're amazingly fast Morn76! How much coding experience do you have?

I think this is more about Googling skills than amazing coding ability. :-) The fixes are all out there somewhere. That said, I've not really had significant prior experience with cmake or Xcode and I've never really used C++ for anything in practice, so I'm a bit proud of myself here that it all works so far.

But perhaps the most important new development for the Minetest Mac port is actually Homebrew. Unlike Fink and Macports, Homebrew does not seem to suck as much and all our dependencies are supported and up to date. That makes everything so much easier.

I suppose now I could best the other builds by including hiredis too? Does anyone actually use redis or is this another of those contests to see who has the biggest, largest, mightiest... ah, umm, database backend? :-)

That's pretty much the same way as I go about it, and I've gotten better at it during the year or two I've been into Minetest. But its not what you CAN do that counts, its what you DO, and your productivity is extremely high. Also, I want to thank you for doing this important "core" work instead of, like me, drifting off to unorganized personal fancies. So you have every right to be proud of yourself :-)

I switched to homebrew recently on a whim, nice to hear it works better.

Think I read somewhere about a significant performance improvement with redis.

[OmniStudent]

Maybe you should clone mtmake-osx instead of downloading the ZIP, so you can simply do "git pull" before you build. Nested git repositories seem to work, you just have to be more mindful of which directory you are in before you 'git pull'.

Have to learn more git, as of now I'm only able to clone your git to my hard drive and use it as a fresh copy for code experiments.

I'm starting to suspect that you are, well,... smarter than I am. Don't deny it :-)

[Morn76]

I switched to homebrew recently on a whim, nice to hear it works better.

Well with Fink I remember I was able to install Open Source software (in the 10.3/10.4 days), but I could never get anything upgraded for some reason. Maybe 10.4 was no longer supported.

Macports has all kinds of software, just never what you need. Or it's broken.

So I would say Homebrew looks much better. It's a bit like Arch Linux: You can get many packages a binaries ("bottles"), but there are also these Ruby recipes to compile and install from source. So I think thanks to this dual nature it's pretty future-proof.

Think I read somewhere about a significant performance improvement with redis.

And at least on Linux, it is always said that separate processes are better for performance than threading (it's the reverse on Windows). So using a separate database server might be a good idea. Plus Redis seems to be widely supported by hosting companies, so I guess that is why people want it.

I'm starting to suspect that you are, well,... smarter than I am. Don't deny it :-)

Well, getting ancient, uncommented, hard-to-understand source code to run is certainly something I have experience with. Although in science it's usually Fortran-77 or worse, Fortran-iV. :-)

As for the Debug/Release issue, maybe I can try to build a Release with less overzealous optimization settings. Perhaps xcodebuild does something slightly dangerous like "-O3" here? I've tried to do a Release build of the November 2013 version which required only a minimum of changes to compile on OS X, but it also crashed before the map got loaded in-game. So at least my messing with semaphores does not seem to be the root cause here.

P.S. I've tested optimization settings with "Release". Without optimization (0) MT works, 1/2/3/s cause crashes.

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

xcodebuild ARCHS="x86_64" GCC_OPTIMIZATION_LEVEL="0"  -configuration Release

Strangely enough however, this unoptimized Release build is quite a bit larger than a Debug build (also unoptimized): 14.8 MB vs 10.3 MB! So now I'm trying to figure out if there is a noticeable performance benefit at least.

P.P.S. When I stand in the same place in Stampyworld, I easily get 50 to 60 fps with Debug, while Release seems to stay between 40 and 50 fps and struggles to go above 50. So it really looks like Debug is a bit faster.

[OmniStudent]

Well, getting ancient, uncommented, hard-to-understand source code to run is certainly something I have experience with. Although in science it's usually Fortran-77 or worse, Fortran-iV. :-)

What science? I'm guessing physics or chemistry based on those languages. I'm doing bioinformatic stuff where I seldom have to do more than write python scripts.

Strangely enough however, this unoptimized Release build is quite a bit larger than a Debug build (also unoptimized): 14.8 MB vs 10.3 MB! So now I'm trying to figure out if there is a noticeable performance benefit at least.

Lots of inline function in the Release version?

P.P.S. When I stand in the same place in Stampyworld, I easily get 50 to 60 fps with Debug, while Release seems to stay between 40 and 50 fps and struggles to go above 50. So it really looks like Debug is a bit faster.

Strange, but I guess that ties in with the optimization problems you mentioned.

[Morn76]

What science? I'm guessing physics or chemistry based on those languages. I'm doing bioinformatic stuff where I seldom have to do more than write python scripts.

Atmospheric science, which is somewhere between physics and chemistry, mostly chemistry for me right now. But of course it's mainly the big models that are in Fortran, for analysis code everyone is generally very fond of Python or IDL.

Changing your own code is easy, but diving into a big model changing something there is more challenging. Then again newer models use more advanced Fortran with proper modules, object orientation, and so on. It's mainly older Fortran spaghetti code where you realize Fortran is an even older language than Basic and it shows. Just a definite punched card feel to it, with a minimum of lines, reusing memory (like unions in C), and few to no comments. :-)

Strange, but I guess that ties in with the optimization problems you mentioned.

I will play around a little with compilation options and settings, i.e. try to make building more like it is on Linux. Use make instead of xcodebuild, perhaps use g++ (unless g++/gcc are just links to clang on OS X; I haven't checked that yet. I suppose they might be.) My first attempt with make was a failure though. I think it compiled some of the static libraries for 32 bit and then could not link them to the rest. :-(

Why does OS X have to troll me so much whenever I build something? It always almost works. :-)

[raffahacks]

The easiest way is to install wine (=a windows software interpreter for mac) and run the windiws version. Everything works (including online features) and the framerate is very good.
Hope to be useful, if you want i can publsh a standalone mac binary built with wine and windows binaries.
Bye

[OmniStudent]

The easiest way is to install wine (=a windows software interpreter for mac) and run the windiws version. Everything works (including online features) and the framerate is very good.
Hope to be useful, if you want i can publsh a standalone mac binary built with wine and windows binaries.
Bye

Would be nice, even if for no other reason than performance comparison. Morn76's version will probably be both faster and less troublesome, it can be downloaded as a regular app. But the more the merrier! And you still need wine if you want to write "merde" on a french keyboard :-)

[Morn76]

Would be nice, even if for no other reason than performance comparison. Morn76's version will probably be both faster and less troublesome, it can be downloaded as a regular app. But the more the merrier! And you still need wine if you want to write "merde" on a french keyboard :-)

I suppose I could try to create a build without SSE extensions or whatever instructions are causing my i5 build not to work on a Core 2 Duo. It would be nice if Xcode had a simple option to make a binary that is compatible with all CPUs supported by Mavericks. But apparently there isn't. So I've been looking at Homebrew's Mac hardware detection module ( https://github.com/Homebrew/homebrew/bl ... ardware.rb ) to get a feel for the various compiler flags: e.g. "-march=core2" looks promising.

The performance difference between a native build vs Wine is probably not that big actually. Wine 1.6 has supposedly improved OpenGL performance a lot. So the main advantage of a native build is probably just the smaller download size. Wine is 500 MB or so.

Personally I'm too scared to install Wine. Because then Windows malware and trojans from spam email attachments might actually run under Linux or OS X too. That is not the kind of compatibility I want.

[Morn76]

I've made some progress: Now I can build a 64 bit binary with make instead of xcodebuild. It turns out the crashiness of optimized Release builds was due to these compiler flags: "-ffast-math -Wall -fomit-frame-pointer -pipe -funroll-loops". Remove them and the problems are gone. I just have to test them individually to figure out which flag is the problematic one.

CMakeLists also had this previously overlooked gem:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

   if(APPLE)
      set(CMAKE_OSX_ARCHITECTURES i386 CACHE STRING "do not build for 64-bit" FORCE)
      set(ARCH i386)
   endif()

No wonder the static libraries were always stubbornly built for i386! Obviously someone once considered 64 bit builds for OS X a bad idea and put this here. I have no idea why.

[hoodedice]

AFAIK, the devs here hate 64 bit Minetest, saying that it does not have enough performance benefits to be viable

[OmniStudent]

I've made some progress: Now I can build a 64 bit binary with make instead of xcodebuild. It turns out the crashiness of optimized Release builds was due to these compiler flags: "-ffast-math -Wall -fomit-frame-pointer -pipe -funroll-loops". Remove them and the problems are gone. I just have to test them individually to figure out which flag is the problematic one.

CMakeLists also had this previously overlooked gem:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

   if(APPLE)
      set(CMAKE_OSX_ARCHITECTURES i386 CACHE STRING "do not build for 64-bit" FORCE)
      set(ARCH i386)
   endif()

No wonder the static libraries were always stubbornly built for i386! Obviously someone once considered 64 bit builds for OS X a bad idea and put this here. I have no idea why.

That's great progress! I thought it was neigh impossible to build graphical mac apps without Xcode. Do you need to include Cocoa, Carbon in some special way when doing this? Have you checked that the app takes input from the keyboard?

[Morn76]

@hoodedice: Maybe, but all dynamic libraries installed by Homebrew are 64 bit, so I don't think they would link with the main program if it were 32 bit. This is not about a performance benefit, but about OS X defaulting to 64 bit in general.

@OmniStudent: It still uses the frameworks from the XCode bundle, so everything works. But the benefit with make vs xcodebuild is that make does not override cmake's settings with its own defaults like XCode/xcodebuild does. So the compiler flags as defined by cmake are actually used. Whereas before it was unclear which settings XCode's magic, high-performance debug builds were built with. It's better not to have two programs fighting over defaults. :-)

[raffahacks]

The easiest way is to install wine (=a windows software interpreter for mac) and run the windiws version. Everything works (including online features) and the framerate is very good.
Hope to be useful, if you want i can publsh a standalone mac binary built with wine and windows binaries.
Bye

Would be nice, even if for no other reason than performance comparison. Morn76's version will probably be both faster and less troublesome, it can be downloaded as a regular app. But the more the merrier! And you still need wine if you want to write "merde" on a french keyboard :-)

Thank you for your answer. Minetest runs smoothly on Wine, on my 2gb core 2 duo mac @ 35 fps and with online multiplayer. On my mac Morn76 version doesn't work, will try to recompile his. The problem is it's very heavy (200mb for the standalone mac binary)

[Morn76]

On my mac Morn76 version doesn't work, will try to recompile his.

I'm working on a make-based "make_mac.sh" that I will push to mdoege/mtmake-osx soon I hope. Without interference from xcodebuild, it should be easier to stick e.g. "-march=core2" in the CMakeLists somewhere and get a build that works on your machine. (Because with Xcode I could not figure out how to do this.)

If we could get a single build that works on older machines too without a big performance drop on the latest models that would be ideal I think. Minetest probably does not get much speed advantage from those vector extensions anyway because so much work is dony by external libraries compiled by Homebrew. And I think Homebrew's precompiled Mavericks binaries like Irrlicht are compatible with Core 2 too.

[sfan5]

AFAIK, the devs here hate 64 bit Minetest, saying that it does not have enough performance benefits to be viable

You got many things wrong, almost any Mac OS X code in the CMake files was not tested.

[raffahacks]

Thank you Morn76, hope to see your binary soon!
Your work is very good :)

[OmniStudent]

I'm working on a make-based "make_mac.sh" that I will push to mdoege/mtmake-osx soon I hope. Without interference from xcodebuild, it should be easier to stick e.g. "-march=core2" in the CMakeLists somewhere and get a build that works on your machine. (Because with Xcode I could not figure out how to do this.)

Oh YES, of course! If "make" works its possible to make a script :) Perhaps the linux one-line-installs have good clues on this.

About a year ago, I compiled a 32-bit version of Minetest, with 32-bit Irrlicht. Run on an average 2010 macbook pro this gave me framerates of ~30, with annoying drops below 15.

[Morn76]

I've uploaded a new binary and my build script repo has also been updated. (This new build is not Core 2-compatible yet though.) As it turns out, "-fomit-frame-pointer" was causing the crashes. Now that it's gone, Release builds can be optimized with -O3 as under Linux and are smaller and faster than before. Now I regularly get 60 fps in Stampyworld and Karsthafen, at least when looking at buildings close by.

@raffahacks: It would be helpful if you could determine which compiler flags I need to make a binary on my machine that is compatible with yours. "-march core2" I guess, but maybe more? https://github.com/Homebrew/homebrew/bl ... ardware.rb has quite a few tests for a lot of things like SSE. Homebrew apparently builds its bottles (=binaries) for Core 2 compatibility ( https://github.com/Homebrew/homebrew/wiki/Bottles ), so if we could find out which compiler settings they use we could simply compile MT with the same settings and everything should work. I'm not sure how to get Homebrew's settings however. Maybe you could compile something on your machine with Homebrew and send the compiler command line with all the flags.

@OmniStudent: Like I said earlier, I think you should use LevelDB for your maps. Slowdowns due to database loading will still happen but not be as bad as with SQLite. I do my Stampy map in LevelDB and only migrate a copy to SQLite for distribution. I hope with the release 0.4.10, all binaries will have LevelDB support on all platform so I can upload the LevelDB version directly.

[Morn76]

Thank you Morn76, hope to see your binary soon!

Raffahacks, I've uploaded a new ZIP file to https://github.com/mdoege/minetest/rele ... g/20140429 (core2test_...). It's compiled with -DCMAKE_CXX_FLAGS="-mmacosx-version-min=10.9 -march=core2 -msse4.1", based on Homebrew's settings. Please tell me if it works on your machine or not.

[OmniStudent]

@OmniStudent: Like I said earlier, I think you should use LevelDB for your maps. Slowdowns due to database loading will still happen but not be as bad as with SQLite. I do my Stampy map in LevelDB and only migrate a copy to SQLite for distribution. I hope with the release 0.4.10, all binaries will have LevelDB support on all platform so I can upload the LevelDB version directly.

I don't know how to "use" levelDB, I thought Minetest used this by default (if build with it). But I'm not sad :) Now mac users can get into Minetest easily, and neophyte programmers like me can use "make" to build it.