Re: [C++-sig] boost::python for Python 3.0
On Jun 1, 2009, at 5:52 AM, Alcides Viamontes Esquivel wrote: Good to know that you are on it! Same here, I'm super excited about python 3 compatibility! I work on http://mapnik.org which uses boost python heavily. Cheers, Dane ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Setting up a boost.python workflow on a Mac
Hello Randolph, On Oct 4, 2009, at 5:36 PM, Randolph Fritz wrote: I have just successfully--I hope--done this & I want to get my notes down before I forget the problems I encountered. These occurred with Boost 1.39 and Mac OS 10.5.8. 1. Bjam did not automatically detect the Mac OS environment and compilation consistently failed. So, I added the following line to /etc/site-config.jam: using darwin ; You can pass as a command line option to bjam: ./bjam toolset=darwin (see also: https://trac.mapnik.org/wiki/MacInstallation#Step1:RouteBC) Dane ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] cannot find -lboost_python after upgrade to Ubuntu 9.10
I think that recent boost packages on ubuntu have added a '-py25' or '- py26' at the end of the library, essentially providing two libraries linked to each of the python versions available on ubuntu. Dane On Nov 1, 2009, at 2:28 PM, Anders Wallin wrote: This example from the tutorial http://pastebin.ca/1652154 used to compile on my 9.04 system with this makefile: http://pastebin.ca/1652155 now after the 9.10 upgrade I get: /usr/bin/ld: cannot find -lboost_python what could be wrong? I do have 'libboost-python-dev' installed as well as 'libboost-python1.38.0' and 'libboost1.38-dev' ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Implementation of proper overload resolution
Troy,
Really __impressive__ write-up and work on this. I'd definitely be
interested in build instructions and your work getting into future
releases.
Cheers,
Dane
On Dec 17, 2009, at 8:08 AM, Troy D. Straszheim wrote:
Here's what I've got on overloading. This turned out to be a lot more
work, and this mail much longer, than I'd hoped. Would appreciate a
readthrough and comments/questions, I've done about all I can do.
First
a review of the problems, then a walkthrough of an implementation I
have
that fixes them.
1.a) Problem: Ambiguous calls from python to overloaded functions
Boost.python's 'overloading' is and has always been broken w.r.t. is
ambiguity. The library currently has no notion, given some tuple of
arguments, of one function being a better match than another. It
knows
only "this function matches" or not. What the user observes is the
following: when a call to a c++ function is made from python e.g.
m.f(1)
boost.python looks through the overloads for f, in the reverse order
of
registration, and calls the first one that is callable. For
instance if
the registrations are
void f_int(int);
void f_bool(bool);
BOOST_PYTHON_MODULE(m)
{
def("f", f_int);
def("f", f_bool);
}
then f_bool will execute this call of f(1), since the python 'int'
converts to c++ bool. If the overloads were registered in the reverse
order, f_int would be executed.
In this case the c++ overloads in question are potentially
distinguishable from one another, as python has distinct types bool
and
int. So these aren't "necessarily" ambiguous.
1.b) Problem: "Necessarily" ambiguous overloads
There are some overload sets that *are* necessarily ambiguous. This
set, for instance,
void f_double(double);
void f_float(float);
BOOST_PYTHON_MODULE(m)
{
def("f", f_double);
def("f", f_float);
}
can never be unambiguous, since python has no 'float' type. I.e.
f(x)
will call f_float for any value of x where the call succeeds at all.
1.c) Problem: Multiple values for keyword argument
At the same place in the boost.python code where this 'first-match'
overload resolution is done, the user error 'multiple values for
keyword
argument' is not checked. Neal Becker recently pointed this out.
With
boost.python it looks like this:
int addem(int x, int y, int z) { return x*100 + y*10 + z; }
BOOST_PYTHON_MODULE(M)
{
def("addem", &addem, (arg("x"), arg("y"), arg("z")));
}
from M import addem
addem(1, 8, 2, x=4)
Traceback (most recent call last):
...
ArgumentError: Python argument types in
M.addem(int, int, int)
did not match C++ signature:
addem(int x, int y, int z)
That error message is very confusing... f(int,int,int) doesn't match
f(int,int,int)? The pure python version reports something more
sensible:
def g(x,y,z, **kwargs):
... print x,y,z,kwargs
...
g(1,2,3,x=4)
Traceback (most recent call last):
File "", line 1, in
TypeError: g() got multiple values for keyword argument 'x'
2.) An implemented solution
I've got something implemented. Here's what it does.
2.a) Solution: multiple values for keyword
The easiest case to catch is the last [1.c]. It is also orthogonal to
the others. If a registered function has keyword arguments, check for
multiple keyword values, and raise an error if so:
from M import addem
addem(1,2,3,x=1)
Boost.Python.TypeError: M.addem() got multiple values for keyword
argument 'x'
2.b) Solution: "necessarily" ambiguous overloads
The next easiest thing to catch is case [1.b], "necessarily" ambiguous
registrations. It proceeds as follows: at import time, as each new
overload V for function F is registered, compare V to the existing
overloads EO for F. If V has the same signature as something in EO,
raise an AmbiguousOverload exception. For instance, if you load the
module from [1.b] above, you get:
import m
Traceback (most recent call last):
...
AmbiguousOverload: Boost.Python function m.f
has ambiguous overloads. C++ signatures
f(float) -> None
and
f(double) -> None
are indistinguishable to python.
Again this is because c++ float and c++ double both map to python
'float'. This one is "easy" as it happens only once (not at every
function call) and doesn't take up any space.
2.c) Solution: ambiguous calls
The hard case is [1.a]:
void f_bool(bool);
void f_int(int);
BOOST_PYTHON_MODULE(m)
{
def(f, f_bool);
def(f, f_int);
}
For module 'm' above, a call to f(True) or f(1) should succeed and
call
the corresponding function. Passing a float, however, is ambiguous:
f(True) # ok
f(1) # ok
f(1.0)
Traceback (most recent call last):
File "", line 1, in
Boost.Python.AmbiguousCall: Ambiguous call to Boost.Python function
m.f
C++ signatures:
f(int)
f(bool)
So the implementation has some how 'scored' each possible overload and
in each case either used the best one or reported ambiguity if
multiple
overloads are tied for 'best'.
The sc
Re: [C++-sig] Implementation of proper overload resolution
Troy,
Incidentally, do you know the proper way (or is there a proper way?)
to support None type keyword arguments?
Cheers,
Dane
On Dec 17, 2009, at 11:11 AM, Dane Springmeyer wrote:
Troy,
Really __impressive__ write-up and work on this. I'd definitely be
interested in build instructions and your work getting into future
releases.
Cheers,
Dane
On Dec 17, 2009, at 8:08 AM, Troy D. Straszheim wrote:
Here's what I've got on overloading. This turned out to be a lot
more
work, and this mail much longer, than I'd hoped. Would appreciate a
readthrough and comments/questions, I've done about all I can do.
First
a review of the problems, then a walkthrough of an implementation I
have
that fixes them.
1.a) Problem: Ambiguous calls from python to overloaded functions
Boost.python's 'overloading' is and has always been broken w.r.t. is
ambiguity. The library currently has no notion, given some tuple of
arguments, of one function being a better match than another. It
knows
only "this function matches" or not. What the user observes is the
following: when a call to a c++ function is made from python e.g.
m.f(1)
boost.python looks through the overloads for f, in the reverse
order of
registration, and calls the first one that is callable. For
instance if
the registrations are
void f_int(int);
void f_bool(bool);
BOOST_PYTHON_MODULE(m)
{
def("f", f_int);
def("f", f_bool);
}
then f_bool will execute this call of f(1), since the python 'int'
converts to c++ bool. If the overloads were registered in the
reverse
order, f_int would be executed.
In this case the c++ overloads in question are potentially
distinguishable from one another, as python has distinct types bool
and
int. So these aren't "necessarily" ambiguous.
1.b) Problem: "Necessarily" ambiguous overloads
There are some overload sets that *are* necessarily ambiguous. This
set, for instance,
void f_double(double);
void f_float(float);
BOOST_PYTHON_MODULE(m)
{
def("f", f_double);
def("f", f_float);
}
can never be unambiguous, since python has no 'float' type. I.e.
f(x)
will call f_float for any value of x where the call succeeds at all.
1.c) Problem: Multiple values for keyword argument
At the same place in the boost.python code where this 'first-match'
overload resolution is done, the user error 'multiple values for
keyword
argument' is not checked. Neal Becker recently pointed this out.
With
boost.python it looks like this:
int addem(int x, int y, int z) { return x*100 + y*10 + z; }
BOOST_PYTHON_MODULE(M)
{
def("addem", &addem, (arg("x"), arg("y"), arg("z")));
}
from M import addem
addem(1, 8, 2, x=4)
Traceback (most recent call last):
...
ArgumentError: Python argument types in
M.addem(int, int, int)
did not match C++ signature:
addem(int x, int y, int z)
That error message is very confusing... f(int,int,int) doesn't match
f(int,int,int)? The pure python version reports something more
sensible:
def g(x,y,z, **kwargs):
... print x,y,z,kwargs
...
g(1,2,3,x=4)
Traceback (most recent call last):
File "", line 1, in
TypeError: g() got multiple values for keyword argument 'x'
2.) An implemented solution
I've got something implemented. Here's what it does.
2.a) Solution: multiple values for keyword
The easiest case to catch is the last [1.c]. It is also orthogonal
to
the others. If a registered function has keyword arguments, check
for
multiple keyword values, and raise an error if so:
from M import addem
addem(1,2,3,x=1)
Boost.Python.TypeError: M.addem() got multiple values for keyword
argument 'x'
2.b) Solution: "necessarily" ambiguous overloads
The next easiest thing to catch is case [1.b], "necessarily"
ambiguous
registrations. It proceeds as follows: at import time, as each new
overload V for function F is registered, compare V to the existing
overloads EO for F. If V has the same signature as something in EO,
raise an AmbiguousOverload exception. For instance, if you load the
module from [1.b] above, you get:
import m
Traceback (most recent call last):
...
AmbiguousOverload: Boost.Python function m.f
has ambiguous overloads. C++ signatures
f(float) -> None
and
f(double) -> None
are indistinguishable to python.
Again this is because c++ float and c++ double both map to python
'float'. This one is "easy" as it happens only once (not at every
function call) and doesn't take up any space.
2.c) Solution: ambiguous calls
The hard case is [1.a]:
void f_bool(bool);
void f_int(int);
BOOST_PYTHON_MODULE(m)
{
def(f, f_bool);
def(f, f_int);
}
For module 'm' above, a call to f(True) or f(1) should succeed and
ca
Re: [C++-sig] [boost.python] How can I link against certain python version?
On Jan 4, 2010, at 10:50 PM, blp330 wrote:
Hi,
I try to upgrade my boost from 1.36 to 1.41, but it will link against
python26.lib.
My own python version is 2.5,
How can I tell boost to link with python25.lib?
What operating system are you on? Mac OS X?
Generally, I on Mac OSX I set up a user-config.jam file and then point
to it using the bjam options:
bjam --with-python --ignore-site-config --user-config=user-config.jam
toolset=darwin -d2
My 'user-config.jam' is based on the template that looks like this:
import option ;
import feature ;
if ! darwin in [ feature.values ]
{
using darwin ;
}
project : default-build darwin ;
using python
: %(num)s # version
: %(system)s/Library/Frameworks/Python.framework/Versions/%
(num)s/bin/python%(num)s # cmd-or-prefix
: %(system)s/Library/Frameworks/Python.framework/Versions/%
(num)s/include/python%(num)s # includes
: %(system)s/Library/Frameworks/Python.framework/Versions/%
(num)s/lib/python%(num)s/config # a lib actually symlink
: darwin # condition
;
libraries = --with-python ;
If it turns out you are on Mac OSX I can explain those variables in
the '%()s' syntax a bit more - they are not for bjam but just where
you might change info depending on which python version you want to
link against.
Dane
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] incorrect linking to libpython
Amos, I feel your pain, seriously. I've been down many of these paths as well. My overall sense is that direct linking of boost to a python executable may not be necessary, and rather that bjam could use `- undefined dynamic_lookup`, which will mean that when you import the python module you've built with boost::python the right version of python will be dynamically looked up based on the interpreter you are running. There are certainly potential problems with this route (and I've only lightly tested so far) but I think it may hold promise. More to the point, I've also got into the habit of passing -Z to the linker to make sure that if the custom python framework is not able to be linked, ld does not fallback to linking to the "system" or apple provided python framework and rather throws an error so you know the exact point things went wrong rather than only later by getting the dreaded "Version Mismatch" error. Failing to link to the /Library or user installed python26 is almost invariably the case on snow leopard because two copies will exist and the user installed version won't be preferentially linked with the normal -L/path/to/dir -lpython2.6 method because 'libpython2.6' is actually: /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/ libpython2.6.a and my sense is the linker will prefer the /usr/lib/libpython2.6.dylib over that because of the 'a' (even though it is actually, and oddly, a symlink to the dynamic library at: /Library/Frameworks/Python.framework/Versions/2.6/Python So, one workaround is symlinking: /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/ libpython2.6.dylib -> ../../../Python Then bjam should be able to find it. But I think a preferable method would be if bjam actually sent the linker line: -F/Library/Library/Frameworks -framework Python -Z instead of -L/etc/etc -lpython... Dane More info on those ld commands at: http://developer.apple.com/mac/library/DOCUMENTATION/Darwin/Reference/ManPages/man1/ld.1.html On Feb 26, 2010, at 3:47 PM, Amos Anderson wrote: Hello -- summary: I'm trying to compile the boost python library using a custom installed python on osx. however, it appears to be linking to the system library, not the installed library. I'm using OSX 10.6.2, which has python 2.6.1 by default. I wanted to try to install 2.6.4 just to see how the process works. I To install python, I did this: ./configure --enable-framework make make install which put the distribution here: /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 I changed a boost config file to read: using python : 2.6 : /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 : /Library/Frameworks/Python.framework/Versions/2.6/include/ python2.6 : /Library/Frameworks/Python.framework/Versions/2.6/lib/ python2.6/config ; and compiled the library. However, when I examine the library itself: % otool -L libboost_python.dylib libboost_python.dylib: libboost_python.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Python.framework/Versions/2.6/Python (compatibility version 2.6.0, current version 2.6.1) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) I can see that it linked to the system's version. Why did it choose that one? The problem is that when I run my code, I get the error: Fatal Python error: Interpreter not initialized (version mismatch?) ../../../triad.sh: line 9: 59136 Abort trap python $@ the OS gives me a popup window mentioning all the linked libraries: Binary Images: 0x1 -0x10ff7 +org.python.python 2.6.4 (2.6.4) <536A2002-9AEC-D7DF-8C2B-6C634FB7F37E> /Library/Frameworks/Python.framework/Versions/2.6/Resources/ Python.app/Contents/MacOS/Python 0x13000 -0x100153fe7 +org.python.python 2.6.4, (c) 2004-2008 Python Software Foundation. (2.6.4) <3B4D8CE1-8D9C-97CB-57BA-A8F4C40CE5F0> /Library/Frameworks/Python.framework/Versions/2.6/Python 0x1002e7000 -0x1002e8ff7 +time.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib- dynload/time.so 0x10048 -0x100493fef +libgcc_s.1.dylib ??? (???) /usr/local/lib/libgcc_s.1.dylib 0x100753000 -0x10077bfff +libboost_wserialization.dylib ??? (???) <4FD94C16-75D0-DE5D-A27B-E3AEAEEA8CCC> /Users/amos/triad/trunk/lib/libboost_wserialization.dylib 0x10100 -0x1013eeff7 +triad.so ??? (???) /Users/amos/triad/trunk/lib/triad.so 0x1020eb000 -0x102124fef +libboost_serialization.dylib ??? (???) <33DB6DD1-4712-AEE1-0761-18054566A5E4> /Users/amos/triad/trunk/lib/libboost_serialization.dylib 0x1021b1000 -0x1021f0ff7 +libboost_python.dylib ??? (???) <67258016-C11E-8EDF-BF36-103DBC2
[C++-sig] boost python and clang++
Anyone tried building a boost python application using clang++? I noticed this post: http://blog.llvm.org/2010/05/clang-builds-boost.html#more and gave it a shot with mapnik (mapnik.org). Compiled fine (in nearly half the time), but it appears that exception translation is not working: http://trac.mapnik.org/ticket/565 Any thoughts or ideas welcome! Dane ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] help finding solution to lack of exception handling with boost python on open solaris 64 bit
Hello, I recently recompiled my C++ app (mapnik.org, which uses boost python for python binding) with -m64 flags for 64 bit operation and this broke the boost python exception handling. Instead of C++ exceptions being propagated to python exceptions, I get segmentation faults (core dump). I have a long dependency chain that all needs to be 64 bit, so I'm really stuck unless I can find a way to restore boost python's ability to handle exceptions without crashing. Exceptions are very common during setup of mapnik, and are needed to report basic configuration issues as a user gets set up. I'm desperate to try anything that might help - anyone have any suggestions? What i have tried so far: 1) recompiling all apps with -02 instead of -03 2) making sure all apps are compiled with the exact same version of gcc (at least all the C++ libraries I have compiled from source) 3) ensured that all dynamic libraries link to the same libgcc_s.so.1 and libstdc++.so.6. 4) tried with both boost 1.44 and 1.45 I'm out of ideas - anyone have suggestions to try? More info below. Dane -- With 32bit boost, python, and mapnik, exceptions worked fine. This is on opensolaris: $ cat /etc/release OpenSolaris Development snv_133 X86 Copyright 2010 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 15 February 2010 with the sun provided 64 bit python26: $ /usr/bin/amd64/python --version Python 2.6.4 Both boost and mapnik are compiled with a *custom* compiled gcc 44: $ /opt/ts/gcc/4.4/bin/g++ -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: .././configure --prefix=/opt/ts/gcc/4.4 --bindir=/opt/ts/gcc/4.4/bin --libdir=/opt/ts/gcc/4.4/lib --mandir=/opt/ts/gcc/4.4/share/man --datadir=/opt/ts/gcc/4.4/share --includedir=/opt/ts/gcc/4.4/include --infodir=/opt/ts/gcc/4.4/share/info --libexecdir=/opt/ts/gcc/4.4/lib --sysconfdir=/etc/opt/ts --disable-nls --disable-static --with-gnu-as --with-as=/usr/gnu/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared --enable-multilib --enable-nls --without-x --with-system-zlib --enable-languages=c,c++,f95,objc --with-mpfr=/opt/ts --with-gmp=/opt/ts Thread model: posix gcc version 4.4.4 (GCC) ( I was unable to get boost compiled with the gcc 3.4.3 or gcc 4.3.3 provided by sun packages, for more info see: http://trac.mapnik.org/wiki/OpenSolarisInstallation/TroubleShooting) So, instead of throwing an understandable exception, boost python crashes and this is what a normal backtrace looks like in gbd: (gdb) bt #0 0x0005f666 in ?? () #1 0xfd7fff2ec5d1 in _Unwind_RaiseException_Body () from /usr/lib/amd64/libc.so.1 #2 0xfd7fff2ec855 in _Unwind_RaiseException () from /usr/lib/amd64/libc.so.1 #3 0xfd7ffa98bb39 in __cxa_throw (obj=, tinfo=0x1, dest=0x474e5543432b2b00) at ../../../../.././libstdc++-v3/libsupc++/eh_throw.cc:78 #4 0xfd7ff3aa2de2 in boost::python::throw_error_already_set () from /usr/local/lib/libboost_python.so.1.44.0 #5 0xfd7ff3a9ae31 in boost::python::objects::function::argument_error () from /usr/local/lib/libboost_python.so.1.44.0 #6 0xfd7ff3a9b4fb in boost::python::objects::function::call () from /usr/local/lib/libboost_python.so.1.44.0 #7 0xfd7ff3a9b730 in boost::detail::function::void_function_ref_invoker0::invoke () from /usr/local/lib/libboost_python.so.1.44.0 #8 0xfd7ff3aa3053 in boost::python::detail::exception_handler::operator() () from /usr/local/lib/libboost_python.so.1.44.0 #9 0xfd7ff28fb1b2 in boost::detail::function::function_obj_invoker2, boost::_bi::list3, boost::arg<2>, boost::_bi::value > >, bool, boost::python::detail::exception_handler const&, boost::function0 const&>::invoke () from /usr/local/lib/python2.6/site-packages/mapnik/64/_mapnik.so #10 0xfd7ff3aa2e25 in boost::python::handle_exception_impl () from /usr/local/lib/libboost_python.so.1.44.0 #11 0xfd7ff3a97d50 in function_call () from /usr/local/lib/libboost_python.so.1.44.0 #12 0xfd7ff6ff9aad in PyObject_Call () from /usr/lib/amd64/libpython2.6.so.1.0 #13 0xfd7ff700af29 in instancemethod_call () from /usr/lib/amd64/libpython2.6.so.1.0 #14 0xfd7ff6ff9aad in PyObject_Call () from /usr/lib/amd64/libpython2.6.so.1.0 #15 0xfd7ff705d8a1 in slot_tp_init () from /usr/lib/amd64/libpython2.6.so.1.0 #16 0xfd7ff7051c06 in type_call () from /usr/lib/amd64/libpython2.6.so.1.0 #17 0xfd7ff6ff9aad in PyObject_Call () from /usr/lib/amd64/libpython2.6.so.1.0 #18 0xfd7ff709c1c0 in do_call () from /usr/lib/amd64/libpython2.6.so.1.0 #19 0xfd7ff709b672 in call_function () from /usr/lib/amd64/libpython2.6.so.1.0 #20 0xfd7ff709810d in PyEval_EvalFrameExReal () from /usr/lib/amd64/libpython2.6.so.1.0 #21 0xfd7ff7094d9d in PyEval_EvalFrameEx () from /usr/lib/amd64/libpython2.6.so.1.0 #22 0
Re: [C++-sig] help finding solution to lack of exception handling with boost python on open solaris 64 bit
Thanks everyone for your ideas! Exactly what I was looking for.
With your help I I've narrowed it down to duplicate libgcc_s.so versions being
imported, as this solves it:
LD_PRELOAD=/usr/sfw/lib/amd64/libgcc_s.so
So I can now do:
LD_PRELOAD=/usr/sfw/lib/amd64/libgcc_s.so /usr/bin/amd64/python -c "import
mapnik;mapnik.Map('this should throw exception');"
...which now throws a proper argument error exception.
So, my error is now clearer: I've been using sun provided 64 bit python
compiled with a different gcc version than I built both boost and mapnik with.
Why I could get away with this in 32 bit mode is beyond me.
My understanding is that by using LD_PRELOAD I am able to force the libgcc_s.so
version that python itself is linked to - to be loaded first (rather than the
libgcc_s.so that boost_python and _mapnik.so are linked to). This allows both
the exception handling to work again and the program (surprisingly) to run
properly (tests pass at least).
I figure, since I was unable to compile boost_python (or boost proper) with the
gcc version from sun (and that the sun python was compiled with), my only
proper route from here is to compile python myself using my custom version of
gcc.
Dane
>>
>> On Thu, Dec 2, 2010 at 4:23 PM, Dane Springmeyer wrote:
>>
>>> Hello,
>>>
>>> I recently recompiled my C++ app (mapnik.org, which uses boost python for
>>> python binding) with -m64 flags for 64 bit operation and this broke the
>>> boost python exception handling.
>>>
>>> Instead of C++ exceptions being propagated to python exceptions, I get
>>> segmentation faults (core dump).
>>>
>>> I have a long dependency chain that all needs to be 64 bit, so I'm really
>>> stuck unless I can find a way to restore boost python's ability to handle
>>> exceptions without crashing.
>>>
>>> Exceptions are very common during setup of mapnik, and are needed to report
>>> basic configuration issues as a user gets set up.
>>>
>>> I'm desperate to try anything that might help - anyone have any
>>> suggestions?
>>>
>>> What i have tried so far:
>>>
>>> 1) recompiling all apps with -02 instead of -03
>>> 2) making sure all apps are compiled with the exact same version of gcc (at
>>> least all the C++ libraries I have compiled from source)
>>> 3) ensured that all dynamic libraries link to the same libgcc_s.so.1 and
>>> libstdc++.so.6.
>>> 4) tried with both boost 1.44 and 1.45
>>>
>>> I'm out of ideas - anyone have suggestions to try?
>>>
>>> More info below.
>>>
>>> Dane
>>>
>>> --
>>>
>>> With 32bit boost, python, and mapnik, exceptions worked fine.
>>>
>>> This is on opensolaris:
>>>
>>> $ cat /etc/release
>>> OpenSolaris Development snv_133 X86
>>> Copyright 2010 Sun Microsystems, Inc. All Rights Reserved.
>>> Use is subject to license terms.
>>> Assembled 15 February 2010
>>>
>>> with the sun provided 64 bit python26:
>>>
>>> $ /usr/bin/amd64/python --version
>>> Python 2.6.4
>>>
>>> Both boost and mapnik are compiled with a *custom* compiled gcc 44:
>>>
>>> $ /opt/ts/gcc/4.4/bin/g++ -v
>>> Using built-in specs.
>>> Target: i386-pc-solaris2.11
>>> Configured with: .././configure --prefix=/opt/ts/gcc/4.4
>>> --bindir=/opt/ts/gcc/4.4/bin --libdir=/opt/ts/gcc/4.4/lib
>>> --mandir=/opt/ts/gcc/4.4/share/man --datadir=/opt/ts/gcc/4.4/share
>>> --includedir=/opt/ts/gcc/4.4/include --infodir=/opt/ts/gcc/4.4/share/info
>>> --libexecdir=/opt/ts/gcc/4.4/lib --sysconfdir=/etc/opt/ts --disable-nls
>>> --disable-static --with-gnu-as --with-as=/usr/gnu/bin/as --without-gnu-ld
>>> --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared
>>> --enable-multilib --enable-nls --without-x --with-system-zlib
>>> --enable-languages=c,c++,f95,objc --with-mpfr=/opt/ts --with-gmp=/opt/ts
>>> Thread model: posix
>>> gcc version 4.4.4 (GCC)
>>>
>>> ( I was unable to get boost compiled with the gcc 3.4.3 or gcc 4.3.3
>>> provided by sun packages, for more info see:
>>> http://trac.mapnik.org/wiki/OpenSolarisInstallation/TroubleShooting)
>>>
>>>
>>> So, instead of throwing an understandable exception, boost python crashes
>>> and this is what a normal backtrace looks like in gbd:
>>>
&g
Re: [C++-sig] Boost.Python and python 3.x?
On Dec 30, 2010, at 9:33 AM, Ralf W. Grosse-Kunstleve wrote: > Hi Andrew, > > Yes, the GSoC project was finished. > I checked in a few Python3 related fixes after the > 1.45 release that may be important for you, in > particular the one below, which you could easily apply > manually to your installation. > > Ralf > Hi Ralf, Great stuff, thanks for doing this. I'm starting to use the new python3 support and that windows fix will surely help down the road. Curious if you could also take a look at https://svn.boost.org/trac/boost/ticket/4609 and see if it is viable for checkin? Thanks! Dane ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
