Building Oolite Windows from source - The Easier Way

[Redspear]

Neither 'git pull' nor 'git clone' able to connect. i.e. failure to start download process despite internet connection.
I'm unaware of any permission changes or blocks on my system but can't rule that out yet.

Next chance I get, I'll write down the error message.
Thanks.

[Redspear]

sh: git: command not found

It's been a while since I played with the source code so I'm hoping that I'm just making some silly error

[Commander_X]

You might have to check 2 files:

• msys.bat (the one that starts it all), and check the "start of Oolite specific changes" section
  <unzipped_folder>/Msys_x2/1.0/etc/fstab, and make sure your /git resource is properly mapped.

E.g. if your subst o:[...] lines in the first file are not commented, then the second file should have also not commented the o:/git /git line. Otherwise you might need to manually taylor them to suit your environment.

[Thargoid]

Check that the O: drive is correctly mapped. It should point at the root folder of your Oolite install. If you've had that drive letter mapped somewhere else prior to starting up the build environment, then the build command won't work as it won't be able to find Git.

This one I fell over myself, I mapped O: to something else on boot-up then building stopped working. The build script needs O: mapped to the Oolite root folder.

[Redspear]

Thanks gents, I'll look into that

[another_commander]

We have some news about the Windows build which should be of interest to those compiling from source.

In Oolite 1.80 and 1.82, a library called libgcc_s_sjlj[_64]-1.dll has been part of the binary distribution. This library contains low level functions called directly by the compiler in specific cases of complicated operations (if you are _really_ interested to know exactly what it does, check https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html ). However, this was used only by a small part of the binary distribution. For reasons of uniformity and for reducing the dependencies needed for distrbution, this library has now been dropped. Our trusty nightly buildbot has been updated to take note of the change and new nightlies are generated without that library. If you are not building the game from source on Windows, you can stop reading here.

If you are building the game from source on Windows, be advised that you will have to also update your development environment to account for the change. You can do this in two ways:
- Download the new development environment from https://drive.google.com/file/d/0BwG6R5 ... sp=sharing,
or (if you would prefer to avoid a 333MB download)
- In your development environment's folder, go to Msys_x2\1.0\Devlibs\gnustep1201\System\Library\Makefiles\, open the file common.make in a text editor, go to line 602 and change it from

Code: Select all

INTERNAL_LDFLAGS += -shared-libgcc -fexceptions

to

Code: Select all

INTERNAL_LDFLAGS += -fexceptions

. Do the same with the file common.make found in Msys_x2\1.0\Devlibs32\gnustep1201\System\Library\Makefiles\ to apply the change also for the 32-bit build case.

After the change has been applied, make sure to pull the latest revision from github before you attempt a new build of the game.

Note that if you do not update your environment, the builds you generate will continue to depend on libgcc_s_sjlj[_64]-1.dll and this may lead to unpredictable behaviour, especially in the case an exception is thrown during runtime.

The first post on this thread has been updated with the latest development environment's version download link.

[Redspear]

Check that the O: drive is correctly mapped. It should point at the root folder of your Oolite install. If you've had that drive letter mapped somewhere else prior to starting up the build environment, then the build command won't work as it won't be able to find Git.

Finally had another crack at this (acknowledging the changes of the previos post) and still can't get it to work...

Found the relevant lines in mysys.bat and fstab but only succeeded in creating new combinations that don't work.
Tried changing the drive letter (in case 'unmapping' o was the problem) but no joy.
Trying to set it up in c:/myoolite (or /c/myoolite).

Any help gratefully received.
Thanks.

[another_commander]

Given that the only change in the environment between v1.80 (which I believe had been working for you) and now is the one related to the static libgcc, maybe you can try to backtrack and try to remember if you had changed anything at any point on your system (new user accounts, settings etc). There must have been a reason it was working before and not now. Maybe you can try re-installing the environment from the zip file from scratch in a different folder?

Another check you can do is fire up msys.bat and check on Windows Explorer whether a new drive (the subst one) has been created or not. It should normally have the letter O: assigned. Make sure that the drive is physically listed there and, if so, let us know what its contents are.

Can you also post the contents of the fstab file? Maybe the git folders are not mapped correctly.

[Commander_X]

Also a result of the

Code: Select all

mount

and

Code: Select all

set | grep GNU

commands executed in the command prompt after you run msys.bat, could also be useful -- it would give a better visibility of what/if anything went wrong in your environment, at least from a resource mapping perspective.

[Redspear]

Thanks for the help folks...

fstab:

Code: Select all

#C:\DevelopmentEnvironment\SourceControl\git			/git
#C:\DevelopmentEnvironment\gcc\nsis					/nsis

#Uncomment below for full portability - requires also uncomment in msys.bat
#o:/msys_x/1.0/mingw /mingw 
o:/git /git
#o:/gstep1201 /OOgstep
#o:/nsis /nsis

Also a result of the

Code: Select all

mount

and

Code: Select all

set | grep GNU

commands executed in the command prompt after you run msys.bat, could also be useful --

Besides the quote a few posts up, the only other report I'm getting is

GNUstep system root is /mingw../devlibs/gnustep1201/System

upon starting msys.bat

[another_commander]

Can you please post the output of the following from the msys shell (the $ is the prompt, type all that follows it):

Code: Select all

$ echo $PATH

You should be seeing paths pointing to the compiler folders at the start of the output and the git executable path /git/bin at the very end of it. If you don't see /git/bin mentioned in the path, then check the file <DevEnvRoot>\Msys_x2\1.0\msys.bat and ensure that the lines at the beginning reading

