Building Oolite Windows from source - The Easier Way

[another_commander]

Seeing that, despite the quite comprehensive wiki instructions on how to make an Oolite executable, building from source on Windows is still a quite complicated matter, I have created a package that will hopefully simplify the process a lot and allow even the relatively inexperienced users to have a razor bleeding edge version of the game to play with and test. Please note that bleeding edge versions may cause spontaneous combustion of your computer, so you use them at own risk.

The download link to the Oolite Development Environment - Light Edition is this:
https://drive.google.com/file/d/1u1IvBx ... sp=sharing
The package contains the Objective-C compiler plus Posix environment (MinGW/MSYS), the Git package version 2.16.2 required for checking out and updating the source code and the required gnustep-base 1.20.1 files. No other downloads will be required.

Instructions on how to build an Oolite trunk executable from zero:

Download the environment and unzip it to a folder of your choice. IMPORTANT: The zip file you downloaded must be decompressed maintaining the folders' path structure, check your unzip program's documentation if you are not sure how to do this. Also note that in the unlikely case that your system is using drive letter O:, you will need to edit the files msys_x2/1.0/msys.bat and msys_x2/1.0/etc/fstab and change the references to o: to an unused drive letter. MORE IMPORTANT: Do not install this in a path containing spaces. We have had cases where the environment failed to work when installed in locations such as My Documents, Program Files etc.

Once unzipped, you must run the msys.bat file, found in <RootOfWhereTheEnvironmentWasInstalled>\msys_x2\1.0. You can create a shortcut to desktop for this file if you want. Once run, the environment will start up.

Important note: The latest development environment is by default configured for building the 64-bit version of the game, but it contains all files necessary for building the 32-bit flavor as well. To switch to the 32-bit version of the compiler, you need to navigate to the folder Msys_x2/1.0 and rename the following folders like this:
1) Devlibs -> Devlibs64,
2) Mingw -> Mingw64,
3) Devlibs32 -> Devlibs
4) Mingw32 -> Mingw
Reverse-rename to return to the 64-bit configuration. Never, ever mix 32-bit Devlibs with 64-bit Mingw or vice-versa. Expect build failure if you do so.

The rest of the steps are:

1. Create our working directory:

Code: Select all

mkdir /d/myoolite

to create a folder called myoolite under D:\. This is where we will check out the code, but instead of D: any available drive letter can be used. We will refer to D: here for simplicity.

Code: Select all

cd /d/myoolite

to enter our working directory.

2. Check out the oolite code:

Code: Select all

git clone https://github.com/OoliteProject/oolite.git

This will start copying the source code from the repository to your working dir. When finished, there will be a folder named oolite under the folder you performed the checkout. Next do a

Code: Select all

cd oolite

to enter in the trunk folder, where the actual build will take place. Finally, execute this command to pull in all the binary dependencies needed for the full build (maybe you can take a coffee break here, this takes a while):

Code: Select all

git submodule update --init

3. Build the source:

Code: Select all

make debug=no

That's it! Sit back and relax while it builds. Once done, you will find two new folders under the oolite folder: obj.win.spk and oolite.app. obj.win.spk contains the object files produced by the compiler and you don't need to worry too much about it. And of course you all know what oolite.app is.

4. Profit:
Double click the oolite.exe file that resides in your D:\myoolite\oolite\oolite.app folder. You should see the splash screen followed by the familiar rotating Cobra. Now you can go and improve your Elite rating and give us some feedback from your testing while you're at it.

If at any later time you would like to update to the code that will be current by then, all you need to do is start up MSYS, then

Code: Select all

cd /d/myoolite/oolite
git pull
git submodule update
make debug=no

Good luck.

[Lestradae]

Very much appreciated, again.

Will see if I manage.

Cheers

L

[another_commander]

With at least two users having successfully used the above instructions to build from trunk, I believe this can now be stickied. The older threads that contained obsolete information have had their sticky status removed.

[Lestradae]

I did manage, no problems at all.

[Cmdr James]

As this is likely to be a post lots of people read about trunk building, its worth reminding that the trunk build should not be used for people who just want to play, and should only really be used for testing.

It is expected to contain bugs, some of which might make the game completely unplayable.

Some things might change in ways that dont make sense -- one day you buy a wormhole scanner, next day you can sell it for 10 times as much, or planets and starts might move about from build to build.

Additionally, a few OXPs are configured to only work with some oolite versions, and to use with trunk need at least a change to the requires plist entry, and possibly more. It is also possible that some OXPs will not silently fail, and you might find some missions impossible. This is useful as feedback for the dev team, but might be disappointing for anyone who just wants to have a go at shooting thargoids.

[Solas]

while playing or testing a trunk build you may find bugs in the core game or with OXPs.
these may be looked up or reported at ..

Testing and Bug reports
https://bb.oolite.space/viewforum.php?f=3
Oolite-PC ( may mention Windows specific bugs )
https://bb.oolite.space/viewforum.php?f=8
Expansion Pack ( OXPs )
https://bb.oolite.space/viewforum.php?f=4
Oolite - Bugs ( game core, game core - OXP interaction )
https://developer.berlios.de/bugs/?group_id=3577

[Thargoid]

But if you're reporting OXP bugs, please remember to actually mention you're using the self-build rather than the current beta-release

