Mac builds link to wrong Python binaries #380

Closed
artemp opened this Issue Oct 11, 2011 · 5 comments

Comments

Projects
None yet
1 participant
Owner

artemp commented Oct 11, 2011

I was getting a bus error when loading Mapnik into the standard Leopard Python 2.5.

{{{
% which python
/usr/bin/python
% python
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import mapnik
Bus error
}}}

The stack trace showed:

{{{
Process: Python [9129]
Path: /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
Identifier: Python
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: tcsh [81490]

Interval Since Last Report: 559 sec
Crashes Since Last Report: 2
Per-App Interval Since Last Report: 0 sec
Per-App Crashes Since Last Report: 2

Date/Time: 2009-07-08 16:54:43.456 -0700
OS Version: Mac OS X 10.5.7 (9J61)
Report Version: 6
Anonymous UUID: CCDA1631-26C1-4F73-AD03-C2A3B4FD4F07

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000028
Crashed Thread: 0

Thread 0 Crashed:
0 org.python.python 0x004cbfa1 PyErr_Occurred + 17
1 mapnik.so 0x01072a29 boost::python::len(boost::python::api::object const&) + 33 (object.hpp:21)
2 ...python-xgcc40-mt-1_39.dylib 0x002991bc boost::python::objects::function_doc_signature_generator::function_doc_signatures(boost::python::objects::function const
) + 284 (function_doc_signature.cpp:288)
3 ...python-xgcc40-mt-1_39.dylib 0x00285f97 function_get_doc + 39 (object_operators.hpp:71)
4 org.python.python 0x0012e688 PyDictProxy_New + 2768
5 org.python.python 0x0014d942 PyObject_GenericGetAttr + 780
6 org.python.python 0x0014d12a PyObject_GetAttrString + 70
7 org.python.python 0x0012e1dd PyDictProxy_New + 1573
8 org.python.python 0x0015e58e PyType_IsSubtype + 1288
9 org.python.python 0x00121505 PyObject_Call + 50
10 org.python.python 0x001215d4 PyObject_Call + 257
11 org.python.python 0x00121643 PyObject_CallFunction + 74
12 ...python-xgcc40-mt-1_39.dylib 0x002843e6 boost::python::objects::class_base::add_property(char const_, boost::python::api::object const&, char const*) + 70 (errors.hpp:44)
13 mapnik.so 0x010be66a boost::python::class<mapnik::query, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>& boost::python::class_<mapnik::query, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>::add_property<double (mapnik::query::)() const>(char const_, double (mapnik::query::)() const, char const) + 74
14 _mapnik.so 0x010bd307 export_query() + 257
15 mapnik.so 0x010b03d1 init_module__mapnik() + 45
16 ...python-xgcc40-mt-1_39.dylib 0x002906e9 boost::function0::operator()() const + 41 (function_template.hpp:989)
17 ...python-xgcc40-mt-1_39.dylib 0x0028fc3c boost::python::handle_exception_impl(boost::function0) + 204 (errors.cpp:25)
18 ...python-xgcc40-mt-1_39.dylib 0x00290ab0 boost::python::detail::init_module(char const
, void (
)()) + 160 (function_template.hpp:849)
19 _mapnik.so 0x010afec1 init_mapnik + 37 (mapnik_python.cpp:228)
20 org.python.python 0x001a35f1 _PyImport_LoadDynamicModule + 187
[...]

Binary Images:
0x1000 - 0x1ffe org.python.pythonapp 2.5.0 (2.5.0a0) <5aa9f0cc36fda395f965e08c96613cf5> /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
0x49000 - 0x4afff readline.so ??? (???) <242a40e30d706dd854dfd70f6c6574d7> /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/readline.so
0xbb000 - 0xbbffe dl.so ??? (???) /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/dl.so
0x119000 - 0x1e5feb org.python.python 2.5 (2.5) <523ba54c654eeed6bc670db2f58a73ab> /System/Library/Frameworks/Python.framework/Versions/2.5/Python
0x232000 - 0x248fea libedit.2.dylib ??? (???) /usr/lib/libedit.2.dylib
0x272000 - 0x2a4fff +libboost_python-xgcc40-mt-1_39.dylib ??? (???) <9d0d3fadfcc63a263a5c6a3b7523a12d> /usr/local/lib/libboost_python-xgcc40-mt-1_39.dylib
0x2e9000 - 0x2ecffc libltdl.3.dylib ??? (???) <7eb66768e1abe38c3799255e56cf3693> /usr/lib/libltdl.3.dylib
0x2f2000 - 0x2f4ffb +libboost_system-xgcc40-mt-1_39.dylib ??? (???) /usr/local/lib/libboost_system-xgcc40-mt-1_39.dylib
0x400000 - 0x52affb +org.python.python 2.6.1, (c) 2004-2008 Python Software Foundation. (2.6.1) <97a408d2d126e7b1a8861dc789d78984> /Library/Frameworks/Python.framework/Versions/2.6/Python
0x5d7000 - 0x697ffb +com.kyngchaos.UnixImageIO 1.0.29 (UnixImageIO 1.0.29) <2bb05fd563367f1447de07c18af2e489> /Library/Frameworks/UnixImageIO.framework/Versions/B/UnixImageIO
0x6bd000 - 0x7b7fef +libicuuc.42.dylib ??? (???) <9a3c257721626f508497e0992b294ed7> /usr/local/lib/libicuuc.42.dylib
0x1000000 - 0x122cfff +_mapnik.so ??? (???) /Library/Python/2.5/site-packages/mapnik/_mapnik.so
0x1bc8000 - 0x1db2fff +libmapnik.dylib ??? (???) /usr/local/lib/libmapnik.dylib
[...]
}}}