Code: Select all

subst o: /D
subst o: ..\..

are NOT commented out.

When you type the mount command in the msys shell, does it not give you any output at all?

The GNUstep root message indicates that at least GNUstep is set correctly. Is gcc recognized as installed too? Can you please post the output of

Code: Select all

$ gcc -v

If all fails, you may try to re-install the latest version of the DevEnv in a completely different folder and try again. I just tested it on my system, in a completely fresh directory (checking of course that no pre-existing path environment variables interfere) and it works as expected.

[Redspear]

When you type the mount command in the msys shell, does it not give you any output at all?

Apologies, I managed to misunderstand Commander_X's post (...somehow )

Output of mount:

Code: Select all

C:\OoliteDevelopmentEnvironment_LE_20160113\OoliteDevelopmentEnvironment_LE_20160113\Msys_x2\1.0 on / type user (binmode,noumount)
C:\OoliteDevelopmentEnvironment_LE_20160113\OoliteDevelopmentEnvironment_LE_20160113\Msys_x2\1.0 on /usr type user (binmode,noumount)
C:\Users\Me\AppData\Local\Temp on /tmp type user (binmode,noumount)
o:\git on /git type user (binmode)
c: on /c type user (binmode,noumount)
d: on /d type user (binmode,noumount)
e: on /e type user (binmode,noumount)
f: on /f type user (binmode,noumount)
g: on /g type user (binmode,noumount)
h: on /h type user (binmode,noumount)
i: on /i type user (binmode,noumount)
j: on /j type user (binmode,noumount)

The only other one yielding anything is gcc -v:

Code: Select all

Using built-in specs.
COLLECT_GCC =C:\OoliteDevelopmentEnvironment_LE_20160113\OoliteDevelopmentEnvironment_LE_20160113\Msys_x2\1.0\mingw\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/oolitedevelopmentenvironment_le_20160113/oolitedevelopmentenvironment_le_20160113/msys_x2/1.0/mingw/bin/../libexec/gcc/mingw32/4.7.1/lto-wrapper.exe
Target: mingw32
Configured with: ../../src/gcc-4.7.1/configure --build=mingw32 --enable-languages+c,c++,ada,fortran,objc,obj-c++ --enable-threads=win32 --enable-libgomp --enable-lto --enable-fully-dynamic-string --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gnu-ld --disable-nls --disable-win32-registry --disable-symvers --disable-build-poststage1-with-cxx --disable-werror --prefix=/mingw32tdm --with-local-prefix=/mingw32tdm --enable-cxx-flags='-fno-function-sections -fno-data-sections' --with-pkgversion=tdm-1 --enable-sjlj-exceptions --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: win32
gcc version 4.7.1 (tdm-1)

subst o: /D
subst o: ..\..

are indeed uncommented...

[Commander_X]

I'm not using the subst o: approach, but from the looks of your mount table (i.e. the output of the mount command), your mapping from the subst command doesn't work -- that is, I'd expect to see a

Code: Select all

o: on /o type user (binmode,noumount)

at the end of your list (not sure, though, to what extent msys plays nice with this regard).
A quick fix would be to comment out (by placing a "rem " in front of them) the two "subst"lines in msys.bat. comment out the o:/git mapping in your fstab file and put a C:/OoliteDevelopmentEnvironment_LE_20160113/OoliteDevelopmentEnvironment_LE_20160113/git /git after it.
Thus, in your msys.bat you'd have this layout for Oolite specific changes:

Code: Select all

rem - start of Oolite specific changes

:: These changes are to enable the Oolite dev environment to live everywhere.
:: We assume that drive O: does not map to a physical device, and remap it
:: relative to the present location every time this batch file is run. 
:: drive O: is also referred to in ../etc/fstab
:: If you use a different drive letter for Oolite's environment,
:: make sure to change it in fstab too! 

rem subst o: /D
rem subst o: ..\..

rem - end of Oolite specific changes

and your fstab would look like this:

Code: Select all

#C:\DevelopmentEnvironment\SourceControl\git         /git
#C:\DevelopmentEnvironment\gcc\nsis               /nsis

#Uncomment below for full portability - requires also uncomment in msys.bat
#o:/msys_x/1.0/mingw /mingw
#o:/git /git
C:/OoliteDevelopmentEnvironment_LE_20160113/OoliteDevelopmentEnvironment_LE_20160113/git /git
#o:/gstep1201 /OOgstep
#o:/nsis /nsis

One last advice: don't make the edits in these files with Notepad. Notepad++ or Wordpad are better suited for this. If by any chance you mixed up the end of line characters in these files, you may be already suffering the results.

[another_commander]

I'm not using the subst o: approach [snip]

Not using the subst approach either here (I do exactly what you describe actually), but I do distribute the environment like this in order to be sure that it will work on any folder it gets installed in. I know this is the case, at least on the various systems I tried this on. I really don't know why it doesn't map the O: drive for Redspear, but your proposal should work just fine.

[another_commander]

A quick search on the net brings up this:

The SUBST command works in Windows 7 but the substituted drive is only visible in the same privilege level. Running your SUBST command in a NON-elevated command prompt should solve your problem.

Redspear, have you changed user access privileges at any point recently? Check the shortcut used for msys.bat (right click, Properties, Advanced...). Is it set to run as administrator? You can try toggling this option and see if it helps.