2010/1/6 Marc <marc.gli...@gmail.com>: > On 5 jan, 16:21, Bill Hart <goodwillh...@googlemail.com> wrote: >> David Kirkby reported a bug on Solaris related to using stlport4 which >> is a newer version of their library. It's our trac ticket #272. > > That one is because mpir, in cxx/osdoprnti.cc, includes <cstdarg>, > which provides std::va_list, whereas it uses va_list. The easiest fix > is to include <stdarg.h> instead. >
Thanks. David Kirkby and I did sort this one out ok. >> A few days ago, whilst investigating this, I found the following from >> Marc Glisse on the gmp mailing list which seems to be a comment >> directed at us.... >> >> http://gmplib.org/list-archives/gmp-bugs/2009-February/001273.html >> >> "Note that such a workaround should test that >> _RWSTD_NO_TEMPLATE_ON_RETURN_TYPE is defined (hello MPIR...)." >> >> I'll add a trac ticket for this and we'll have to figure out what the >> hell he's talking about (unless he happens to be reading). > > Hmm, that's a bit old... The old standard library that comes with > sunpro can't handle some of the code, so mpir introduced a workaround. > If that is the case, it is strange that the workaround is not enabled > only when using sunpro with the old library, but whenever __sun is > defined (which basically means solaris). Ah, OK. Yes, I just assumed it was the sun compiler in general which didn't know about these extensions. > Now, the support of locales > in stlport4 or in libstdc++ (ie g++) on solaris is actually quite bad > (even though it compiles the code), so the workaround may still be a > good thing for those 2 cases as well (but for different reasons). Ok. > The > macro I mention is the one that tests precisely whether we are using a > version of roguewave where use_facet has a non-standard api (and thus > the regular code fails to compile). > Ah, I see. > While I am here, let me mention that opensolaris now uses stdcxx (from > Apache) as its C++ standard library (for kde for instance), which > behaves much better. So, it should compile all the original code without workarounds, presumably. > > Also, not too old sunpro (as any standard C99 compiler) could use > #define __GMP_EXTERN_INLINE inline. Yes, that is a longstanding and old issue for us. We definitely should fix this one. Thanks. Bill.
-- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
