FreeOrion for Debian - Build failures

[Apo]

Hi,

I would like to find out more about the current build failures of FreeOrion for several Debian supported architectures.

I understand that the target group for FreeOrion are users for amd/intel's 64bit pc architectures (called amd64 in Debian) and i386. However Debian supports several other architectures and in my opinion it wouldn't be bad for FreeOrion to be playable on popular architectures like ARM.

Here is a nice overview about all package related information for FreeOrion.

http://packages.qa.debian.org/f/freeorion.html

This is the current status of the build servers for FreeOrion

https://buildd.debian.org/status/packag ... perimental

and for unofficial Debian architectures

http://buildd.debian-ports.org/status/p ... perimental

FreeOrion builds fine on amd64, i386 and ia64 (Itanium). Except hurd-i386 and kfreebsd all architectures use the Linux kernel. Unfortunately FreeOrion cannot be built on hurd and kfreebsd because these architectures don't provide the required build-deps at the moment. It appears to me that libois-dev requires some Linux specific functions so that it is quite unlikely that FreeOrion will ever be ported to the FreeBSD or Hurd kernel. But i might be wrong of course.

The other architectures fail because of

FreeOrion/GG/GG/adobe/any_regular.hpp:689:5: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>'

or in case of s390x

FreeOrion/util/Serialize.ipp:21:4: error: #error "Incompatible endianness for binary serialization."

In the first case i am not sure whether this is caused by Debian's boost transition (we are using boost1.49 at the moment and migrate to boost1.53 right now). A part of the problem might be the different endianess of the different architectures. In what extent are other architectures for FreeOrion supported and do you even intend to make FreeOrion work on every possible system available?

I'm curious to learn more about it

Cheers
Markus

[Geoff the Medio]

It appears to me that libois-dev requires some Linux specific functions...

If those are used in the keyboard or mouse portions, then that's a problem, but if it's elsewhere, they're not needed for FreeOrion and a custom build of OIS might be possible. I can't find anything useful about a BSD port of OIS by googling.

FreeOrion/GG/GG/adobe/any_regular.hpp:689:5: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>'

As far as I can tell, the any_regular stuff is only used in the GG Adam/Eve code, which isn't needed for FreeOrion. adrian_broher has posted some patches recently that make it easier to exclude this code when building FreeOrion, and regardless, it should be possible to omit it all when building GG.

FreeOrion/util/Serialize.ipp:21:4: error: #error "Incompatible endianness for binary serialization."

You could try just omitting that assert. The point of it was to allow serialization between OSes, but that's likely not working anyway. If it's just to (de)serialize on the same system, it probably doesn't matter or need those asserts to pass, although I don't know that for sure.

There is also an option for serialization to text archives, which are slower and larger, but shouldn't care about endianness. Set FREEORION_BINARY_SERIALIZATION to 0 in Serialize.h.

In what extent are other architectures for FreeOrion supported and do you even intend to make FreeOrion work on every possible system available?

I'd like it to work on as many systems as possible, but unless someone who knows what they're doing can provide patches, it won't happen on its own.

[adrian_broher]

As far as I can tell, the any_regular stuff is only used in the GG Adam/Eve code, which isn't needed for FreeOrion. adrian_broher has posted some patches recently that make it easier to exclude this code when building FreeOrion, and regardless, it should be possible to omit it all when building GG.

I'm a bit more pessimistic about that because I don't know if adobe::name_t uses those headers.

[Geoff the Medio]

...I don't know if adobe::name_t uses [any_regular] headers.

As far as I can tell it doesn't. I can build name.cpp after renaming GG\adobeany_regular.hpp and GG\adobeany_regular_fwd.hpp.

[adrian_broher]

As far as I can tell it doesn't.

Seems like you're right with that:

Code: Select all

$ g++ -I GG/ -M GG/src/adobe/memory.cpp | grep any_regular

$ g++ -I GG/ -M GG/src/adobe/name.cpp | grep any_regular

$ g++ -I GG/ -M GG/src/adobe/string_pool.cpp | grep any_regular

So that could be possibly fixed with the next release.

[Geoff the Medio]

So that could be possibly fixed with the next release.

Presumably your recently-posted patches that make adam/eve stuff optional and default off for FO GG builds would suffice? I'm hoping Naglium will report on testing them, but he's not been responsive in the last week or so.

Or was there something else that you mean by "fixed"?

[adrian_broher]

Presumably your recently-posted patches that make adam/eve stuff optional and default off for FO GG builds would suffice?

Yes, that's what I meant. The patches would suffice to fix this issue and I assume that they are in the repository before the next release.

[Apo]

Yes, that's what I meant. The patches would suffice to fix this issue and I assume that they are in the repository before the next release.

I assume you refer to your patch in this forum post?

viewtopic.php?f=9&t=7528

I think i can test it for our next upload. Unfortunately it might take a few weeks until then.

