[C++-sig] Re: STLPort problems
mike.thompson at day8.com.au
Fri Aug 29 10:20:10 CEST 2003
"Mike Thompson" <mike.thompson at day8.com.au> wrote in message
news:biml94$f9q$1 at sea.gmane.org...
> "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
> 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
> clean compile.
> Here's what I had to do:
> 1. python\src\converter\builtin_converters.hpp
> I had to add a new #define for LONG_LONG at line 106. Code now
> like this:
> // using Python's macro instead of Boost's - we don't seem
> get the
> // config right all the time.
> # ifdef HAVE_LONG_LONG
> #define LONG_LONG PY_LONG_LONG
> <------ ADDED THIS LINE ------------
> BOOST_PYTHON_TO_PYTHON_BY_VALUE(signed LONG_LONG,
> BOOST_PYTHON_TO_PYTHON_BY_VALUE(unsigned LONG_LONG,
> # endif
> 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
> LONG_LONG using
> Python's concept of long long from the same PyConfig.h. I have no
> idea if that's correct and general.
> 2. python\src\object\enum.cpp
> Under VC6 and STLport, fprintf() ends up in the global namespace,
> line 48 becomes:
> fprintf(fp, text);
> instead of:
> BOOST_CSTD_::fprintf(fp, text);
> 3. python\src\object\function.cpp
> Under VC6 and STLport, strcmp() ends up in the global namespace, so
> line 20 becomes:
> return strcmp(x,y) < 0;
> instead of:
> return BOOST_CSTD_::strcmp(x,y) < 0;
> Hacks 2 and 3 above are obviously not general solutions, but I'd be very
> to test any changes you want to make to CVS HEAD.
1. There is a new beta release of SLTport - version 4.5-0725. Its not shown
home page but its announced and is available at
now using this version.
2. Ignore hack #1 above. I was, in fact, working with boost 1.30.2 when I
changes and when I realised this and went to work with overnight cvs, I
problem had already been fixed.
3. Problems 2 and 3 arise because I've choosen to use STLport with the
I.e. I've got the following major configuration switch set (in
#define _STLP_NO_OWN_IOSTREAMS 1
When I disable this switch (and use STLport's iostream implementation)
then no compilation
problems at all. Everything is fine.
However, if I use native (VC6) iostream and STLPort then I get problems
2 and 3 described
before PLUS some new compilation erros because I'm now actually using
boost HEAD (and
These new compilation problems all relate to the used of 'complex' and
that its in std.
I'll detail them soon. I just wanted to write a quick update before
dinner, just in case anyone
spend any time on this.
More information about the Cplusplus-sig