"The best way to predict the future is to invent it." -- Alan Kay
Believe it or not, this is on purpose. It means that, somehow, maybe indirectly, you are using an interface that has been marked as "unstable". So you have two options: either you avoid using interfaces marked as unstable, or you can agree to take the risk. To do the latter, you just have to define a UNSTABLE pre-processor symbol, this will allow your program to compile.
This is so you do not use an unstable interface in a program meant to be stable, by accident or otherwise.
XPLC's module loader tries to load every file the given directory, which for the test suite is the "tests" subdirectory. It seems that some dynamic loader crash on some conditions, most notable when attempting to load an executable.
A recent GCC version fixed a long-standing bug that XPLC was working around, but the workaround is incompatible with the fix. This is fixed in the current version of XPLC.
I have not yet figured out the proper options to link shared objects on Solaris. This is fixed in the current version of XPLC.
Darwin and Mac OS X does not seem to support weak symbols. This is fixed in the current version of XPLC.
This function is non-standard, but available on most platforms. On Windows, it is available as _snprintf, so you can either define a pre-processor symbol to do the correction (the VC++ 7 configuration file does this), or change the source code.
This is fixed in the current version of XPLC.