Thanks for the hints with the serialization issue. Needs more testing on my side now and access to the build servers in question.

[adrian_broher]

I assume you refer to your patch in this forum post?

viewtopic.php?f=9&t=7528

I think i can test it for our next upload. Unfortunately it might take a few weeks until then.

Yes, that's the patch I was talking about. I doubt you can just use it like this. The cmake build system was changed significantly between 5771 and trunk (6138). But you can use it to work out your own patch.

[Apo]

FreeOrion 0.4.3 is now in Debian unstable and I wanted to provide some feedback for this topic again.

Build status for supported architectures:

https://buildd.debian.org/status/packag ... =freeorion

Build status for unsupported architectures:

http://buildd.debian-ports.org/status/p ... &suite=sid

The good news is that FreeOrion builds on more architectures now because I ommitted the endianess and size checks as suggested by Geoff the Medio. This allows FreeOrion to build on s390x, powerpc64, alpha and probably powerpcspe too. I am attaching the applied patch for this issue in Debian. Perhaps you might consider including it.

The bad news is that FreeOrion still fails to build on a couple of other architectures. The error is triggered by

http://sources.debian.net/src/freeorion ... egular.hpp

at line 689

Code: Select all

#ifndef ADOBE_NO_DOCUMENTATION
    BOOST_STATIC_ASSERT((sizeof(any_regular_t) == 16 + sizeof(void*)));
#endif

Apparently Adrian's patch didn't solve this issue. Would it be safe to omit these lines or are there smarter ways to handle this assertion for different architectures?

The last remaining issue is specific to GNU/Hurd and GNU/FreeBSD operating systems. It seems ois hasn't been ported to these architectures yet. I presume I could omit the problematic build dependency libois-dev but I'm not so sure about the consequences. Probably FreeOrion would be still uncompilable or the game would be unusable. I think I wouldn't do those users any favor with such a change but perhaps there are some more experienced FreeBSD users around who could point me in the right direction.

[Geoff the Medio]

Code: Select all

#ifndef ADOBE_NO_DOCUMENTATION
    BOOST_STATIC_ASSERT((sizeof(any_regular_t) == 16 + sizeof(void*)));
#endif

Would it be safe to omit these lines or are there smarter ways to handle this assertion for different architectures?

I have no idea what that assert is testing or why it's necessary. Given that it's wrapped in an preprocessor check for a documentation define, it's plausible that it's not actually needed.

The last remaining issue is specific to GNU/Hurd and GNU/FreeBSD operating systems. It seems ois hasn't been ported to these architectures yet. I presume I could omit the problematic build dependency libois-dev but I'm not so sure about the consequences. Probably FreeOrion would be still uncompilable or the game would be unusable.

Probably various preprocessor blocks would be needed to exclude the uses of OIS from client code. After that was done, there would probably be no usable form of input from the keyboard or mouse.

[Apo]

Code: Select all

#ifndef ADOBE_NO_DOCUMENTATION
    BOOST_STATIC_ASSERT((sizeof(any_regular_t) == 16 + sizeof(void*)));
#endif

Would it be safe to omit these lines or are there smarter ways to handle this assertion for different architectures?

I have no idea what that assert is testing or why it's necessary. Given that it's wrapped in an preprocessor check for a documentation define, it's plausible that it's not actually needed.

The last remaining issue is specific to GNU/Hurd and GNU/FreeBSD operating systems. It seems ois hasn't been ported to these architectures yet. I presume I could omit the problematic build dependency libois-dev but I'm not so sure about the consequences. Probably FreeOrion would be still uncompilable or the game would be unusable.

Probably various preprocessor blocks would be needed to exclude the uses of OIS from client code. After that was done, there would probably be no usable form of input from the keyboard or mouse.

Ok, then I will omit this documentation check too in the future, let's see what happens.

I had a look at the OIS project at sourceforge and it seems they are not really interested in porting OIS to *BSD.

http://sourceforge.net/p/wgois/feature-requests/13/

This feature request is almost three years old and it got no reply. Unless someone else, who has more experience with *BSD, can actually play FreeOrion on such a system, I'm quite reluctant to exclude those code blocks just for the sake of compiling the game.

[Geoff the Medio]

After seeing some bug / patch posts on the tracker,

https://sourceforge.net/p/freeorion/bugs/545/
https://sourceforge.net/p/freeorion/bugs/546/

I'll commit some changes to exclude the problematic asserts in the serialization and any_regular code.

[Apo]

After seeing some bug / patch posts on the tracker,

https://sourceforge.net/p/freeorion/bugs/545/
https://sourceforge.net/p/freeorion/bugs/546/

I'll commit some changes to exclude the problematic asserts in the serialization and any_regular code.

Thanks for applying my patches.

[Geoff the Medio]

Thanks for applying my patches.

Thanks for submitting. In future, it would be preferable to use the forum for patch submission, and post about it to remind if they're missed for a week or two.