COMPILE: Linux Port

[J Bytheway]

Originally posted by arrow014
Ok, I finally found some time to start working on this on my Mandriva 2006 partition. I downloaded, built and installed SVN, checked out the source, ran autoconf, got errors, installed autoconf and automake packages, ran ./configure, got errors, installed the byacc package, ran ./configure and it seems to get through just about everything fine now;

Well done on getting this far .

it generates a bunch of makefiles and then gives me a slightly wierd error:

...
config.status: creating ctp2_code/ui/Makefile
config.status: creating ctp2_code/ui/interface/Makefile
config.status: creating ctp2_code/os/include/config.h
config.status: executing depfiles commands
configure: configuring in ctp2_code/libs/anet
configure: running /bin/sh ctp2_code/os/autoconf/config/configure --prefix=/usr/local --cache-file=/dev/null --srcdir=.
/bin/sh: ctp2_code/os/autoconf/config/configure: No such file or directory
configure: error: /bin/sh ctp2_code/os/autoconf/config/configure failed for ctp2_code/libs/anet

Not sure what to do about this...is it really a problem? If so, any ideas what I need to do to fix it?

Yes, this is a real problem. I ran into it myself, but then forgot about it. The problem is this: The configure script is set to run a "child" configure script to do the configuring for the anet library. Now, when it tries to run this configure script for anet, it finds that the script isn't there. It tries to compensate by running a "generic" configure script in "ctp2_code/os/autoconf/config/" (this is the directory it was told to look for such things), but there is no such script (installing enough packages might make this generic script exist - it might even make it do the right thing, but I wouldn't count on it). Unfortunately this fallback behaviour makes the error message somewhat obscure. Anyway, the solution is to go to the ctp2_code/libs/anet directory and create the configure script (by running automake, etc. You can probably get away with simply running "../../../autogen.sh")

Actually, I'm rather proud of myself for getting this far by myself...I really haven't had much success building stuff from sources in the past, but I've been learning a lot about Linux development lately and it's starting to work a lot better.

I'm glad you're getting the hang of things . Learning to use these autotools (especially understanding their error messages) can be an uphill struggle. Tip for the day: when you get a strange error, look up for the last non-strange line. In this case, the line that tells you what's really going wrong was

configure: configuring in ctp2_code/libs/anet

Of course, identifying the last non-strange line can be tough!

Tomorrow I'll try to get around to finishing those instructions in the post above (and adding a note about this problem), but once you've done those which are there, you should at least be able to get to the ctp2 main menu. Let me know if anything else stumps you .

[J Bytheway]

I think the instructions above are now complete.

[ctplinuxfan]

Hi,

congratulations that you got the game running so far! I wish i could do a bit more atm, than reading this great news...

Regarding the child configure problem: I *think* i commited a change to the Makefile, i.e. running either

make bootstrap

or

make bootstrap-anet

within the top source directory should do the trick.
Sorry, if i forgot to mention it.

As far as i can tell, we now have everything of Johannes Sixt patch included.

What i remember to be also put on todo/plan is:[list=1][*]serialization: CTP2 uses a platform dependent form of serialisation, so for saving/loading games a format exchangable over different platforms would be great. If it works for now, definititely prio below input implementation.[*]add the patch to repository (for review)[*]look over type cast carefully;
Seems what i feared is correct, i.e. most void * casts are meant to be to a target uint32 value, not a value referenced by an uint32 ptr, as i hoped. This could mean, that an uint32 is sometimes used to effectively store an address, i.e. a pointer to something. Whenever you see a crash when dereferencing a pointer cast to uint32 *, try to pass the pointer around or for a quick workaround cast to uint32 again. My vague guess is that this is a hack to provide a kind of unique id of an instance of an object. If so, an UUID algorithm placed somewhere (e.g. in ID class) could be an alternative.
When an uint32 is used to store pointers to instances, perhaps we'll stumble over back-casts to origin type as well.[/list=1]

[arrow014]

Regarding the child configure problem: I *think* i commited a change to the Makefile, i.e. running either

make bootstrap

or

make bootstrap-anet

within the top source directory should do the trick.
Sorry, if i forgot to mention it.

