Just a short note to report that libxslt 1.1.6 builds without problem on Solaris
using the Sun ONE Studio 7 compiler, with just one warning:

 cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../libxslt -I../libexslt -I..
-I../libxslt -I../libexslt -I/usr/local/libxml2/include/libxml2 -O -O -c date.c
 -KPIC -DPIC -o .libs/date.o
"date.c", line 748: warning: implicit function declaration: localtime_r

This bug was already present in libxslt 1.1.5:
	http://bugzilla.gnome.org/show_bug.cgi?id=138095

I had written the warning could be caused by a missing <time.h> in date.c, but
it's a bit more complicated than that. File date.c does include <time.h>:
	#ifdef HAVE_TIME_H
	#include <time.h>
	#endif
after including "config.h":
	#if defined(WIN32) && [...]
	[...]
	#else
	#include "config.h"
	#endif
which does define HAVE_TIME_H:
	/* Define to 1 if you have the <time.h> header file. */
	#define HAVE_TIME_H 1

The problem is that unlike GNU systems, Unix systems don't always "export" newer
APIs by default, for compatibility reasons. On Solaris /usr/include/time.h looks
like:
	#if	defined(__EXTENSIONS__) || defined(_REENTRANT) || \
		    (_POSIX_C_SOURCE - 0 >= 199506L)
	extern struct tm *gmtime_r(const time_t *, struct tm *);
	extern struct tm *localtime_r(const time_t *, struct tm *);
	#endif	/* defined(__EXTENSIONS__) || defined(_REENTRANT) .. */

As far as I can tell, the idea here is that you don't need localtime_r if you
don't write threaded programs that are supposed to define _REENTRANT or
_POSIX_C_SOURCE. Of course that's stupid since libraries should use localtime_r
even when they're not threaded themselves, because they may be later used in a
threaded program.

Anyway, I see no solution apart from defining __EXTENSIONS__ which is fairly
standard on Solaris if you want to use the latest APIs without caring about
compatibility. I'm not sure whether __EXTENSIONS__ should be defined in config.h
or Makefile. Both should work, it's a question of taste and consistency.