Problemas de biblioteca dinámica con Python y libstdc ++
esumen ejecutivo: un módulo de Python está vinculado a una versión diferente delibstdc++.dylib que el ejecutable de Python. El resultado es que llama aiostream desde el bloqueo del módulo.
Estoy creando un módulo Python usando SWIG en una computadora más antigua (ejecutando 10.5.8). Por varias razones, estoy usando GCC 4.5 (instalado a través de MacPorts) para hacer esto, usando Python 2.7 (instalado a través de MacPorts, compilado usando el GCC 4.0.1 predeterminado del sistema).
Comportamiento observadoara resumir una larga historia: llamando astr( myObject ) en Python hace que el código C ++ a su vez llame astd::operator<< <std::char_traits<char> >. Esto genera el siguiente error:
Python(487) malloc: *** error for object 0x69548c: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
Establecer un punto de interrupción y llamar abacktrace cuando falla da:
#0 0x9734de68 in malloc_error_break ()
#1 0x97348ad0 in szone_error ()
#2 0x97e6fdfc in std::string::_Rep::_M_destroy ()
#3 0x97e71388 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string ()
#4 0x97e6b748 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow ()
#5 0x97e6e7a0 in std::basic_streambuf<char, std::char_traits<char> >::xsputn ()
#6 0x00641638 in std::__ostream_insert<char, std::char_traits<char> > ()
#7 0x006418d0 in std::operator<< <std::char_traits<char> > ()
#8 0x01083058 in meshLib::operator<< <tranSupport::Dimension<(unsigned short)1> > (os=@0xbfffc628, c=@0x5a3c50) at /Users/sethrj/_code/pytrt/meshlib/oned/Cell.cpp:21
#9 0x01008b14 in meshLib_Cell_Sl_tranSupport_Dimension_Sl_1u_Sg__Sg____str__ (self=0x5a3c50) at /Users/sethrj/_code/_build/pytrt-gcc45DEBUG/meshlib/swig/mesh_onedPYTHON_wrap.cxx:4439
#10 0x0101d150 in _wrap_Cell_T___str__ (args=0x17eb470) at /Users/sethrj/_code/_build/pytrt-gcc45DEBUG/meshlib/swig/mesh_onedPYTHON_wrap.cxx:8341
#11 0x002f2350 in PyEval_EvalFrameEx ()
#12 0x002f4bb4 in PyEval_EvalCodeEx ()
[snip]
Creo que el problema es que mi código se vincula con una nueva versión de libstdc ++:
/opt/local/lib/gcc45/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.14.0)
mientras que el binario de Python tiene una dependencia muy indirecta del sistemalibstdc++, que se carga primero (salida deinfo shared en gdb):
1 dyld - 0x8fe00000 dyld Y Y /usr/lib/dyld at 0x8fe00000 (offset 0x0) with prefix "__dyld_"
2 Python - 0x1000 exec Y Y /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python (offset 0x0)
(objfile is) /opt/local/bin/python
3 Python F 0x219000 dyld Y Y /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python at 0x219000 (offset 0x219000)
4 libSystem.B.dylib - 0x9723d000 dyld Y Y /usr/lib/libSystem.B.dylib at 0x9723d000 (offset -0x68dc3000)
(commpage objfile is) /usr/lib/libSystem.B.dylib[LC_SEGMENT.__DATA.__commpage]
5 CoreFoundation F 0x970b3000 dyld Y Y /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation at 0x970b3000 (offset -0x68f4d000)
6 libgcc_s.1.dylib - 0x923e6000 dyld Y Y /usr/lib/libgcc_s.1.dylib at 0x923e6000 (offset -0x6dc1a000)
7 libmathCommon.A.dylib - 0x94af5000 dyld Y Y /usr/lib/system/libmathCommon.A.dylib at 0x94af5000 (offset -0x6b50b000)
8 libicucore.A.dylib - 0x97cf4000 dyld Y Y /usr/lib/libicucore.A.dylib at 0x97cf4000 (offset -0x6830c000)
9 libobjc.A.dylib - 0x926f0000 dyld Y Y /usr/lib/libobjc.A.dylib at 0x926f0000 (offset -0x6d910000)
(commpage objfile is) /usr/lib/libobjc.A.dylib[LC_SEGMENT.__DATA.__commpage]
10 libauto.dylib - 0x95eac000 dyld Y Y /usr/lib/libauto.dylib at 0x95eac000 (offset -0x6a154000)
11 libstdc++.6.0.4.dylib - 0x97e3d000 dyld Y Y /usr/lib/libstdc++.6.0.4.dylib at 0x97e3d000 (offset -0x681c3000)
12 _mesh_oned.so - 0x1000000 dyld Y Y /Users/sethrj/_code/_build/pytrt-gcc45DEBUG/meshlib/swig/_mesh_oned.so at 0x1000000 (offset 0x1000000)
13 libhdf5.7.dylib - 0x122c000 dyld Y Y /opt/local/lib/libhdf5.7.dylib at 0x122c000 (offset 0x122c000)
14 libz.1.2.5.dylib - 0x133000 dyld Y Y /opt/local/lib/libz.1.2.5.dylib at 0x133000 (offset 0x133000)
15 libstdc++.6.dylib - 0x600000 dyld Y Y /opt/local/lib/gcc45/libstdc++.6.dylib at 0x600000 (offset 0x600000)
[snip]
Nota que elmalloce produce un error @ en la dirección de memoria del sistemalibstdc++, no con el que está vinculada la biblioteca compartida.
Traté de obligar a MacPorts a construir Python usando GCC 4.5 en lugar del compilador de Apple, pero la fase de instalación falla porque necesita crear un "Framework" de Mac, lo que aparentemente GCC no hac
Incluso con la-static-libstdc++ indicador del compilador, __ostream_insert llama alstd::basic_streambuf de la biblioteca compartida cargada por el sistema.
Intenté modificar DYLD_LIBRARY_PATH anteponiendo/opt/local/lib/gcc45/ pero sin resultado.
¿Qué puedo hacer para que esto funcione? Estoy al final de mi ingenio
Más informacióEste problema parece sercommon to mac os x. Observe cómo en todas las salidas de depuración se muestran, la dirección salta entre las llamadas astd::__ostream_insert ystd::basic_streambuf::xsputn: está dejando el nuevo código GCC 4.5 y saltando al código de la biblioteca compartida anterior en/usr/bin. Ahora, para encontrar una solución alternativa ...