[C++-sig] Re: STLPort problems

Mike Thompson 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
> using
> > > the VC6 projects supplied in the distribution.  Exactly the same problem
> each
> > > 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
> 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
looks
> like this:
>                  // using Python's macro instead of Boost's - we don't seem
to
> 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,
> PyLong_FromLongLong(x))
>                  BOOST_PYTHON_TO_PYTHON_BY_VALUE(unsigned LONG_LONG,
> PyLong_FromUnsignedLongLong(x))
>                  # 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,
so
> 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
happy
> to test any changes you want to make to CVS HEAD.
>

More information:

1.   There is a new beta release of SLTport - version 4.5-0725.  Its not shown
on their
       home page but its announced and is available at
http://www.stlport.com/beta/  I'm
       now using this version.

2.    Ignore hack #1 above.   I was, in fact, working with boost 1.30.2 when I
made these
       changes and when I realised this and went to work with overnight cvs, I
found this
       problem had already been fixed.

3.    Problems 2 and 3 arise because I've choosen to use STLport with the
native VC6
       iostreams library.
       I.e. I've got the following  major configuration switch set (in
stl_user_config.h)
                    #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
       not 1.30.2).

      These new compilation problems all relate to the used of 'complex' and
Boost.Python's belief
      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.

--
Mike










More information about the Cplusplus-sig mailing list