Armagetron 0.2.8.3.3 fails to build from source with GCC-6

What do you want to see in Armagetron soon? Any new feature ideas? Let's ponder these ground breaking ideas...
Post Reply
Apo
Posts: 8
Joined: Fri Aug 29, 2014 12:07 pm

Armagetron 0.2.8.3.3 fails to build from source with GCC-6

Post by Apo »

Hi all,

I'm currently working on

https://bugs.debian.org/812293

The game fails to build from source with GCC-6 but builds fine with GCC-5. I use the latest stable release 0.2.8.3.3.

Code: Select all

> libtron.a(libtron_a-gCycle.o): In function `tOutput::tOutput<tColoredString, tColoredString>(char const*, tColoredString const&, tColoredString const&)':
> /<<PKGBUILDDIR>>/client/src/../../src/tools/tLocale.h:128: undefined reference to `tOutput::operator<<(tOutput const&)'
> /<<PKGBUILDDIR>>/client/src/../../src/tools/tLocale.h:128: undefined reference to `tOutput::operator<<(tOutput const&)'
> libtron.a(libtron_a-gCycle.o): In function `tOutput::tOutput<tColoredString>(char const*, tColoredString const&)':
> /<<PKGBUILDDIR>>/client/src/../../src/tools/tLocale.h:116: undefined reference to `tOutput::operator<<(tOutput const&)'
> libtron.a(libtron_a-gGame.o): In function `tOutput::tOutput<tString, int>(char const*, tString const&, int const&)':
> /<<PKGBUILDDIR>>/client/src/../../src/tools/tLocale.h:128: undefined reference to `tOutput::operator<<(tOutput const&)'
> libtron.a(libtron_a-gGame.o): In function `tOutput::tOutput<tString>(char const*, tString const&)':
> /<<PKGBUILDDIR>>/client/src/../../src/tools/tLocale.h:116: undefined reference to `tOutput::operator<<(tOutput const&)'
> libtron.a(libtron_a-gGame.o):/<<PKGBUILDDIR>>/client/src/../../src/tools/tLocale.h:116: more undefined references to `tOutput::operator<<(tOutput const&)' follow
> collect2: error: ld returned 1 exit status
> Makefile:813: recipe for target 'armagetronad_main' failed
Since it fails at line 116 and 128

*this << identifier;

it might be related to this change "Optimizations remove null pointer checks for this" explained at

https://gcc.gnu.org/gcc-6/changes.html
https://gcc.gnu.org/gcc-6/porting_to.html

Any ideas how to solve this issue?

User avatar
Z-Man
God & Project Admin
Posts: 11427
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: Armagetron 0.2.8.3.3 fails to build from source with GCC

Post by Z-Man »

Seems to be a wonky template instantiation problem, I bet it's our fault and not GCCs. The missing function is private and not implemented on purpose, earlier GCCs apparently don't use it. I don't exactly know why not :) What appears to be happening with earlier GCCs is that
tOutput::operator<<(char *) gets converted to tOutput::operator<<(tOutput(char *))
and of that operator<<, a templated version is picked, not the nonexisting one. It's a lot of useless conversions, I'll try to get rid of them and post a patch. May be a couple of days.

User avatar
Z-Man
God & Project Admin
Posts: 11427
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: Armagetron 0.2.8.3.3 fails to build from source with GCC

Post by Z-Man »

Here you go. I have not tested this with gcc 6, I don't have the resources to run that at hand right now. But this patch removes the declaration of the non-implemented function, so at the very least, it should turn the errors from linker errors to compiler errors and make them easier to digest.
It also replaces the call to the overloaded, templated operator implemented sometimes as member operator and sometimes as static operator (who knows which version gets called? Not me, apparently) with a call to a simple, named member function that does the job the call was supposed to do without any overload ambiguity. So I'm reasonably sure it should remove the error entirely.

So, Pro Tip 1: Don't write code where you have no bloody clue what it's actually going to do.
Corollary Pro Tip 1: Don't mix different modes on how to declare operator overloads.
Corollary Pro Tip 2: Don't implement overloaded operators in terms of each other. Implement them in terms of regular member functions.