Whilst such reports are very welcome (at least by me for my OXPs), I have had at least three occasions since I've been doing this of such reports where the use of a home-build version has not (initially) been mentioned, and the error has turned out to be in the build rather than the OXP.

There's little more frustrating than trying to chase down a bug that you can't repeat because you're using a standard beta-release version and your reporter isn't.

[Griff]

It worked for me too, although I got an error about a missing msvcr71.dll file after compiling the source and double clicking the oolite.exe, a quick search of my pc found it living in quite a few program folders so i copied it into the D:\myoolite\trunk\oolite.app folder and oolite.exe started up perfectly!

[Screet]

Thanks for that package!

While the other way with the common gnustep downloads did create problems for me (wrong DLL and such), this works really well!

I miss two hints to this helpful package:
1) how to create an installer
2) that this package requires to be built on a 32bit Windows

With Vista64 the batch file opens one window after another and then, when 129 windows are open, closes all of them together. Nothing else appears to happen.

Thus I just placed that package on XP32, installed the installer-software, did make a fresh build, did create the installer and moved that one to Vista64 - now everything is fine

Screet, who cannot imagine using 1.72.2 except testing purposes anymore

[another_commander]

I miss two hints to this helpful package:
1) how to create an installer
2) that this package requires to be built on a 32bit Windows

Good point on 2). The compiler we are using for Windows is 32-bit only. For 64-bit building there is mingw-w64, but this has not been tested and there are no guarantees whatsoever that it will work.

As for 1), the omission of the installer files is deliberate. The aim of the package is to enable building, not distribution of the trunk code. Experienced users who want to build installers can easily do so, but for normal users this is not recommended. I generally would like to avoid having installers of various test versions floating around and I prefer to worry about installers of actual releases only.

[Frame]

Running vista ultimate following the exact steps.

I get this when trying to build source...

Code: Select all

$ make debug=no
Making all for objc_program oolite...
Compiling file src/Core/legacy_random.c ...
gcc.exe: installation problem, cannot exec `cc1': No such file or directory
make[1]: *** [obj/legacy_random.o] Error 1
make: *** [oolite.all.objc-program.variables] Error 2

every step above have been followed to the letter

EDIT: cc1 is residing in

Code: Select all

d:/msys_x/1.0/mingw/lib/gcc-lib/mingw32/3.2.3/cc1.exe

EDIT1.1
also found it in

Code: Select all

D:\msys_x\1.0\mingw\libexec\gcc\mingw32\3.4.2\cc1.exe

EDIT 2:

Help!!!

EDIT 3:

gcc.exe resides in

Code: Select all

D:\msys_x\mingw\bin\gcc.exe

While you can see where cc1.exe is... so obviously this is a path problem.. but the package is extracted correctly...

[another_commander]

There seem to have been reports of gcc not working correctly under Vista. See this discussion I found at the Code::Blocks forum:
http://forums.codeblocks.org/index.php/ ... 939.0.html

The funny thing is that some of the users who have confirmed that they have successfully built Oolite following the instructions provided, use Vista. I have seen the package working under Vista myself. However, there has been a patch for gcc out, that seems to resolve the MinGW Vista issues. I would recommend that if you choose to give it a go, you install gcc-3.4.5-20060117-3. You will need to unzip the gcc files in the folder where MinGW currently resides.

Before doing anything though, you can launch Msys and type path in the prompt. Look at the list of paths that will be displayed and make sure that /mingw/bin is one of them. You can also try to copy all executables from mingw\libexec\gcc\mingw32\3.4.2 to mingw\bin and see if that helps.

[Frame]

Thanks... before unpacking the new files
path is:

Code: Select all

$ path
sh: path: command not found

unpacking files...

trying a new make debug=no

failure....

Same error as before, now I bet that is because I do not have a path..

I tried

Code: Select all

set path = /d/myoolite

and then typing path, but again path is unknown.

speculation... when i run msys.. the window popping up says

mingw32... should this really be just mingw ?

[another_commander]

Thanks... before unpacking the new files
path is:

Code: Select all

$ path
sh: path: command not found

Sorry, my bad. I was thinking command console. For Msys, type set at the command prompt, then check the PATH variable from the list that will appear. You can also check the installation by typing gcc -v in the prompt. It should respond with something like:

Code: Select all

$ gcc -v
Reading specs from d:/msys_x/1.0/mingw/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)

unpacking files...

trying a new make debug=no

failure....

Same error as before, now I bet that is because I do not have a path..

I tried

Code: Select all

set path = /d/myoolite

and then typing path, but again path is unknown.

speculation... when i run msys.. the window popping up says

mingw32... should this really be just mingw ?

This should not be the cause of the problem. If you check your PATH as stated above, you should be able to confirm that /mingw/bin is included. The path should NOT be set to /d/myoolite. Have you tried copying the executables in /mingw/libexec/gcc/mingw32/3.4.2 to /mingw/bin? Also, the window title appears correctly as mingw32.

[Frame]

I had just set path to something.. To test it... , in mingw32.... I'm well aware what path is in the command line.. just not so when i thought you meant in mwing32 window...

But..

Command line path does not include gcc though.. there are two kinds though

the cmd.exe path (reconstructed each time cmd.exe is called)

and

command.exe path... (dos path)-.--

neither contains the gcc path.

And I have not used brute force and moved the exe files, since this would
be the "incorrect" way of doing it, and I thought when I do things like that, things usually go from bad to worse..

but using brute force... because I like that approach...