MOAI on Debian

[todd]

Wow - great progress. Thanks for digging in on this.

[ibisum]

Its quite possible to build it in a 32-bit host Linux system. You can do that yourself. But if you are running 64bit Linux, we have discovered that you will have to do a lot of work to get the environment set up to build a 32-bit binary that works. It seems MOAI (and its 3rdparty tree) is not quite ready for 64-bit computing ..

[ibisum]

Just adding an update .. I had to add:

Code: Select all

1.  


2. link_directories (/usr/lib/i386-linux-gnu/ /usr/lib/)


3.  

.. to the top of CMakeLists.txt in order to get this to build under Ubuntu 11.10.

[ibisum]

Okay, one more discovery .. I've built this cleanly on a new Ubuntu 11.10-i386 (32bit) VM, running in Virtualbox on my main Linux machine (Host is running Ubuntu 12.04-amd64).

I have an NVIDIA graphics card in the machine and have configured VirtualBox 3D acceleration so that the guest OS has acceleration. However, I run into problems with an XGetVisualsInfo() bug in VirtualBox, resulting in a segfault whenever I try to run the gluthost-moai binary.

To get around this, I do:

Code: Select all

1.  


2. $ LIBGL_ALWAYS_INDIRECT=1 ~/bin/moai.gluthost ../../config/config.lua main.lua


3.  

.. whenever I want to run a MOAI sample, or my app. This means: no 3D acceleration for the MOAI binary within the VM, but I can live with that .. for now.

In the meantime, I want to figure out how to build Linux native client on my 64-bit Ubuntu host machine, natively (no virtualization) and have it run properly under 32bit libraries .. I will work on this over the weekend, I think its feasible.

[apomk2]

While I didn't get it to build properly, I at least got it to run on a 64bit ubuntu system. It's hardly a permanent solution, but it beats having to run Wine.

I had to manually copy a couple of 32bit libraries, since I couldn't find suitable 32bit packages for them. In case someone's interested, I uploaded them together with a ready built 32bit binary here:
http://dl.dropbox.com/u/1874436/gluthost.tar.gz

First you have to install the bulk of the required 32bit libraries with this:

Code: Select all

1. sudo apt-get install ia32-libs multiarch-support

After that, unpack the "lib32" dir somewhere (e.g. /usr/local/lib32), create a file called "/etc/ld.so.conf.d/local.conf", add the path of your lib32 directory to it and run

Code: Select all

1. sudo ldconfig

That should do the job. You can check if all libraries are in place by running the "ldd" command on the binary. You obviously do this at your own peril.

I didn't really check every possible library in MOAI, but it does run.

I guess one way to get it to run without manually installing those libraries would be to just link them statically. There aren't a lot and they aren't very big, so I guess it could be feasable.

[spacepluk]

Hey guys, I had a mishap with my hard drive and I'm still dealing with it... long story... Anyway, I'm glad it's working for you hopefully I'll back on my feet soon.

Saludos,

[ibisum]

spacepluk: hope you get it sorted!

apomk2: great job mate! Another thing you can do is just put all these files, libs and bins, in their own folder, and then run the gluthost from within that folder - saves having to tweak/config the system with /usr/local/lib32 ..

[framp]

This is awesome!

Hope this time it will get integrated in the official repository together with the other building systems
Thank you a bunch

[spacepluk]

I've finally found the problem on 64bit systems

The culprit was the precompiled bytecode present in src/lua-headers/moai_lua.h. I guess the best solution would be to let lua compile at runtime instead of embedding the non-portable bytecode in the c header. But for now, you can just replace moai_lua.h with the one attached before compiling on 64bit systems.

Saludoss

[ibisum]

Great work spacepluk! I have confirmed that this fix makes 64-bit based builds work just fine, no problems. I can now throw away the 32-bit libs hack and stay on amd64 for future testing ..

EDIT: MOAI-dev's/Zipline-Folks: PLEASE merge this fix for Linux builds into moai-dev as soon as possible!

[thebullno1]

Can we just embed the compatibility moai.lua file as a string? It might take a few extra ms to compile but the compatibility will be much better.

[nemrod]

Thanks for working on this! I'm new to Moai and after reading the basics on the wiki I was a bit disappointed when I discovered there was no Linux support. :/

I'm trying to build it on a 64-bit Arch installation but am running into this error when running make -j4:

Code: Select all

1. [ 53%] [ 54%] Building CXX object src/moaicore/CMakeFiles/moaicore.dir/MOAICpArbiter.cpp.o


2. Building CXX object src/moaicore/CMakeFiles/moaicore.dir/MOAICpBody.cpp.o


3. In file included from /foobar/moai-beta/src/moaicore/MOAITextBox.h:10:0,


4.                  from /foobar/moai-beta/src/moaicore/moaicore.h:120,


5.                  from /foobar/moai-beta/src/moaicore/moaicore.cpp:6:


6. /foobar/moai-beta/src/moaicore/MOAITextStyle.h:59:15: warning: ‘MOAITextDesigner’ is already a friend of ‘MOAITextStyle’ [enabled by default]


7. /foobar/moai-beta/src/moaicore/MOAICpArbiter.cpp: In static member function ‘static int MOAICpArbiter::_getContactDepth(lua_State*)’:


8. /foobar/moai-beta/src/moaicore/MOAICpArbiter.cpp:46:52: error: ‘cpArbiteGetDepth’ was not declared in this scope


