STLport version 5.2.1
Solaris 9 (SPARC) with Sun C++ 5.9 (Sun Studio 12)
Solaris 10 (SPARC) with Sun C++ 5.9 (Sun Studio 12)
Solaris 10 (SPARC) with Sun C++ 5.5 (Sun Studio 8)
STLport has two fundamental problems when trying to define the math functions in its own namespace:
1. It uses C math functions from the global namespace, but includes the new C headers, i.e. <cmath>, by default. This gives error messages like
"../../stlport/stl/_cmath.h", line 425: Error: fabs is not a member of file level.
because <cmath> of Sun C++ only declares functions in std.
2. It defines functions in the global namespace and imports them into its own namespace later. This conflicts with Solaris' <math.h> header which has "using std::abs;" etc. in the global namespace. If _STLP_NO_NEW_C_HEADERS is defined to get around the first problem, this second problem causes errors like
"../../stlport/stl/_cmath.h", line 432: Error: std::acos(float) already had a body defined.
These problems are not limited to _cmath.h. There are similar errors in other headers like _cstdlib.h.
A possible solution is rather simple: Don't define anything in the global namespace. Instead, define functions like abs(float) in STLport's own namespace, or import them there with "using". Headers like _cstdio.h already do that and don't cause any problems on Solaris. I've made a set of rather crude patches which ignore most STLport configuration macros, but solve the C header problems for me.
This solution has another advantage: Not defining any functions outside its own namespace means that it becomes easy to let STLport coexist with other STL libraries, even with other builds of STLport itself (provided that you hide the private _Locale* and _WLocale* functions in STLport's shared library interface).