GCC 3.4.2 and all that; overhaul the build system!

OpenTNL has severe problems compiling with GCC 3.4.2 (and, presumably, above). Use of the "-fpermissive" flag is necessary to get the compiler to accept tnlVector.h:

In file included from tnlUDP.h:35,
                 from tnl.h:51,
                 from assert.cpp:27:
tnlVector.h: In member function 'T& TNL::Vector<T>::front()':
tnlVector.h:301: error: there are no arguments to 'begin' that depend on a template parameter, so a declaration of 'begin' must be available
tnlVector.h:301: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
tnlVector.h: In member function 'const T& TNL::Vector<T>::front() const':
tnlVector.h:306: error: there are no arguments to 'begin' that depend on a template parameter, so a declaration of 'begin' must be available
tnlVector.h: In member function 'T& TNL::Vector<T>::back()':
tnlVector.h:311: error: there are no arguments to 'end' that depend on a template parameter, so a declaration of 'end' must be available
tnlVector.h: In member function 'const T& TNL::Vector<T>::back() const':
tnlVector.h:316: error: there are no arguments to 'end' that depend on a template parameter, so a declaration of 'end' must be available
make[1]: *** [assert.o] Error 1
make: *** [default] Error 2

Adding -fpermissive to the CFLAGS in necessary Makefiles gets past this.

We then have a virtual member function being initialised to NULL, where GCC wants zero:

In file included from tnlNetObject.h:39,
                 from tnlNetInterface.h:41,
                 from eventConnection.cpp:31:
tnlRPC.h: At global scope:
tnlRPC.h:167: error: expected '0' before ""
tnlRPC.h:167: error: invalid initializer for virtual method 'virtual bool TNL::RPCEvent::checkClassType(TNL::Object*)'
tnlRPC.h:167: error: expected ';' before ""

Changing the NULL on line 167 to 0 fixes this, and AFAIK is no different functionally. (I'm primarily self-taught, and have never thought initialising virtual functions to anything other than zero was correct; I wonder where this was picked up...)

Then there's the issue of the seemingly unnecessary Platform::checkHeap() function in platform.cpp. This is only defined on Windows, and compilation doesn't seem to suffer if it is simply removed entirely!

Having compiled tnl, there are then countless errors in libtomcrypt, ALL seemingly due to using the wrong syntax for including headers. Putting "-I./" in CFLAGS is unnecessary, and all local header files - i.e. those in the libtomcrypt source directory - should use

#include "header.h"

rather than

#include <header.h>

The latter is more correct and, quite simply, works.

I'm trying to compile using the latest MinGW, and had to make the above changes before I got anywhere. I've now run up against linker errors, which at first glance look like they're due to not linking against winsock libraries. I *would* go further and try to submit these changes to CVS, but the "Joint Copyright Assignment" you have to fill in before contributing has gone AWOL! Try the links on this page to see what I mean: opentnl.org/contribute.php

If this library aims at true cross-platform compatibility, these updates need to be made, and I'd also suggest switching to an Automake/conf build system for UNIXish platforms. This would make adding official support for MinGW on Windows fairly trivial, and does not preclude having additional make or project files for compilers such as Visual C/C++. I've just started writing a framework for a new game, two goals of which are to run on at least Windows and Linux and to use open-source development tools and libraries; OpenTNL sounds perfect for the network layer in principle, but in reality, it needs some maintenance work. Which I'd happily offer to do, if I had more spare time, and could sign the necessary agreement for contribution!