[C++-sig] Re: [jamboost] Re: 1_28_0 python2.2.1 gcc3.0.4 build on sparc-solaris-2.7 problem report

[Mike Rovner]

It is known bug in 3.0.4. One solution is to include <iostream.h> before
Python.h
That allows to compile BPL.
But python.jam unconditionally uses -lutil which is not part of Solaris and
after manual exclusion I still
get:
python-test-target
../../../libs/python/build/bin/comprehensive.test/gcc/debug-python/runtime-l
ink-dynamic/comprehensive.test
Traceback (most recent call last):
  File "../test/comprehensive.py", line 1245, in ?
    from boost_python_test import *
ImportError: ld.so.1: /usr/local/bin/python: fatal: relocation error: file
/export/home/mike/boost_1_28_0/libs/python/build/bin/boost_python_test.so/gc
c/debug-python/runtime-link-dynamic/shared-linkable-true/boost_python_test.s
o: symbol _Py_RefTotal: referenced symbol not found

Thanks,
Mike

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:ad6dcn$dh3$2 at main.gmane.org...
> Moving this to the C++-sig, where it belongs...
>
> ----- Original Message -----
> From: "Mike Rovner" <gclbb-jamboost at m.gmane.org>
>
>
> >
> > "David Abrahams" wrote...
> > > Sounds like you're right. What's the proposed fix?
> >
> > Modify boost[.python] to use 64-bit file operations [in that case].
>
> Boost.Python doesn't use any file operations.
>
> > I.e. include wrap_python.hpp first, huh?
>
> "huh", Huh?
>
> Which file should #include wrap_python first?
>
> > Or exclude <cstddef> from config.hpp - I see no use of it in that file.
>
> It's needed for offsetof()... though it appears BOOST_OFFSETOF is not used
> anywhere anymore, so we could just dispense with that.
>
> What happens if you comment out the #include <cstddef> from config.hpp?
>
> -Dave