Home » Stars! Clones, Extensions, Modding » FreeStars » Compiling under Linux
| Compiling under Linux |
Sun, 08 January 2006 18:03  |
|
 Madman |
 | Officer Cadet 1st Year |
Messages: 228
Registered: November 2003
Location: New Zealand | |
|
I've finally got motivated to have a bit of a look at freestars, with a view to seeing if I can contribute.
Is Linux meant to be one of the targets yet?
I tried to compile it on my Linux box and got the errors pasted below.
If Linux is not a target yet, I'll go back into lurk mode (I'm skilled at things like C++ and XML, but the gnu configuration system is a complete mystery), otherwise could someone indicate what I'm doing wrong, what software versions I need to use, or what is missing?
=========================================================
$ ./configure
bash: ./configure: No such file or directory
(Ok, maybe the instructions need updating here)
$ autoconf
configure.ac:5: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:6: error: possibly undefined macro: AM_PATH_CPPUNIT
configure.ac:7: error: possibly undefined macro: AM_CONFIG_HEADER
$ ./configure
./configure: line 1269: syntax error near unexpected token `freestars,0.1'
./configure: line 1269: `AM_INIT_AUTOMAKE(freestars,0.1)'
$ aclocal
aclocal:configure.ac:6: warning: macro `AM_PATH_CPPUNIT' not found in library
$ automake
configure.ac: required file `./install-sh' not found
configure.ac: required file `./missing' not found
Server/Makefile.am: required file `./depcomp' not found
configure.ac:7: required file `config.h.in' not found
Running:
Debian 64-bit Linux (the 'testing' distribution on amd64)
autoconf (GNU Autoconf) 2.59
automake (GNU automake) 1.9.6
aclocal (GNU automake) 1.9.6
GNU Make 3.81beta4
gcc (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)
Report message to a moderator
|
|
|
| | | | | | |
| Re: Compiling under Linux |
Sat, 14 January 2006 18:59  |
|
| Madman |
| Officer Cadet 1st Year |
Messages: 228
Registered: November 2003
Location: New Zealand | |
|
I haven't yet found out how to build FreeStars using all the configure stuff, so I decided to look at running gcc on all the cpp files to see what happened.
Compiling the server with 32-bit gcc, I get the following warning:
stl_numeric.h: In function '_Tp std::accumulate(_InputIterator, _InputIterator, _Tp, _BinaryOperation) [with _InputIterator = std::_Deque_iterator<const FreeStars::RacialTrait*, const FreeStars::RacialTrait* const&, const FreeStars::RacialTrait* const*>, _Tp = double, _BinaryOperation = double (*)(long int, const FreeStars::RacialTrait*)]':
Server/Race.cpp:709: instantiated from here
stl_numeric.h:116: warning: converting to 'long int' from 'double'
I haven't tracked that one down yet to see if it will blow anything up.
More seriously, under 64-bit gcc I get the above warning, plus the following errors (I've snipped it a bit because the same sort of error occurs several times):
Server/Player.cpp:52: warning: passing NULL to non-pointer argument 3 of 'void std::deque<_Tp, _Alloc>::insert(typename std::_Deque_base<_Tp, _Alloc>::iterator, _InputIterator, _InputIterator) [with _InputIterator = long int, _Tp = FreeStars::BattlePlan*, _Alloc = std::allocator<FreeStars::BattlePlan*>]'
stl_deque.h: In member function 'void std::deque<_Tp, _Alloc>::_M_insert_dispatch(typename std::_Deque_base<_Tp, _Alloc>::iterator, _Integer, _Integer, __true_type) [with _Integer = long int, _Tp = FreeStars::BattlePlan*, _Alloc = std::allocator<FreeStars::BattlePlan*>]':
stl_deque.h:1135: instantiated from 'void std::deque<_Tp, _Alloc>::insert(typename std::_Deque_base<_Tp, _Alloc>::iterator, _InputIterator, _InputIterator) [with _InputIterator = long int, _Tp = FreeStars::BattlePlan*, _Alloc = std::allocator<FreeStars::BattlePlan*>]'
Server/Player.cpp:52: instantiated from here
stl_deque.h:1348: error: invalid static_cast from type 'long int' to type 'FreeStars::BattlePlan*'
Looking at that line in Server/Player.cpp
mBattlePlans.insert(mBattlePlans.begin(), Rules::GetConstant("MaxBattlePlans"), NULL);
mBattlePlans is a deque of pointers
deque<BattlePlan *> mBattlePlans;
but Rules::GetConstant("MaxBattlePlans") returns a long int.
which of course breaks on systems where long int and pointers are different sizes.
Is there a reason that a long int is getting inserted into a queue of pointers?
Report message to a moderator
|
|
|
|
| Re: Compiling under Linux |
Fri, 20 January 2006 14:44 |
|
| Orion |
 | Crewman 2nd Class |
Messages: 15
Registered: November 2005
Location: Strasbourg, France | |
|
Hello,
here I describe my attempt at compiling FreeStars on my GNU/Linux box. I'll speak here about the server, the client being another story.
First, I extracted the source under CVS, using the instructions given on the CVS page of FreeStars.
After that, I needed to download the TinyXml library used by FreeStars. The home page of TinyXml is http://www.grinninglizard.com/tinyxml/
Here, I chose to download the packeged version tinyxml_2_4_3.tar.gz. I copied the file into the 'freestars' directory and unpacked it there.
As I had a problem with CPPUNIT, which probably is a unit test module for C++ unknown by me, I decided to ignore it. To do that, I edited the file configure.ac and commented out the line concerning AM_APTH_CPPUNIT by putting an sharp (#) at the beginning of the line.
I could then bootstrap the autotools by entering following commands, from the freestars directory :
aclocal
autoheader
automake --add-missing --copy
autoconf
I simply ignored the warning about AM_PATH_GLIB being underquoted.
It was then time to use the classic installations commands on a GNU/Linux box :
./configure
make
I got a huge number of warnings, mostly like the following example :
Battle.cpp: In member function 'bool FreeStars::Battle::FightRound()':
Battle.cpp:297: warning: comparison between signed and unsigned integer expressions
I also had some other warning types, but I didn't investigate them, as I got an error :
../tinyxml/tinystr.cpp:112: fatal error: opening dependency file .deps/../tinyxml/tinystr.Tpo: Aucun fichier ou rpertoire de ce type
The french text means "No file or directory of this type".
And here I am today, not knowing how to continue. I hope that this is of some help, and maybe that somebody can help me to continue.
The Client is not yet incorporated into the "configure" framework. So compiling it can only be done by hand. This is more complicated, as it needs the wxWidget installed.
My environment is the same as the one described by Madman in the previous post, except that I am running Debian on an AMD32 processor (testing distribution too).
Orion
Report message to a moderator
|
|
|
|
| Re: Compiling under Linux |
Fri, 20 January 2006 16:04 |
|
| Madman |
| Officer Cadet 1st Year |
Messages: 228
Registered: November 2003
Location: New Zealand | |
|
| Orion wrote on Sat, 21 January 2006 08:44 |
As I had a problem with CPPUNIT, which probably is a unit test module for C++ unknown by me, I decided to ignore it. To do that, I edited the file configure.ac and commented out the line concerning AM_APTH_CPPUNIT by putting an sharp (#) at the beginning of the line.
I could then bootstrap the autotools by entering following commands, from the freestars directory :
aclocal
autoheader
automake --add-missing --copy
autoconf
I simply ignored the warning about AM_PATH_GLIB being underquoted.
It was then time to use the classic installations commands on a GNU/Linux box :
./configure
make
|
Thank you, that is very useful. I was missing 'autoheader', and the options to automake.
| Quote: |
I got a huge number of warnings, mostly like the following example :
Battle.cpp: In member function 'bool FreeStars::Battle::FightRound()':
Battle.cpp:297: warning: comparison between signed and unsigned integer expressions
|
Before doing the configre stuff, go into Server/Makefile.am and remove the -Wall from the AM_CXXFLAGS line.
All this does is removes the warnings, but it makes it less intimidating.
Getting it to compile cleanly with -Wall is a worthy goal, but someone has to do a lot of cleanup with the signed/unsigned stuff before this becomes useful.
| Quote: |
I also had some other warning types, but I didn't investigate them, as I got an error :
../tinyxml/tinystr.cpp:112: fatal error: opening dependency file .deps/../tinyxml/tinystr.Tpo: Aucun fichier ou rpertoire de ce type
The french text means "No file or directory of this type".
|
OK, that one is easy - just create a directory Server/tinyxml, and it will have somewhere to put the .Tpo files. There is probably a proper way of doing it, but this will get things to the next stage:
make[2]: Entering directory `/home/roy/games/freestars/freestars/Server'
make[2]: *** No rule to make target `../MersenneTwister/mt19937ar.o', needed by `fs-server'. Stop.
make[2]: Leaving directory `/home/roy/games/freestars/freestars/Server'
This one hopefully shouldn't be too hard either - more makefile madness.
| Quote: |
The Client is not yet incorporated into the "configure" framework. So compiling it can only be done by hand. This is more complicated, as it needs the wxWidget installed.
|
Well, wxWidgets do seem to be available as Debian packages. The problem is there seems to be a choice of a dozen or so packages, and I don't know whcih ones to install (I'm running KDE, for Gnome I think it would be easier).
| Quote: |
My environment is the same as the one described by Madman in the previous post, except that I am running Debian on an AMD32 processor (testing distribution too).
|
I think the only difference is that I get errors when trying to put an integer onto a queue of pointers (this is bad anyway, but only the 64 bit environment makes it an error). I commented those lines out for the purposes of this post.
Report message to a moderator
|
|
|
| |
| Re: Compiling under Linux |
Fri, 20 January 2006 22:11 |
|
| LEit |
 | Lt. Commander |
Messages: 879
Registered: April 2003
Location: CT | |
|
The MSVC++ build files are the .dsw and .dsp files. Unfortunatly or fortunatly, they're different then what you'll use for pretty much any other complier.
A lot of the warnings are turned off by #pragmas, those won't work on compilers other then MSVC.
#pragma warning(disable : 4786) // identifier was truncated to '255' characters in the debug information
#pragma warning(disable : 4514) // unreferenced inline function has been removed
#pragma warning(disable : 4710) // function '' not inlined
#pragma warning(disable : 4512) // assignment operator could not be generated
If that can be done for another compiler, that could be added to the FSServer.h file. There is nothing about signed/unsigned, and I compile with warning level 4 (execpt for STL stuff at level 3) and try to compile without warnings.
I only have MSVC, so that's all I can really code for.
Some things I've been meaning to get to that should make the process easier for other people:
Checking TinyXML into FreeStars, basicly to freeze it at a version that's known to work, although I'll probably update it as updates to TinyXML become available.
Making sure all (non compiler specific) defines are in a header file, currently there is at least one in the build file (TIXML_USE_STL).
Getting a combined file for which files are needed would be good, from my point of view it would be best if there was a converter between .dsp and a makefile. MSVC can use makefiles, but they're much less convient then the .dsp files.
There does seem to be a bunch of Linux programmers now, perhaps one of them will get everything working.
- LEitReport message to a moderator
|
|
|
| |
| Re: Compiling under Linux |
Sat, 21 January 2006 05:17 |
|
| Madman |
| Officer Cadet 1st Year |
Messages: 228
Registered: November 2003
Location: New Zealand | |
|
| LEit wrote on Sat, 21 January 2006 16:37 |
The parameters to insert are iterator to instert after, number of items to insert, and item to insert. So the Rules::GetConstant("MaxBattlePlans") returning an int isn't the problem, it seems the problem is that NULL is being interpreted an int - 0L and not a pointer.
|
Oops, you are right - changing the code to the following works fine:
mShipDesigns.insert(mShipDesigns.begin(), Rules::GetConstant("MaxShipDesigns"), (Ship*)NULL);
mBaseDesigns.insert(mBaseDesigns.begin(), Rules::GetConstant("MaxBaseDesigns"), (Ship*)NULL);
mFleets.insert(mFleets.begin(), Rules::MaxFleets, NULL);
mDefaultPayTax = false;
mBattlePlans.insert(mBattlePlans.begin(), Rules::GetConstant("MaxBattlePlans"), (BattlePlan*)NULL);
What is strange is that the fleet insert doesn't need the change (and all the other places the code uses NULL), and that NULL doesn't work in the first place - it is defined as the right thing to use as far as I can tell. Having to cast NULLs should be unnecessary. Oh well, at least I can move on from that for the moment, although it would be better to find the clean solution.
Report message to a moderator
|
|
|
| | | |
| Re: Compiling under Linux |
Sat, 21 January 2006 23:15 |
|
| NingunOtro |
 | Master Chief Petty Officer |
Messages: 105
Registered: September 2005
Location: Brussels, Belgium | |
|
| Madman wrote on Sat, 21 January 2006 22:57 |
... I can now work towards moving from 16 to 64 bit Stars ... never mind this 32 bit stuff in the middle  ...
|
But should'nt someone mind? I mean, I've got an amd64 running 32bit Fedora Core 4 and I can eventually upgrade to the 64bit version, but what about all the people around with 32bit (or less?) processors?
I do not know about possible source code incompatibilities, I mean that perhaps you inadvertently use 64bit specific features that could be very difficult to circumvent afterwards when somebody decides he needs to compile that source code for 32bits.
Since 64bit processors and OS run 32bit code quite well, should we not stick with the bit level most of us will be able to use?
If we were esteemed intelligent 'enough', they would have contacted us.
If we can not find them, either we are not smart enough, or they are smarter at hiding.Report message to a moderator
|
|
|
| | |
| Re: Compiling under Linux |
Sun, 22 January 2006 09:06 |
|
| crr65536 |
 | Chief Warrant Officer 3 |
Messages: 180
Registered: June 2005 | |
|
| Madman wrote on Sun, 22 January 2006 00:08 |
| crr65536 wrote on Sun, 22 January 2006 17:33 |
Or better yet - write code that doesn't depend on the processor. No need to introduce gratuitous incompatibilities.
|
That would be my intention - any slight changes I make to get it to compile on 64 bit aren't going to break it for anything else.
Software is most robust if it works on as many platforms is possible (sometimes at the expense of slight dumbing down of the code to handle working on several different compilers). Also, it's much less of a barrier to contributors. For instance, I wouldn't bother if 64-bit Linux was specifically excluded.
With me using 64 bit Linux, Orion using 32-bit Linux, and LEit using this strange obscure operating system that comes out of a place called Redmond , we could be reasonably sure that without much extra effort, Freestars would compile on just about anything.
Sometime if I get a sudden burst of enthusiasm, I might drag out my old MacOSX box and get it going on that 
|
In that case, that's great! My previous comment seems to have been based on a misinterpretation of what you said.
I'm planning on writing a simple client for FreeStars in Python (since Stars isn't a high-performance application, a high-level language is well suited to it). This would make making it portable really easy. However, it's been mostly just bouncing around in my head for a few months - the first step is always the hardest ... 
Report message to a moderator
|
|
|
| | | |
| Re: Compiling under Linux |
Sun, 22 January 2006 20:02 |
|
| Madman |
| Officer Cadet 1st Year |
Messages: 228
Registered: November 2003
Location: New Zealand | |
|
| Kotk wrote on Mon, 23 January 2006 05:50 |
Jeffs were developers from MS Excel team and their game engine is very nice, but UI looks like dot graph with some spreadsheets and dialogs attached. Turn based strategy game may actually provide amounts of eye candy if you so wish.
|
I really like the current interface, in that it's easy to use, and doesn't have lots of overlapping windows (except I'd like the fleet and planet displays done better, somehow).
I've tried some open source games where there are lots of windows full of information, and not having a 30" screen I find that really cluttered.
Eye candy is fine, as long as it doesn't get in the way of usability.
[Updated on: Sun, 22 January 2006 20:11] Report message to a moderator
|
|
|
|
Goto Forum:
Current Time: Fri May 03 17:21:27 EDT 2024
|
Members
Search
Help
Register
Login
Home
Jeffs were developers from MS Excel team and their game engine is very nice, but UI looks like dot graph with some spreadsheets and dialogs attached. Turn based strategy game may actually provide amounts of eye candy if you so wish. 
