COMPILE: Linux Port

[cap601]

Using that changes the errors to:

bldque.cpp: In member function 'BuildQueue& BuildQueue::operator=(const BuildQueue&)':
bldque.cpp:1715: error: expected `<' before '(' token
bldque.cpp:1715: error: expected type-specifier before '(' token
bldque.cpp:1715: error: expected `>' before '(' token
bldque.cpp:1715: error: expected `<' before '(' token
bldque.cpp:1715: error: expected type-specifier before '(' token
bldque.cpp:1715: error: expected `>' before '(' token

[Martin Gühmann]

Originally posted by cap601
Using that changes the errors to:

I see, the forum can't display the code correctly, if I use the [ CODE ] tags, so I changed to [ PHP ] tags.

-Martin

[cap601]

With that I end up with exactly the same errors as with the original code.

[Martin Gühmann]

Originally posted by cap601
With that I end up with exactly the same errors as with the original code.

Well in that case you have to copy the members of BuildQueue manually:

		m_owner          = copy.m_owner;
		m_city           = copy.m_city;
		m_wonderStarted  = copy.m_wonderStarted;
		m_wonderStopped  = copy.m_wonderStopped;

-Martin

[cap601]

Changing that allows compilation to continue until:

CityData.cpp: In member function 'void CityData::Copy(CityData*)':
CityData.cpp:984: error: cast from 'uint32*' to 'uint32' loses precision
CityData.cpp:984: error: cast from 'PLAYER_INDEX*' to 'uint32' loses precision

This is also from trying to use memcpy. Which variables need to be copied this time?

[Martin Gühmann]

Originally posted by cap601
This is also from trying to use memcpy. Which variables need to be copied this time?

They are listed in the definition of CityData in CityData.h. The list starts with m_owner and ends with m_is_rioting.

- Martin

[cap601]

On doing that (and having to use -> instead of . in the assignments) I get the error:

CityData.cpp: In member function 'void CityData::Copy(CityData*)':
CityData.cpp:1052: error: ISO C++ forbids assignment of arrays
CityData.cpp:1053: error: ISO C++ forbids assignment of arrays

What's the best of legally copying the arrays (m_numSpecialists and m_specialistDBIndex for reference)?

[Martin Gühmann]

Originally posted by cap601
What's the best of legally copying the arrays (m_numSpecialists and m_specialistDBIndex for reference)?

Well I don't now whether it is the best method, but in this case you can use memcpy to copy the content of one array into another array.

Use google to figure out the details if your compiler doesn't come with a c++ documentation. You should also figure out what sizeof does.

-Martin

[Martin Gühmann]

So cap what is so difficult to enter into google some words like c++, sizeof, and memcpy?

-Martin

[lynx_abraxas]

I have tested RichardH merges and they are all fine except the removal of the typedefs for sint in ranches/linux/ctp2_code/gfx/gfx_utils/tiffutils.cpp in rev. 805. My tiffio.h isn't happy without them. Shall I put them back in?
Sadly the sprites still disappear with out any reason and always when moving from one tile to another.
I'm not sure though, if it is a good idea to include the changes that were made to trunk into the linux branch. Wouldn't it be better to merge the changes necessary for linux from branch into trunk? So that we one day might end up with just trunk that compiles under linux and win and all changes that are made are in for both OS unless they are OS specific. (So far I only found the basic graphics part (SDL), the inline assembly and the configuration to be specific for linux/gcc)

[Martin Gühmann]

Originally posted by lynx_abraxas
Wouldn't it be better to merge the changes necessary for linux from branch into trunk? So that we one day might end up with just trunk that compiles under linux and win and all changes that are made are in for both OS unless they are OS specific. (So far I only found the basic graphics part (SDL), the inline assembly and the configuration to be specific for linux/gcc)

Of course it would be better to merge the Linux changes into trunk, since we have no one who keeps the Linux branch up to date, which is a requirement to have separate branches.

- Martin

[cap601]

Sorry about not responding quicker but I've been having some problems with my Linux install and haven't spent much time looking at this.

I've done some googling and I think the problem is related to the fact that I'm using a 64bit OS/compiler. I've also looked at some fixes to the problem I've come across this (using bldque.cpp as an example) which compiles:

memcpy(&m_owner, &copy.m_owner, static_cast<uint32>(reinterpret_cast<unsigned long>(&m_wonderComplete)) + sizeof(m_wonderComplete) - static_cast<uint32>(reinterpret_cast<unsigned long>(&m_owner))); 

Is this a valid fix (it works for CityData.cpp as well)?

EDIT: In a different problem I've noticed that ./configure appears to be failing with:

=== configuring in ctp2_code/libs/anet (/home/josh/CTP2/source/ctp2_code/libs/anet)
configure: running /bin/bash ctp2_code/os/autoconf/config/configure '--prefix=/home/josh/CTP2/'  '--bindir=/home/josh/CTP2/ctp2_program/ctp/' --cache-file=/dev/null --srcdir=.
/bin/bash: ctp2_code/os/autoconf/config/configure: No such file or directory
configure: error: ctp2_code/os/autoconf/config/configure failed for ctp2_code/libs/anet

The directory (but not the file) does exist. Any ideas on how to fix this?

[Martin Gühmann]

Originally posted by cap601
Sorry about not responding quicker but I've been having some problems with my Linux install and haven't spent much time looking at this.

Well, in such a case I am not very patient, so that I thought you gave up. And that is a basic thing to do. Of course, I could tell you everything what you have to do, but them you would never do stuff on your own.

Originally posted by cap601
I've done some googling and I think the problem is related to the fact that I'm using a 64bit OS/compiler. I've also looked at some fixes to the problem I've come across this (using bldque.cpp as an example) which compiles:

memcpy(&m_owner, &copy.m_owner, static_cast<uint32>(reinterpret_cast<unsigned long>(&m_wonderComplete)) + sizeof(m_wonderComplete) - static_cast<uint32>(reinterpret_cast<unsigned long>(&m_owner))); 

Is this a valid fix (it works for CityData.cpp as well)?

If it works it is fine, but I have no idea why you needed the double cast. At least it looks ugly.

If you can do it depends on the length of unsigned long, if it has the same length than unsigned int than it is ok, but if not than I prefer the solution we headed before, by explicitly copying all the members of CityData and BuildQueue and using memcpy for the two remaining arrays.

Originally posted by cap601
EDIT: In a different problem I've noticed that ./configure appears to be failing with:

=== configuring in ctp2_code/libs/anet (/home/josh/CTP2/source/ctp2_code/libs/anet)
configure: running /bin/bash ctp2_code/os/autoconf/config/configure '--prefix=/home/josh/CTP2/'  '--bindir=/home/josh/CTP2/ctp2_program/ctp/' --cache-file=/dev/null --srcdir=.
/bin/bash: ctp2_code/os/autoconf/config/configure: No such file or directory
configure: error: ctp2_code/os/autoconf/config/configure failed for ctp2_code/libs/anet

The directory (but not the file) does exist. Any ideas on how to fix this?

Probably you can add to the directory an empty configure file, but actually I have no idea about that.

-Martin

[cap601]

On further experimentation it appears that the static_cast is unneeded so I don't believe there are any reasons to manually assign each member now. Googling suggests there are better ways that would work on 32 and 64 bit but I don't know enough about them to advocate their usage.

Creating a blank configure file in that directory doesn't help and the same error occurs. Attempting to compile regardless now fails at:

Library: DEBUG
make[4]: Entering directory `/home/josh/CTP2/source/ctp2_code/libs/anet/src/linux/dp/debug'
gcc -D_DEBUG -g -Werror -DUNIX -Dcdecl="" "-D__NO_ANONYMOUS_UNIONS__" "-DPACK=__attribute__ ((packed))" -Dstrnicmp=strncasecmp -Dstricmp=strcasecmp -Ddp_ANET2 -DCOMM_INST -I. -I../../../../h -I../../../aeh -I../../../../demo/utils -c ../../../dp/dprint.c -o dprint.o
../../../dp/dprint.c: In function ‘dp_dprintf’:
../../../dp/dprint.c:242: error: invalid initializer
make[4]: *** [dprint.o] Error 1
make[4]: Leaving directory `/home/josh/CTP2/source/ctp2_code/libs/anet/src/linux/dp/debug'
+ die
+ echo Build failed; ./build
Build failed; ./build
+ exit 1

The referenced code is:

    #ifdef	_M_ALPHA
	va_list argptr = { NULL , 0 };
    #else
	va_list argptr = NULL;  //Line 242
    #endif

If I change the code to that of the other part of the ifdef statement it still fails with:

../../../dp/dprint.c:242: warning: initialization makes integer from pointer without a cast

.

[lynx_abraxas]

[/CODE]

The referenced code is:

    #ifdef	_M_ALPHA
	va_list argptr = { NULL , 0 };
    #else
	va_list argptr = NULL;  //Line 242
    #endif

If I change the code to that of the other part of the ifdef statement it still fails with:

../../../dp/dprint.c:242: warning: initialization makes integer from pointer without a cast

. [/QUOTE]

Concerning anet I can remeber I had problems when I hadn't run make bootstrap before configure.

I have no programming experience with 64 bit architecture so far. But I'd say the very dirty way of storing integer values in void pointers to circumvent the need for more variables and direct casts could be bad with LP-64 when cast back to int. But as said I have no experience there!
To solve the warning one would need to know the structure of argptr or the definition of va_list.

My hope to find some time again to work on the port is slowly vanishing.
My motivation is down as well because the ported graphics part uses SDL although the guys from SDL told me GL would have been the better choice. (There is an unofficial SDL-GL mode, I didn't try so far) Anyway running linux-ctp2 in fullscreen mode on 1280x1024 is as slow as using wine and win-ctp2 for me As win-ctp2 has less bugs (eg. shows the units all the time) I tend to live with wine and win-ctp2 although I don't have time for playing either
Well who knows, perhaps the moment will come again that I get another challenge boost to get going again on porting this...