Hello again, I managed to rebuild TR 0.6.1 for Win32 and also partially fix the audio system to use modern FMOD. Right now there is an audio bug, where the "engine.wav" and "gravel.wav" sounds suddenly cut off a couple of seconds after starting a race. It seems that this bug only affects looping sounds because "gear.wav" can still be heard.
There are a few other problems: first, I have to use a modified "config.h" file based on the one provided by Onsemeliot. This is hackish because it wasn't automatically generated as it should have been -- but I can't do that! The second problem is that the libraries were dynamically linked, so DLLs float around the game executable. (This isn't really a problem, but it does look ugly.)
My question is: how do we cooperate to release a possible 0.6.1-win32 build, in the fortunate case that I fix the looping sound bug soon eventually?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I fixed the looping bug which I introduced while updating the FMOD code. Let me know what your intentions are with regards to releasing 0.6.1 for Win32.
In addition to a plain ZIP archive, I can also provide a Windows setup wizard created with NSIS. Somebody other than myself will have to test the game and scan it for viruses (you can never be too careful).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it's great to provide a Windows executable for 0.6.1 also - even better if you can manage to do an installer. The only reason we didn't have one so far is because nobody of us was able to make it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Andrei and thank you for your efforts! I had no idea (or just forgot) the Windows version uses FMOD, thanks for handling it.
I can test on Windows 8.1 on an Asus T100. I don't have any virus scanner, I would just install avast! Free Antivirus, AVG Antivirus FREE or Avira Antivirus FREE.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am uncomfortable using source control. I would rather upload the full source code somewhere and leave it to someone else to merge the changes into the SVN tree.
The submitted code will have to be thoroughly tested on both Windows and Linux, because of small "compatibility" changes that I had to make: I manually set DATADIR to "." and I had to remove the the forward slashes "/" when loading sounds (e.g. "sounds/engine.wav" instead of "/sounds/engine.wav"), otherwise the game would crash with FMOD saying "file not found".
Then there is also FMOD itself, with is not open-source software, the DLL of which will have to be redistributed.
EDIT: Hello Iwan, I didn't see your post. Just let me know where to upload the source code and the game ZIP, and I'll also create the Setup eventually.
Last edit: Andrei 2015-04-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can totally relate. The common method for contributing to git repositories is to fork it and request pulling from your fork and that process is totally confusing to me still. I will most likely be able to add your changes to svn.
The submitted code will have to be thoroughly tested on both Windows and Linux
I can also test on Linux, Arch Linux 64bit.
Then there is also FMOD itself, with is not open-source software, the DLL of which will have to be redistributed.
FMOD for the windows version should be fine. It's mentioned in the README.txt (please make sure to include all .txt files in the windows zip & installer)
./doc/COPYING.txt
./doc/README.txt
./doc/README-stereo.txt
./doc/DATA_AUTHORS.txt
)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You will notice a folder named "libraries-win32". It is required for future Win32 programmers, otherwise they'll have to rebuild SDL, SDL_image, PhysFS, libjpeg, libpng and zlib before attempting to build TriggerRally on Windows. So the question is, should that folder be distributed along the source code for Win32 programmers' convenience? (I would say yes but I'm heavily biased to say so.)
Start the game by running "TriggerRally\trigger-rally-0.6.1\data\TriggerRally.exe".
Last edit: Andrei 2015-04-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to clarify w.r.t. NSIS installer: I will build it as soon as you guys officially release the 0.6.1-win32 binary ZIP. This is so that the contents of the installer and the ZIP archive will be identical.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
avast found no virus in your files (I unzipped it first).
the time it takes to go from "start race" to car selection is surprisingly long sometimes. I guess I'm overestimating my T100's power :)
the bang.wav sound stops working on Windows and in wine. After about 1m10s of flying and falling around a level. There just is not more collision sound then. The gear switch sound also disappears.
Complete speculation: each individual (non-looped) sound occupies a new channel each time it's played. After a while, we run out of available channels.
I tried doing nothing for a minute. The sounds worked still, so it doesn't seem to be related to game run time but probably to quantity of use of the sounds.
Since https://github.com/red-eclipse/base/tree/master/bin/tools includes binary files, I think it'd be fine to do the same in svn. The files would be located in trigger-rally-0.6.1/ [I think I confused something here, see my next reply for clarification]
For the windows release, I will rename "data/" to "trigger-rally-0.6.1/" and move the "doc/*" files there and only publish "trigger-rally-0.6.1/" inside "trigger-rally-0.6.1.zip"
Last edit: qubodup 2015-05-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Iwan, you are probably right with your speculation. Apparently this error was fixed by passing the FMOD_UNIQUE flag when loading sounds, ensuring that each sound is only played on one channel at a time. (This will probably have to be revisited if AI cars are ever added.)
I have upgraded my Dev-C++ IDE from version 5.10 to 5.11. This new version uses TDM-GCC 4.9.2 instead of 4.8.1. Also the project settings have been changed to tune the executable for i686 specifically. As a result of all this, a new TriggerRally.exe is available.
In addition, I finally stripped the debugging information from the Win32 libraries (.a and .dll files). As a result they are much smaller and the game should start up faster.
Here is the update (containing stripped libraries, new executable and full source code):
@Andrei
"I am uncomfortable using source control. "
I too can relate, but in the context of open-source projects this is a necessity more often than not. I usually settle on using a GUI, which helps things considerably. You can use RapidSVN, which works on Linux and Windows: http://www.rapidsvn.org/
Checking in changes yourself is almost always preferable because you understand exactly what needs to be checked in or not, whereas others may only have a vague understanding of your changes.
I'll be happy to give you instructions to get started if you want.
@Iwan
"includes binary files, I think it'd be fine to do the same in svn."
Why do we need to include binary files in SVN? I'm not sure this is a good idea. At least for open-source projects like Debian, including binaries in the release is a big no-no.
Actually this touches upon an issue I've been considering for some time, namely migrating Trigger source code to github. GIT brings considerable advantages (along with complexity, it must be said), but it simplifies the task of proposing changes (Pull Requests) and allows keeping parallel branches (e.g. a dedicated windows branch with all changes necessary for compiling Windows releases, which easily may contain binaries if need be).
@Andrei
I looked into the Update_002, but I'm not sure what to do with it. I couldn't find a Trigger.exe in there. Where should I look?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Liviu forget about Update 2, I am now posting Update 3!
To answer your question, TriggerRally.exe is in the data folder. You must first download the full project archive (70 MB) and then apply the update by copying its files over the original ones.
About Update 3: I rebuilt all of the Win32 libraries -- properly this time. All are optimized for i686 instead of my build machine and they're properly stripped. Also enabled optimizations for PhysFS, which I didn't do originally (so we were probably using the Debug version of PhysFS all this time).
I think that as far as Windows users are concerned, optimizing for i686 is the best choice. At least until we will have a Win64 release.
@Liviu about RapidSVN, I'll look into the utility later, thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe we are ready to release 0.6.1-win32. I could provide an Update 4, but it would be ridiculous: the only difference is that the executable is optimized slightly differently:
"-O2 -march=i686 -mtune=native"
instead of
"-Ofast -march=i686"
If you find any bugs in Update 3, let me know. If you have suggestions about optimizing the program and libraries differently, also let me know.
Otherwise I am standing by for the official 0.6.1-win32 ZIP release (made from Full + Update 3) which I will convert to a Windows installer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Works nicely on Wine. If no other issues are found, I say go ahead with preparing the installer.
I want the installer to contain the exact same data as the plain ZIP release, therefore the ZIP will have to be created first, preferably by another person, after the game has been throughly tested and scanned for viruses. (I scan everything I upload before giving the links, but modern viruses can be very stealthy.)
BTW, what modifications did you have to do to the code (if any) to get the Win builds? Could you document what you did?
Here are all the things that I remember doing:
config.h: added a manually edited config.h file (couldn't generate it)
audio.cpp: rewrote entire FMOD wrapper code, applied Allman formatting, added mini GNU2 license (I intend to do this for all source code eventually)
audio.h: made small changes for FMOD (e.g. used "FMOD_SOUND" instead of "uint32")
main.cpp: removed slash prefix from sounds, otherwise FMOD would fail with "file not found" (e.g. load "sounds/engine.wav" instead of "/sounds/engine.wav"), added WinMain() function activated for Windows build (also it ignores command line parameters)
app.cpp: manually defined DATADIR to "." if it wasn't defined by the configure script
?: changed "null" to "nullptr", deleted empty lines, deleted extra spaces (code meaning wasn't changed)
OK. We are talking then of modifications to the source code that will affect Linux, too. In this case, the binaries you've come up with cannot be released as 0.6.1, as they do not conform to the source code of that release. We will need first to check in all relevant changes in SVN, check that all works fine on Linux and Windows, and perform a 0.6.2 release when ready.
config.h: What issues did you hit when generating this file?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We will need first to check in all relevant changes in SVN, check that all works fine on Linux and Windows, and perform a 0.6.2 release when ready.
I know this is a silly question, but who will do these things? Obviously I'll build and test on Windows, but to also manage the SVN tree and Linux release is too much for me.
Also I disagree with releasing this as version 0.6.2. In function and in data the current build is identical to 0.6.1. In other words, there were no source code changes or data changes which make them appear different to the user and this was on purpose.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great job!
1. The sound problem is fixed in Wine and Windows 8.1 (tested 5 minutes of aggressive gameplay)
2. avast! finds no threats.
Unfortunately, the project doesn't build on Linux (Arch Linux 64bit) any more: http://codepad.org/ggQWUgH7 (ctrl+f search for "error") any idea what's going on? Current SVN without the updated code does still compile.
Why do we need to include binary files in SVN? I'm not sure this is a good idea. At least for open-source projects like Debian, including binaries in the release is a big no-no.
The binary files would make it easier to make windows releases. They would be in a separate directory and would not be included in any releases. Debian would also not include them, just like it should have done with the copyrighted/trademarked car textures in 0.6.1
0.6.2
We will just do a win32-only 0.6.1a release.
I know this is a silly question, but who will do these things?
It is a very fair question because as far as I know none of us handles code on a daily basis. As seen above, I can test-compile and run on Linux. I'm probably the one who will commit the changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Andrei
"I know this is a silly question, but who will do these things?"
No worries about the new release. I can take care of this.
"no source code changes or data changes which make them appear different to the user"
From what I see, there were source code changes, and that's the point. The binaries no longer conform to 0.6.1 code, and while this may seem like a petty point, projects generally take a religious approach at ensuring that released source code and binary packages match. Your changes are not only Windows related, but also affect Linux builds (whether they're cosmetic or no, they could trigger build failures on other platforms, etc.), and as such all such changes need to be merged, tested, and a new release performed.
Taking care of a new release is not a big deal, but it needs to be done. We could even go for a minor 0.6.1.1 release...
@Iwan
"The binary files would make it easier to make windows releases. They would be in a separate directory and would not be included in any releases. "
I am not comfortable with placing binaries inside the main SVN tree. If these binaries are part of the Windows-only release, then it's the Windows packager's business and has no place in the main source code tree. If we switched to GIT, it would be easier to have a Windows-specific branch containing the needed binaries. But even then we should discuss whether such files should be in the tree.
"Debian would also not include them, just like it should have done with the copyrighted/trademarked car textures in 0.6.1"
A whole different kettle of fish. Debian is the most religious of the free-software advocates, and it has NEVER complained about these for years... Please let's not go into this again. Our current set-up allows people to have the FOSS only textures, as well as the historic textures. With Andrei's help, I think we can easily make this a configurable option in the config file. This is a compromise, and should work for most of us.
"We will just do a win32-only 0.6.1a release."
Since the code changes seem to affect Linux builds too, I favor merging them into SVN and performing a 0.6.1.1 release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I must clarify that the source code I've been working on is from trigger-rally-0.6.1.tar.bz2 and not from the SVN.
Anyway, the problem had to do with macros (in particular, "UNIX" was used instead of "unix"). Later I'll have to investigate "WIN32" versus "_WIN32". On Linux, the Update 4 below should build and run with:
./configure --datadir=`pwd`/data
CPPFLAGS="-w" jam
./trigger
The above CPPFLAGS suppresses the warnings so we can focus on the errors, for now.
Here is Update 4, including the full source code and a new Windows executable.
The new Win32 EXE is optimized with "-O2 -march=i686 -mtune=native".
Hello again, I managed to rebuild TR 0.6.1 for Win32 and also partially fix the audio system to use modern FMOD. Right now there is an audio bug, where the "engine.wav" and "gravel.wav" sounds suddenly cut off a couple of seconds after starting a race. It seems that this bug only affects looping sounds because "gear.wav" can still be heard.
There are a few other problems: first, I have to use a modified "config.h" file based on the one provided by Onsemeliot. This is hackish because it wasn't automatically generated as it should have been -- but I can't do that! The second problem is that the libraries were dynamically linked, so DLLs float around the game executable. (This isn't really a problem, but it does look ugly.)
My question is: how do we cooperate to release a possible 0.6.1-win32 build, in the fortunate case that I fix the looping sound bug
sooneventually?I fixed the looping bug which I introduced while updating the FMOD code. Let me know what your intentions are with regards to releasing 0.6.1 for Win32.
In addition to a plain ZIP archive, I can also provide a Windows setup wizard created with NSIS. Somebody other than myself will have to test the game and scan it for viruses (you can never be too careful).
I think it's great to provide a Windows executable for 0.6.1 also - even better if you can manage to do an installer. The only reason we didn't have one so far is because nobody of us was able to make it.
Hello Andrei and thank you for your efforts! I had no idea (or just forgot) the Windows version uses FMOD, thanks for handling it.
I can test on Windows 8.1 on an Asus T100. I don't have any virus scanner, I would just install avast! Free Antivirus, AVG Antivirus FREE or Avira Antivirus FREE.
I am uncomfortable using source control. I would rather upload the full source code somewhere and leave it to someone else to merge the changes into the SVN tree.
The submitted code will have to be thoroughly tested on both Windows and Linux, because of small "compatibility" changes that I had to make: I manually set DATADIR to "." and I had to remove the the forward slashes "/" when loading sounds (e.g. "sounds/engine.wav" instead of "/sounds/engine.wav"), otherwise the game would crash with FMOD saying "file not found".
Then there is also FMOD itself, with is not open-source software, the DLL of which will have to be redistributed.
EDIT: Hello Iwan, I didn't see your post. Just let me know where to upload the source code and the game ZIP, and I'll also create the Setup eventually.
Last edit: Andrei 2015-04-29
I can totally relate. The common method for contributing to git repositories is to fork it and request pulling from your fork and that process is totally confusing to me still. I will most likely be able to add your changes to svn.
I can also test on Linux, Arch Linux 64bit.
FMOD for the windows version should be fine. It's mentioned in the README.txt (please make sure to include all .txt files in the windows zip & installer)
./doc/COPYING.txt
./doc/README.txt
./doc/README-stereo.txt
./doc/DATA_AUTHORS.txt
)
I'll scan for viruses and then I'll upload a ZIP file of the entire project folder for you to test. Just let me know where exactly I should upload it.
Note that if you want to build on Windows, you will need to install Orwell Dev-C++ and FMOD Studio API (to the default directory in Program Files).
For temporary file sharing I suggest dropbox, google drive, box.net, mediafire or fileconvoy.com
I wasn't planning on building on Windows. I though you would be able to provide a compiled version?
Last edit: qubodup 2015-04-29
Here is the project folder containing source, data and built executable.
http://www.fileconvoy.com/dfl.php?id=gda7626d00bb487c9999657082f5d6d5091da63d73
You will notice a folder named "libraries-win32". It is required for future Win32 programmers, otherwise they'll have to rebuild SDL, SDL_image, PhysFS, libjpeg, libpng and zlib before attempting to build TriggerRally on Windows. So the question is, should that folder be distributed along the source code for Win32 programmers' convenience? (I would say yes but I'm heavily biased to say so.)
Start the game by running "TriggerRally\trigger-rally-0.6.1\data\TriggerRally.exe".
Last edit: Andrei 2015-04-29
Just to clarify w.r.t. NSIS installer: I will build it as soon as you guys officially release the 0.6.1-win32 binary ZIP. This is so that the contents of the installer and the ZIP archive will be identical.
Thanks!
Complete speculation: each individual (non-looped) sound occupies a new channel each time it's played. After a while, we run out of available channels.
I tried doing nothing for a minute. The sounds worked still, so it doesn't seem to be related to game run time but probably to quantity of use of the sounds.
Since https://github.com/red-eclipse/base/tree/master/bin/tools includes binary files, I think it'd be fine to do the same in svn. The files would be located in trigger-rally-0.6.1/ [I think I confused something here, see my next reply for clarification]
For the windows release, I will rename "data/" to "trigger-rally-0.6.1/" and move the "doc/*" files there and only publish "trigger-rally-0.6.1/" inside "trigger-rally-0.6.1.zip"
Last edit: qubodup 2015-05-01
Iwan, you are probably right with your speculation. Apparently this error was fixed by passing the FMOD_UNIQUE flag when loading sounds, ensuring that each sound is only played on one channel at a time. (This will probably have to be revisited if AI cars are ever added.)
The update (current source and executable) is at:
http://www.fileconvoy.com/dfl.php?id=gb3db4930da828f6399965731022ae3e633165b79a
I have upgraded my Dev-C++ IDE from version 5.10 to 5.11. This new version uses TDM-GCC 4.9.2 instead of 4.8.1. Also the project settings have been changed to tune the executable for i686 specifically. As a result of all this, a new TriggerRally.exe is available.
In addition, I finally stripped the debugging information from the Win32 libraries (.a and .dll files). As a result they are much smaller and the game should start up faster.
Here is the update (containing stripped libraries, new executable and full source code):
http://www.fileconvoy.com/dfl.php?id=gd42e0ff919c06997999658000066885b2c6ca2b29
@Andrei
"I am uncomfortable using source control. "
I too can relate, but in the context of open-source projects this is a necessity more often than not. I usually settle on using a GUI, which helps things considerably. You can use RapidSVN, which works on Linux and Windows:
http://www.rapidsvn.org/
Checking in changes yourself is almost always preferable because you understand exactly what needs to be checked in or not, whereas others may only have a vague understanding of your changes.
I'll be happy to give you instructions to get started if you want.
@Iwan
"includes binary files, I think it'd be fine to do the same in svn."
Why do we need to include binary files in SVN? I'm not sure this is a good idea. At least for open-source projects like Debian, including binaries in the release is a big no-no.
Actually this touches upon an issue I've been considering for some time, namely migrating Trigger source code to github. GIT brings considerable advantages (along with complexity, it must be said), but it simplifies the task of proposing changes (Pull Requests) and allows keeping parallel branches (e.g. a dedicated windows branch with all changes necessary for compiling Windows releases, which easily may contain binaries if need be).
@Andrei
I looked into the Update_002, but I'm not sure what to do with it. I couldn't find a Trigger.exe in there. Where should I look?
@Liviu forget about Update 2, I am now posting Update 3!
To answer your question, TriggerRally.exe is in the data folder. You must first download the full project archive (70 MB) and then apply the update by copying its files over the original ones.
Full project archive:
http://www.fileconvoy.com/dfl.php?id=gda7626d00bb487c9999657082f5d6d5091da63d73
Update 3:
http://www.fileconvoy.com/dfl.php?id=g2ad23a52b8ab2a04999658091e6576dd83d3df6cf
About Update 3: I rebuilt all of the Win32 libraries -- properly this time. All are optimized for i686 instead of my build machine and they're properly stripped. Also enabled optimizations for PhysFS, which I didn't do originally (so we were probably using the Debug version of PhysFS all this time).
I think that as far as Windows users are concerned, optimizing for i686 is the best choice. At least until we will have a Win64 release.
@Liviu about RapidSVN, I'll look into the utility later, thanks.
I believe we are ready to release 0.6.1-win32. I could provide an Update 4, but it would be ridiculous: the only difference is that the executable is optimized slightly differently:
"-O2 -march=i686 -mtune=native"
instead of
"-Ofast -march=i686"
If you find any bugs in Update 3, let me know. If you have suggestions about optimizing the program and libraries differently, also let me know.
Otherwise I am standing by for the official 0.6.1-win32 ZIP release (made from Full + Update 3) which I will convert to a Windows installer.
Works nicely on Wine. If no other issues are found, I say go ahead with preparing the installer.
BTW, what modifications did you have to do to the code (if any) to get the Win builds? Could you document what you did?
I want the installer to contain the exact same data as the plain ZIP release, therefore the ZIP will have to be created first, preferably by another person, after the game has been throughly tested and scanned for viruses. (I scan everything I upload before giving the links, but modern viruses can be very stealthy.)
Here are all the things that I remember doing:
Changes external to the source code:
OK. We are talking then of modifications to the source code that will affect Linux, too. In this case, the binaries you've come up with cannot be released as 0.6.1, as they do not conform to the source code of that release. We will need first to check in all relevant changes in SVN, check that all works fine on Linux and Windows, and perform a 0.6.2 release when ready.
config.h: What issues did you hit when generating this file?
When using MinGW/MSYS to run:
it gets to the point where it checks for the SDL version >= 1.2.5 and the following message box appears:
I know this is a silly question, but who will do these things? Obviously I'll build and test on Windows, but to also manage the SVN tree and Linux release is too much for me.
Also I disagree with releasing this as version 0.6.2. In function and in data the current build is identical to 0.6.1. In other words, there were no source code changes or data changes which make them appear different to the user and this was on purpose.
Great job!
1. The sound problem is fixed in Wine and Windows 8.1 (tested 5 minutes of aggressive gameplay)
2. avast! finds no threats.
Unfortunately, the project doesn't build on Linux (Arch Linux 64bit) any more: http://codepad.org/ggQWUgH7 (ctrl+f search for "error") any idea what's going on? Current SVN without the updated code does still compile.
The binary files would make it easier to make windows releases. They would be in a separate directory and would not be included in any releases. Debian would also not include them, just like it should have done with the copyrighted/trademarked car textures in 0.6.1
We will just do a win32-only 0.6.1a release.
It is a very fair question because as far as I know none of us handles code on a daily basis. As seen above, I can test-compile and run on Linux. I'm probably the one who will commit the changes.
@Andrei
"I know this is a silly question, but who will do these things?"
No worries about the new release. I can take care of this.
"no source code changes or data changes which make them appear different to the user"
From what I see, there were source code changes, and that's the point. The binaries no longer conform to 0.6.1 code, and while this may seem like a petty point, projects generally take a religious approach at ensuring that released source code and binary packages match. Your changes are not only Windows related, but also affect Linux builds (whether they're cosmetic or no, they could trigger build failures on other platforms, etc.), and as such all such changes need to be merged, tested, and a new release performed.
Taking care of a new release is not a big deal, but it needs to be done. We could even go for a minor 0.6.1.1 release...
@Iwan
"The binary files would make it easier to make windows releases. They would be in a separate directory and would not be included in any releases. "
I am not comfortable with placing binaries inside the main SVN tree. If these binaries are part of the Windows-only release, then it's the Windows packager's business and has no place in the main source code tree. If we switched to GIT, it would be easier to have a Windows-specific branch containing the needed binaries. But even then we should discuss whether such files should be in the tree.
"Debian would also not include them, just like it should have done with the copyrighted/trademarked car textures in 0.6.1"
A whole different kettle of fish. Debian is the most religious of the free-software advocates, and it has NEVER complained about these for years... Please let's not go into this again. Our current set-up allows people to have the FOSS only textures, as well as the historic textures. With Andrei's help, I think we can easily make this a configurable option in the config file. This is a compromise, and should work for most of us.
"We will just do a win32-only 0.6.1a release."
Since the code changes seem to affect Linux builds too, I favor merging them into SVN and performing a 0.6.1.1 release.
@Iwan, regarding Linux build.
I must clarify that the source code I've been working on is from trigger-rally-0.6.1.tar.bz2 and not from the SVN.
Anyway, the problem had to do with macros (in particular, "UNIX" was used instead of "unix"). Later I'll have to investigate "WIN32" versus "_WIN32". On Linux, the Update 4 below should build and run with:
The above CPPFLAGS suppresses the warnings so we can focus on the errors, for now.
Here is Update 4, including the full source code and a new Windows executable.
The new Win32 EXE is optimized with "-O2 -march=i686 -mtune=native".
http://www.fileconvoy.com/dfl.php?id=g8022538d7a46b176999658289290b86b776d5a52c