Add support for Linux as a platform

[David Williams]

We now have what appears to be a working version of the Cubiquity library for Linux, but there are still some issues with the Unity3D integration. In particular:

• Need to ensure the Linux version uses the right filename by setting the preprocessor directives.
• The native library needs to get copied to the project root (as happens with the Windows version).
• We need to fix the materials as the voxel terrain is currently showing up black.

[David Williams]

@milliams - I've got a VM set up and I'm trying to test the examples I originally sent you. the basic example does work but I'm not seeing the log file being generated. In your case where was it and what was it called?

[Matt Williams]

The Unity log file was put into ~/.config/unity3d/DefaultCompany/Basic/Player.log and the Cubiquity log was just placed next to the executable (technically I guess in the working directory but I ran it from its directory).

[David Williams]

Thanks, I've found it :-)

[David Williams]

Ok, I didn't get it working yet. As in it's not loading the native code library when I place it next to the executable. It could be something I'm doing wrong, or it could be related to the library coming from your machine.

I did make a fix to the search path, and also to make it copy the library to the correct location (as it does for the Windows version) but I didn't test this functionality yet. I suggest that I also attach a simpler shader and then give you another build to test.

[Matt Williams]

I just tried it on my Linux box at work and it fails here too. I'm pretty sure I know why. Try to reproduce these steps and see if you get the same.

1. Go to the directory where the .so file is
2. Type "ldd libCubiquityC.so"
3. It will fail saying that it is not executable. This is the first problem.
4. Type "chmod +x libCubiquityC.so" to fix this
5. Try running "./test.x86" again. It may still fail
6. Run "ldd libCubiquityC.so" again
7. You will see that it can't find the boost libraries since the library I sent you is from earlier in the week before we removed them

Two fixes for this: Install the 32-bit boost_thread and boost_system libs for your machine or wait until I send a new build this evening or tomorrow morning without the boost dependency.

I guess this is a good demonstration of why removing the boost dependency was worth it :)

[Matt Williams]

I've uploaded a new version of the library at https://drive.google.com/file/d/0B2JKumcQLd4LRFNRekJIMFQxSVE/edit?usp=sharing which should have no Boost dependency. You may still have to do the chmod command though.

[David Williams]

Awesome, it works!

The terrain is completely black as it was in you case, but that's fine, I'll take a look at the shader stuff next.

[David Williams]

Good news, I've had some success with the shader and material related issues. I'm now able to build a Linux version of the examples with no special steps required, and they run successfully on Kubuntu 12.04 in VirtualBox. I must say, VirtualBox has been really invaluable for debugging as I can just output from Unity to a shared folder, Alt-Tab into Linux, and test straight away :-)

Anyway, you can download a couple of examples below:

https://drive.google.com/file/d/0B7b4UnjhhIiEVkJGV3hLNnZQQU0/edit?usp=sharing https://drive.google.com/file/d/0B7b4UnjhhIiEQzF4R0RQZUZuRE0/edit?usp=sharing

Let me know if they work for you!

[Matt Williams]

It's works fantastically. I can just unzip the package, click on the binary in the file browser and it runs! I'll try to do a blog post and Unity forum post about it in the next day or two.

I've rebuilt the library in Release mode so that it both runs faster and is a slightly smaller file https://drive.google.com/file/d/0B2JKumcQLd4LUnRTRzI5MDZUVmc/edit?usp=sharing It's about 1.9 MB now, a bunch of which is caused by the static linking. I see your MSVC DLL is only 0.8 MB or so but I guess that it's still dynamically linked.

[David Williams]

Great stuff, thanks for your help on this. I'll leave you to announce the Linux support and you can also post links to the downloads above.

However, we are going to face challenge with keeping all the libraries up-to-date and in sync with each other. For example, when I make changes to the C++ code and rebuild the .dll for Windows I'm probably not going to do it on all platforms, so other platforms will probably break quite often. We should make sure it works for official snapshots/releases though.

The C# code should also be able to check the version of the code it is loading and alert the user if there is a mismatch. Longer term we should perhaps have an automated build process, and perhaps the native code libraries shouldn't be kept in Git. But we can create a separate issue for this as it will affect MacOS too.

[Matt Williams]

I can/will add Cubiquity to the Buildbot continuous integration system so that any changes you make can be immediately rebuilt. I can set it so that once the build is made, it will upload a copy of the library to somewhere or at least make it available at, e.g. milliams.com/cubiquity/builds/linux/libCubiquityC.so or something similar. Assuming I can get cross-compiling working on the build machine, I can do the same for both Windows and OS X.

I agree that maybe the native libraries shouldn't be kept in Git but if they're not then we need a nice simple method of providing Cubiquity for Unity 3D to our users. Again, it should be quite simple to, on the build machine (or even on the server running volumesoffun.com) grab the C4U3D git contents, add the latest libraries and zip it up as a downloadable file. This way we provide a way for people to get the 'git' version of Cubiquity to keep up to date.

[David Williams]

It sounds interesting, but I think it's too soon for continuous integration or automated builds at the moment. There's still too much changing and too much is unclear about the final structure of the project. It would be useful to be able to build the libraries locally though, but we can discuss this in the Cubiquity issue tracker.

I think this particular issue can be closed once you have made the announcement and a a few people have tested the builds.

[David Williams]

I guess you can close this now? We haven't had any complaints, but it might take some time for it too move into the wild anyway as testing on Linux won't be one of the first steps people take. I guess we can open further issues for any specific problems.

[Matt Williams]

Seems to be working for us so far. Future issues can be opened if specific problems arise.