Implicit conversions were also in the mix here and not having them would have uncovered the problem sooner, but I quite like them here, they make life a lot easier all around the place.
Attachments
armagetronad-0.2.8.3.3-gcc6.patch.gz
Gzipped patch. Apply with -p0.
(731 Bytes) Downloaded 89 times

User avatar
assaindan
Average Program
Posts: 59
Joined: Sat Nov 06, 2010 6:09 pm
Location: Mass, USA

Re: Armagetron 0.2.8.3.3 fails to build from source with GCC

Post by assaindan »

Is this, in non technical language, why i cannot get online? havent played in months just got a pc, and it wont run. Tried downloading that new link infamous Zman posted, but it says my computer cannot run that program? huh, missing my tronner family

User avatar
Light
Reverse Outside Corner Grinder
Posts: 1664
Joined: Thu Oct 20, 2011 2:11 pm

Re: Armagetron 0.2.8.3.3 fails to build from source with GCC

Post by Light »

assaindan wrote:Is this, in non technical language, why i cannot get online? havent played in months just got a pc, and it wont run. Tried downloading that new link infamous Zman posted, but it says my computer cannot run that program? huh, missing my tronner family
The link he just posted is a patch for the source. Try here:
http://lightron.org/#Download

Apo
Posts: 8
Joined: Fri Aug 29, 2014 12:07 pm

Re: Armagetron 0.2.8.3.3 fails to build from source with GCC

Post by Apo »

Thanks a lot Z-Man. Your patch works perfectly.

Cheers

User avatar
Z-Man
God & Project Admin
Posts: 11427
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: Armagetron 0.2.8.3.3 fails to build from source with GCC

Post by Z-Man »

It's not enough :( Release builds from the 0.2.8 and 0.4 were crashing with gcc 6, I fixed those up. I was relying on undefined behavior based on me "Knowing Too Much". References are just syntax dressing for pointers, right? "this" is just a regular pointer, right? So while it's legally so that they're not allowed to be NULL, they can be and you can test them for NULL just like a regular pointer to bail out of functions that would otherwise access memory around NULL and crash is totally fine, right?

Well, of course, WRONG. The optimizer is allowed to assume you're not doing anything illegal (resulting in unspecified behavior), because whatever goes wrong if you assume that, it's unspecified. So it merrily optimizes away any if(this) and if (&reference) tests, they can never be false. We had a couple of those, at least one path resulting in real crashes as soon as you enter a network game. It also warns about those tests now, which is nice.

Ergh. I guess we need to do 0.2.8.3.4 with those fixes. Source and PPA only, maybe, it's not like the previous binaries broke...

OR we could save some time and just call it 0.2.8.3.3~ppa2 for the PPA.

OR we could decide to turn the current state of 0.2.8 into the relase 0.2.9 it never was meant to be; after all, I think we did a good job of keeping it in a release ready state.

User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: Armagetron 0.2.8.3.3 fails to build from source with GCC

Post by Lucifer »

Z-Man wrote:OR we could decide to turn the current state of 0.2.8 into the relase 0.2.9 it never was meant to be; after all, I think we did a good job of keeping it in a release ready state.
This would be my choice. Throw a beta out and sit on it for a few months, release around Christmas (or after, during the slow post-holiday period).
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

User avatar
Z-Man
God & Project Admin
Posts: 11427
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: Armagetron 0.2.8.3.3 fails to build from source with GCC

Post by Z-Man »

Yeah, lets do that. That'll only do the people stuck with a gcc 6 system and unwilling to install betas good in a couple of months, though. So we do need to push out a reasonably quick update anyway. Working on it. Decided to go with a full 0.2.8.3.4 because that's actually the lazy way here. In case updates are required, patching patches in a frankenbuild environment is not my idea of fun. This way, I can just merrily hack away on the still healthy 0.2.8.3 svn branch. Plus, it's the proper process, and I'm German.

Post Reply