9. make[2]: *** [src/moaicore/CMakeFiles/moaicore.dir/MOAICpArbiter.cpp.o] Error 1


10. make[2]: *** Waiting for unfinished jobs....


11. make[1]: *** [src/moaicore/CMakeFiles/moaicore.dir/all] Error 2


12. make: *** [all] Error 2

[ibisum]

Thats some sort of oddball typo. I noticed it once or twice myself - change cpArbiteGetDepth to cpArbiterGetDepth and it will build fine. Dunno why it was missed, seems the sort of thing that would've come up a lot earlier in some other build environments.

Also, be sure you're on the linux-cmake-amd64 branch, by the way ..

[zeldin]

The culprit was the precompiled bytecode present in src/lua-headers/moai_lua.h. I guess the best solution would be to let lua compile at runtime instead of embedding the non-portable bytecode in the c header. But for now, you can just replace moai_lua.h with the one attached before compiling on 64bit systems.

Which tool is used to generate this header file? I have the same problem, but unfortunately I can't use your alternate header file either, because in my case it isn't the number of bits which are mismatching, but the endianness (I'm on a MacMini G4, which is 32 bit but big endian).

Thanks for your work!

[zeldin]

Ah, now I see the header file is just a hexdump of the output from luac. Well, that makes it easy. Header file for PPC32 attached.

I agree that a simple way to fix this for moai.lua is to just compile in the source instead. However, I'm thinking that this might be an issue for game scripts as well. Some game developers may want to ship their scripts as bytecode to make them more difficult to read or modify. But that makes the game unportable. So maybe a custom bytecode exporter/importer which generates portable bytecode files would be a good addition to the MOAI framework? Maybe there already is one out there (with a suitable license) which could be used, that somebody here knows of?

[thebullno1]

IMO, digging into lua bytecode format is not simple. It might change when we upgrade to lua 5.2. A module loader which can load encrypted source code sounds better. Bytecode format after all, is still open. Encryption algorithm and keys are not (not really).

[owennewo]

I was about ready to give up on MOAI until I read this thread. All sorted now
(Ubuntu 12.04 64bit).

Like others I'm using the gluthost from that drop box link as I was getting "wrong ELF" errors without it. Apart from that I didn't need to do much else (no changes to header files, etc).

Anyone got any tips on development process on linux. What IDE/text editor are you guys using? Are you testing from the command line (e.g. ../../bin/gluthost ../config/config.lua ./main.lua) or have you got some other tricks.

[ibisum]

You no longer need to run the pre-built gluthost binary - if you check out the moai-dev repo, and switch to either linux-cmake or linux-cmake-amd64 branches (depending on what you need), you should be able to build the binary yourself, natively. It would be helpful to know if you can - or cannot - do this, since the Linux cmake situation is targeted for inclusion in moai- mainline as soon as possible, and if there are any other issues, we should fix 'em.

I have mostly been developing my MOAI apps on Mac OSX over the last year, but have switched to Linux for 50% of my development time (i.e. the hacking I do on my home machine, which is a fat Linux box) now that we have Linux host building. On both platforms, I have settled on using Sublime Text 2 as my editor/IDE .. it can be set up with tab-completion, has superior project navigation features, and I've made a custom build rule that runs my MOAI project directly from the editor - this is a very, very smooth configuration and I highly recommend it. Of course, if you come from a world where the IDE does everything for you, there will be some things missing, but for the most part you can do quite well with SublimeText2. My build package looks like this:

Code: Select all

1.  


2. aaa-jv:MOAI j$ cat ~/Library/Application\ Support/Sublime\ Text\ 2/Packages/User/Lua_MOAI.sublime-build


3. {


4.         "cmd": ["/Users/j/bin/moai-1.0", "${file}"],


5.         "file_regex": "^(...*?):([0-9]*):?([0-9]*)",


6.         "line_regex": "^(...*?):([0-9]*):?([0-9]*)",


7.         "working_dir": "${file_path}",


8.         "selector": "source.lua"


9. }


10.  

(EDIT: the code tags on this bulletin-board replace [ and ] chars with #091/#093.. dunno whats up with that, but FYI..)

The same package works on Linux (just update the path from /User to /home to point to the right binary) and it works just as smoothly to boot. I don't have a 'config.lua' file - for my projects, all config is onboard in the project sources, so there is no need to load it extra. With this package, I cmd-B (Mac) or ctrl-B (Linux) and my MOAI project just runs. Very comfortable.

[owennewo]

Thanks very much - +1 for putting amd64 in mainline. The anim-basic sample is twirling.

I'm new to git - I did the following:

Code: Select all

1. git clone -b linux-cmake-amd64 git://github.com/spacepluk/moai-beta.git


2. cd moai-beta


3. git checkout linux-cmake-amd64


4.  


5. # Compile:


6. mkdir build


7. cd build


8. cmake ..


9. make -j4

I think the git checkout was probably optional as it said I was already on amd64 branch (because of -b flag in git clone I guess).

For newbies, to run a sample:

Code: Select all

1. cd samples/anim/anim-basic


2.  ../../../build/src/hosts/gluthost ../../config/config.lua main.lua

[spacepluk]

Hi owennewo,
You've just remind me that I wanted to update the first post with the exact steps, but for some reason I can't edit it anymore...