./configure --enable-cxx still a disaster on Solaris

[Dennis Clarke]

> On Mon, 23 Mar 2009, Torbjorn Granlund wrote:
>
>> I don't think this is a problem with Solaris, but with Sun's C++
>> compiler.  Or do you have problems also when compiling with the C++
>> compiler from the GNU Compiler Collection?
>
> I think it is currently ok, but you could have some std:: issues in the
> future if someone cleans up gcc (though as I am almost the only one
> interested and I don't have time now, this is not so likely to happen).
>
>> I am not an expert on C++, but C++ experts have determined in the past
>> that Sun's compiler is just too old and too buggy to compile GMP.  They
>> gave up trying to find some syntax for gmpxx.h that would be tolerated
>> by Sun's compiler.
>
> Actually, since the removal of the ternary operators, there is nothing too
> hard for the compiler left, and many people have made it work just fine.
>
> There is also an issue with __attribute__((const)) which is understood by
> the C compiler and crashes the C++ one, but this was supposedly fixed in
> the latest express release of the compiler. However, if you are in
> autoconf hacking mood, you might want to fix the fact that autoconf tests
> the C compiler and uses the results for the C++ compiler as well.
>
>> If we can come up with a reasonable workaround, I'd like to support
>> Sun's C++ compiler.  By "reasonable" I mean that it should not make
>> gmpxx.h much more complex, and not cause performance degradation.
>
> Sun's C++ compiler can use several different standard library
> implementations. With a good one (stlport4 or apache) I think the only
> issue is that gmp.h (and maybe a few other files) uses size_t and va_list,
> whereas it includes cstddef and cstdarg which only provide std::size_t and
> std::va_list (stddef.h and stdarg.h would work). With the old library
> (Cstd) that is kept for backwards compatibility, one also needs to modify
> the facet code a bit: in a couple places in cxx/*.cc, an ugly ifdef
> _RWSTD_NO_TEMPLATE_ON_RETURN_TYPE (or some autoconf test) to add an extra
> argument to the function call. Nothing touches gmpxx.h :-)
>
> Sun's compiler runs on linux and the facet problem can be tested there,
> but the std:: problem can only be tested on solaris and is only visible
> with some libraries (stlport4, not Cstd).
>

Just a quick response. I have been using stlport4 with Sun Studio and I
can tell you that I was able to get a clean build and all tests pass with
a very very old Sun Studio 8 on Sparc sun4m hardware. This is a very old
baseline test and my thought was that if it works there, it will work
anywhere.

I was wrong.

When I tried to do a compile on Sun Sparc v9 hardware ( again Solaris 8 )
with Sun Studio 11 I ran into a pile of problems. This is in spite of the
fact that this very same patched code ( your patches by the way, at least
most of them were ) works on older hardware with an older Sun Studio
compiler.

See :

 http://www.blastwave.org/dclarke/libgmp/SunOS_5.8_Studio_8_patches.txt

Please pardon the extra blank line in gmpxx.h. I went through every file,
and in the case of gmpxx.h I must have hit enter/return accidentally.

---- gmp-4.2.4/gmpxx.h
1350a1351
>

Regardless, this code compiles on Solaris 8 with Sun Studio 8 and fails on
Sparc v9 with Studio 11 and Studio 12. This really bothered me.

If I drop the --enable-cxx from the configure line then everything goes
smoothly until I try *any* optimization flag. If I try any optimization
with Studio 12 then the compiler fails and that is a clear compiler bug.

It all feels as if there is a bit of code fixing that can be done and we
would have a common codebase that compiles and runs well everywhere. Would
that not be the optimal situation for everyone ? [1]

-- 
Dennis Clarke
sig du jour : "An appeaser is one who feeds a crocodile, hoping it will
eat him last.", Winston Churchill

[1] silly question, I know.