Aha! That did the trick. Now ./configure finishes fine, but make got hung up looking for flex, so I installed it from the Mandriva repository and make hummed along nicely until it hit ctp2_code/gfx/gfx_utils/tiffutil.cpp, where it complains about not seeing the header file tiffio.h. I noticed that this file was in the /ctp2_code/libs/tiff folder, so I copied that file to the other directory and it seemed to work ok. It also complained about tiff.h, so I did the same thing for that file. Then it couldn't find d3des/d3des.h, md5/global.h or md5/md5.h in ctp2_code/libs/anet/src/3rdparty/ while compiling ctp2_code/libs/anet/src/tca/tca.c. I noticed the zip files md5.zip and d3des.zip in one of those directories so I unzipped those and that stopped the complaints about the header files. Now it gives me the message "cc1: warnings being treated as errors" and about ten similar warnings, so it quits. I tried to look through the makefile in ctp2_code/libs/anet/src/linux/dp to see what I could do (maybe get rid of a -Werror somewhere?) but I couldn't figure it out (I told you--I'm rather new to this...). Any ideas on what I need to do next?

Examples of warnings:

../../tca/tca.c: In function 'tca_pwchange_generate':
../../tca/tca.c:368: warning: passing argument 1 of 'des2key' discards qualifiers from pointer target type
../../tca/tca.c:369: warning: passing argument 1 of 'Ddes' discards qualifiers from pointer target type
../../tca/tca.c:378: warning: passing argument 1 of 'D2des' discards qualifiers from pointer target type


I go for my third chemo treatment on Wednesday (Nov 16th) so I'll probably be out of commission for a while again, but I'll get back to this eventually... ;-)

Thanks so much for all the help so far!

[J Bytheway]

Originally posted by ctplinuxfan
look over type cast carefully;
Seems what i feared is correct, i.e. most void * casts are meant to be to a target uint32 value, not a value referenced by an uint32 ptr, as i hoped. This could mean, that an uint32 is sometimes used to effectively store an address, i.e. a pointer to something. Whenever you see a crash when dereferencing a pointer cast to uint32 *, try to pass the pointer around or for a quick workaround cast to uint32 again. My vague guess is that this is a hack to provide a kind of unique id of an instance of an object. If so, an UUID algorithm placed somewhere (e.g. in ID class) could be an alternative.
When an uint32 is used to store pointers to instances, perhaps we'll stumble over back-casts to origin type as well.

I'm fairly sure I've seen this trick used to pass quantities of gold (the uint32 cast to a void*, passed, and then at its destination cast back to a uint32). Such cases can't be passed be reference (at least, not easily), because it would involve taking the reference of a temporary or local variable or allocating and deallocating memory.

[ctplinuxfan]

Originally posted by arrow014


Aha! That did the trick. Now ./configure finishes fine, but make got hung up looking for flex, so I installed it from the Mandriva repository and make hummed along nicely until it hit ctp2_code/gfx/gfx_utils/tiffutil.cpp, where it complains about not seeing the header file tiffio.h.

Try to install the dev package for the tiff library, it should contain the headers. It's most likely called libtiff-dev, libtiff-devel, tiff-dev, tiff-devel or something like that. The tiff headers in repository are for the windows build (maybe outdated/not match your tiff library version).

Then it couldn't find d3des/d3des.h, md5/global.h or md5/md5.h in ctp2_code/libs/anet/src/3rdparty/ while compiling

Thanks, i oversaw this, because i have dev-files for md5/d3des also installed. I corrected the GNUMakefile.am accordingly.

Examples of warnings:

../../tca/tca.c: In function 'tca_pwchange_generate':
../../tca/tca.c:368: warning: passing argument 1 of 'des2key' discards qualifiers from pointer target type

I'm certainly sure it's due to the missing dependencies fixed in r496, because after unzipping, the d3des.const patch must be applied, too.
It should work now again, but by running

make clean ; make unpack

within the 3rdparty directory, you can get it working on r495 and before, either.

[ctplinuxfan]

Originally posted by J Bytheway
I'm fairly sure I've seen this trick used to pass quantities of gold (the uint32 cast to a void*, passed, and then at its destination cast back to a uint32). Such cases can't be passed be reference (at least, not easily), because it would involve taking the reference of a temporary or local variable or allocating and deallocating memory.

Well, it's great that it works now!
Maybe we can improve it later or at least use size_t or long for that purpose, because uint32 isn't large enough to store an address on all platforms.

[J Bytheway]

Originally posted by ctplinuxfan
Well, it's great that it works now!
Maybe we can improve it later or at least use size_t or long for that purpose, because uint32 isn't large enough to store an address on all platforms.

I don't think that's a problem. I think the problem would occur if a void* were not big enough to store a uint32... Of course, that's just based on the couple of examples I've seen. Perhaps there are other places where the reverse holds.

[arrow014]

Ugh...chemo was !@#* this time... I was out for a whole week with nausea, headaches, sore muscles, etc etc. Oh, well, enough complaining, I guess, God knows it's better than dying of cancer. And only three more to go (hopefully).

Anyway...back to the current quest...

Originally posted by ctplinuxfan

It should work now again, but by running

make clean ; make unpack

within the 3rdparty directory, you can get it working on r495 and before, either.

Ok, that worked, sweet. A few more minutes of successful compilations flying up my screen later, it stops yet again with:

ui/aui_ctp2/c3imageformats.cpp:46:23: error: SDL_image.h: No such file or directory
ui/aui_ctp2/c3imageformats.cpp: In member function 'virtual AUI_ERRCODE TargaImageFormat::Load(const tchar*, aui_Image*)':
ui/aui_ctp2/c3imageformats.cpp:171: error: 'IMG_Load' was not declared in this scope
make[1]: *** [c3imageformats.o] Error 1
make[1]: Leaving directory `/usr/src/ctp2/ctp2_code'
make: *** [all-recursive] Error 1

Doing a quick 'find -name "SDL_image.h"' doesn't come up with anything in the whole ctp2 directory structure...so maybe I'm missing another library...some TGA lib, perhaps?

Happy Thanksgiving to all!

-- Michael

[J Bytheway]

You need to install the SDL library (look for packages named libsdl*). Under Debian this is split into many packages, so if you're in a similar situation then use your package management tools to get the one with that file in.

[arrow014]

Originally posted by J Bytheway
You need to install the SDL library (look for packages named libsdl*). Under Debian this is split into many packages, so if you're in a similar situation then use your package management tools to get the one with that file in.

Got it. Next problem:

make[2]: *** No rule to make target `gfx/layers/libgfxlayers.la', needed by `ctp2'. Stop.

No idea what to do here...it sounds like something's missing from a makefile somewhere or something...

[J Bytheway]

Check ctp2_code/gfx/Makefile.am Does it mention 'layers' in SUBDIRS? It should. My copy managed to lose its reference to layers - I don't know how. Things have got rather confused in my working copy, so I'm not sure exactly what's in the repository any more...

[Martin Gühmann]

Originally posted by J Bytheway
Check ctp2_code/gfx/Makefile.am Does it mention 'layers' in SUBDIRS? It should. My copy managed to lose its reference to layers - I don't know how. Things have got rather confused in my working copy, so I'm not sure exactly what's in the repository any more...

Is there no way on Linux to check for modifications in your working copy? TortoiseSVN has, in fact it generates a list of all the files you have modified and you can inspect them with the diff viewer.

-Martin

[arrow014]

Originally posted by J Bytheway
Check ctp2_code/gfx/Makefile.am Does it mention 'layers' in SUBDIRS? It should. My copy managed to lose its reference to layers - I don't know how. Things have got rather confused in my working copy, so I'm not sure exactly what's in the repository any more...

Nope, it was missing, so I added it to Makefile.am and Makefile, too. I guess I'm still a little fuzzy as to the relationship between these two files, because it didn't work after modifying just the Makefile.am file, but it did work after modifying the Makefile itself. I'm guessing the .am file is involved in the generation of the Makefile (perhaps in that autogen.sh script that I ran at the beginning?). Is that correct?

Anyway, after that it makes it to what looks like the final step--or close to it (I've omitted some of this output because it's so long):

g++ {compiler options} -o ctp2 {libraries and object files including -lttf}
/usr/bin/ld: cannot find -lttf
{make exit messages}

TTF? True Type Font? I've installed several font libraries and packages...I'm not sure what would be missing, unless it's something specific to this project. Any links?

Dohhh.....after all this I feel like I'm so close!!!

[J Bytheway]

Originally posted by Martin Gühmann
Is there no way on Linux to check for modifications in your working copy? TortoiseSVN has, in fact it generates a list of all the files you have modified and you can inspect them with the diff viewer.

There is a way, normally, but my working copy is really messed up. It seems to be completely impossible to update it. I think I need to remove it and start again with a new copy.