[C++-sig] Re: STLPort problems
mike.thompson at day8.com.au
Fri Aug 29 06:36:44 CEST 2003
"David Abrahams" <dave at boost-consulting.com> wrote in message
news:uhe41n8xh.fsf at boost-consulting.com...
> "Mike Thompson" <mike.thompson at day8.com.au> writes:
> > To get around the problem, I have tried overnight cvs and I've also tried
> > the VC6 projects supplied in the distribution. Exactly the same problem
> > time. No difference.
> > The compile errors occurs on some, but not all, files.
> I believe this is an stlport bug. Have you tried with the
> stlport-0119 "beta"? Boris recommends that one.
Okay, I've download STLport-4.5-0119 and while it takes away the first (tan()
and tanh() issues), there are still other problems.
I've made some adjustments to the overnight cvs HEAD of boost, so I can get a
Here's what I had to do:
I had to add a new #define for LONG_LONG at line 106. Code now looks
// using Python's macro instead of Boost's - we don't seem to
// config right all the time.
# ifdef HAVE_LONG_LONG
#define LONG_LONG PY_LONG_LONG //
<------ ADDED THIS LINE ------------
The missing definition of LONG_LONG caused compile time errors in
builtin_converters.cpp at lines 174 and 353.
Because HAVE_LONG_LONG is defined in PyConfig.h, I've defined
Python's concept of long long from the same PyConfig.h. I have no
idea if that's correct and general.
Under VC6 and STLport, fprintf() ends up in the global namespace, so
line 48 becomes:
Under VC6 and STLport, strcmp() ends up in the global namespace, so
line 20 becomes:
return strcmp(x,y) < 0;
return BOOST_CSTD_::strcmp(x,y) < 0;
Hacks 2 and 3 above are obviously not general solutions, but I'd be very happy
to test any changes you want to make to CVS HEAD.
I'm now going to figure out how to run the unit tests, to check if I've broken
More information about the Cplusplus-sig