[C++-sig] Re: STLPort problems

[Mike Thompson]

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:usmnkeirs.fsf at boost-consulting.com...
> "Mike Thompson" <mike.thompson at day8.com.au> writes:
>
> > "Mike Thompson" wrote:
> >> I'm getting compile time errors when building Boost.Python
> >> using STLport.
> >>
> >
> > Okay.  After far too long, this all seems to be down to two isses:
> >
> >      1.  A problem with Python2.3 and Boost 1.30.2 which now appears
> >           fixed in cvs HEAD.  See my previous posts for details of the
> >           missing #define for LONG_LONG.
> >
> >      2.  As suggested by David, there is an STLport bug.  Its been around
> >           for a while but has not been fixed in the latest beta snapshots.
> >           I've raised the following bug report as a further prompter:
> >                       http://www.stlport.com/dcforum/DCForumID6/1364.html
> >
> >           NB: The bug is ONLY triggered when  you use STLport with the
"I'll
> > use
> >           native iostream library" switch on STLport.
>
> Mike,
>
> STLPort "native iostreams" are a hack, and I'm inclined not to support
> them.  Lots of subtle things don't work right because you can't make
> the fact that they're in a different namespace truly invisible.  If
> there's a small patch needed to get your stuff going, and you post it,
> I'll probably be willing to apply it.  Can you use STLPort iostreams
> instead?
>

I can't see any quick patch which might get STLport "native iostreams" working
with Boost.Python.  A broken <complex> in STLport breaks a bit too much of
boost, and fixing <complex> doesn't look easy.

I'll now investigate using STLPort iostreams instead.

Many thanks.

P.S. If its not supported -- and I can now see why -- I wonder if Boost.Python
should produce an #error if someone (like me) tries to go down the "native
iostreams" path?

--
Mike