It took me a while before I noticed both Python 2.5 and Python 2.6 were in the link list. I had once installed Python 2.6 from Python.org, but it was not the standard "python" executable on my path.

The problematic line in the build log is
{{{
g++ -o bindings/python/_mapnik.so -F/ -framework Python -bundle [...]
}}}

The -framework Python parameter is causing GCC to use /Library/Frameworks/Python.framework/Versions/Current instead of /System/Library/Frameworks/Python.framework/Versions/Current, which is the framework for /usr/bin/python.

I fixed my build problem by deleting the Python 2.6 framework and rebuilding Boost and Mapnik.

Admittedly, this is a configuration issue on my system, but it would be nice if Scons figured out somehow the proper version of the framework to link via the "python" executable rather than the "current" framework.

Owner

artemp commented Oct 11, 2011

[springmeyer] r1187 added the ability to point the linker to the specific framework path. Needs more testing but that should allow you to control the linking. Let us know if you test any further.

Owner

artemp commented Oct 11, 2011

[springmeyer] BTW, what really matters is what version of python libboost_python is linked to, since _mapnik.so must be linked to the same version of python as boost. Controlling python linking with bjam can be even trickier than with SCons/Mapnik.

what does this give?

{{{
otool -L /usr/local/lib/libboost_python-xgcc40-mt-1_39.dylib
}}}

Also?

{{{
otool -L /Library/Python/2.5/site-packages/mapnik/_mapnik.so
}}}

Owner

artemp commented Oct 11, 2011

[jlieske] I trashed the Python 2.6 framework and the builds of Boost and Mapnik, but they are still in the Trash:

{{{
otool -L ~/.Trash/libboost_python-xgcc40-mt-1_39.dylib ~/.Trash/mapnik/_mapnik.so
/Users/jlieske/.Trash/libboost_python-xgcc40-mt-1_39.dylib:
libboost_python-xgcc40-mt-1_39.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Python.framework/Versions/2.5/Python (compatibility version 2.5.0, current version 2.5.1)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
/Users/jlieske/.Trash/mapnik/_mapnik.so:
/Library/Frameworks/Python.framework/Versions/2.6/Python (compatibility version 2.6.0, current version 2.6.0)
libmapnik.dylib (compatibility version 0.0.0, current version 0.0.0)
/Library/Frameworks/UnixImageIO.framework/Versions/B/UnixImageIO (compatibility version 1.0.0, current version 1.0.29)
libboost_python-xgcc40-mt-1_39.dylib (compatibility version 0.0.0, current version 0.0.0)
libicuuc.42.dylib (compatibility version 42.0.0, current version 42.0.0)
../lib/libicudata.42.0.dylib (compatibility version 42.0.0, current version 42.0.0)
libboost_regex-xgcc40-mt-1_39.dylib (compatibility version 0.0.0, current version 0.0.0)
libboost_thread-xgcc40-mt-1_39.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
}}}

Owner

artemp commented Oct 11, 2011

[springmeyer] see also: 453

Owner

artemp commented Oct 11, 2011

[springmeyer] should be prevented with more certainty now with #1451, but still also controllable with the SCons option FRAMEWORK_SEARCH_PATH

@artemp artemp closed this Oct 11, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment