Well, I think I have solved it.
The cause of the issue is two fold. There is a code bug, same_vert was decorated inline at its definition. But same_vert is declared in the header and because the inline definition of the function is not in the header, when the compiler actually decided to follow the directive, the function same_vert is not available outside of its declared compilation unit (2d.cpp).
The reason that this was never noticed is that our building recommendations are actually that you not use -O because it causes various runtime issues.
So the there are two solutions to the problem:
1) I have attached a patch which moves the offending function to where it should be so that inlining will work correctly.
2) Don't compile FSO with any -O option set (which will mean that you have to modify the ebuild to filter out -O from your portage settings).
Personally I would just suggest going with number 2. But there have been previous anecdotes of -O2 and -O3 actually working and not causing the engine to screwup, so if you do decide to go with option 1, we would be interested in your experience. But keep in mind, if we find that you are having inexplicable problems removing -O options will be the first thing that we ask you to do.
Also for the record, using that ebuild, your log will be in $HOME/.tbp_fso/data.
Hopefully, this will allow us to get on with figuring out why you are having strange errors (though the -O setting could be part of the problem for 3.6.10 from the start).
Also, I noticed that our autogen.sh supposedly supports not running configure, but I haven't been able to figure out how to invoke is so, I have also attached a patch that fixes that as well. To make autogen.sh not run configure, invoke it with --noconfigure as the first parameter.
Edit: I was being a dummy. Call autogen.sh as NOCONFIGURE=1 ./autogen.sh to not run configure.
[attachment deleted by admin]