Mac OS X y bibliotecas de impulso estáticas -> std :: string fail

Question

Estoy experimentando algunos problemas muy extraños con las bibliotecas de estimulación estática (Boost 1.45.0-2 de MacPorts, compiladas como librerías de grasa/universales (x86/x86_64)) bajo Mac OS X 10.6.6 con GCC 4.5.

El mensaje de error es

main(78485) malloc: *** error for object 0x1000e0b20: pointer being freed was not allocated 
*** set a breakpoint in malloc_error_break to debug 
[1] 78485 abort (core dumped) 

y un poco de ejemplo de código que provocará este problema:

#define BOOST_FILESYSTEM_VERSION 3 
#include <boost/filesystem.hpp> 
#include <iostream> 

int main (int argc, char **argv) { 
    std::cout << boost::filesystem::current_path().string() << '\n'; 
} 

Este problema se produce siempre al vincular las bibliotecas boost estático en el binario. Sin embargo, vincular dinámicamente funcionará bien.

Aún más información: versiones

gcc probados/utilizado: de Apple GCC 4.2.1 (obras/corre), DarwinPorts GCC 4.5.2 (falla) probaron

banderas/utilizados: ninguno, -fPIC, -fPIC -g, -fPIC -g -ggdb3 -gdwarf-2 -O0

salida gdb con MP GCC 4.5.2/ningún banderas de los anteriores:

(gdb) run 
Starting program: /Users/ionic/crashtest/bin/ctest Reading symbols for shared libraries .++++++++++++++++++++++.................................................................................................................. done 
ctest(80366) malloc: *** error for object 0x100fe6b20: pointer being freed was not allocated 
*** set a breakpoint in malloc_error_break to debug 

Program received signal SIGABRT, Aborted. 0x00007fff81a4e616 in __kill() 
(gdb) bt full 
#0 0x00007fff81a4e616 in __kill() No symbol table info available. 
#1 0x00007fff81aeecca in abort() No symbol table info available. 
#2 0x00007fff81a066f5 in free() No symbol table info available. 
#3 0x0000000100f763e9 in std::string::_M_mutate() No symbol table info available. 
#4 0x0000000100f7644c in std::string::_M_replace_safe() No symbol table info available. 
#5 0x0000000100f77edd in std::string::replace() No symbol table info available. 
#6 0x000000010000713d in std::string::_M_rep() at /usr/include/c++/4.2.1/bits/basic_string.h:1412 
     to = (string &) Cannot access memory at address 0x0 

Parece que funciona bien con la versión GCC de Apple (bastante antigua), pero no funciona bien con la nueva compilación GCC de MacPorts.

otool -L ctest:

./../../bin/ctest: 
     /opt/local/lib/gcc45/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.14.0) 
     /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 625.0.0) 
     /opt/local/lib/gcc45/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 125.2.1) 

He visto varios informes para un gran error del SO X similar con GCC 4.2 y el conjunto de macro _GLIBCXX_DEBUG, pero éste parece aún más genérica, como No estoy usando XCode, ni establezco la macro (incluso no definirlo no ayuda. Lo intenté solo para asegurarme de que realmente no está relacionado con este problema). No parece estar relacionado en absoluto con este problema, ya que el mismo código funciona bien con GCC de Apple.

Como el GCC de Apple aún no incluye ninguna característica de C++ 0x, me gustaría utilizar la versión GCC actualmente estable.

¿Alguien tiene alguna indicación sobre por qué sucede esto o incluso una solución (en lugar de utilizar la solución de la biblioteca dinámica)?

Saludos,

Mihai

Answer 1

El problema era que Boost ha sido construido usando GCC 4.2.1 de Apple, mientras que he estado construyendo el proyecto utilizando un compilador diferente.

Como traté de vincular las bibliotecas de Boost estáticas, también se colocó en el binario la libcdC++ de GCC 4.2.1. Sin embargo, al mismo tiempo, la otra versión de GCC estaba vinculando en su libstdC++ y los problemas de espacio de nombre eran inherentes, por lo tanto, se llamaron las funciones incorrectas y similares.

La solución más simple es reconstruir Boost con su versión GCC objetivo y volver a intentar la construcción de su programa (por ejemplo, utilizando el Boost autoconstruido).)

Tenga cuidado: no intente cambiar el compilador que MacPorts usa para construir Boost (incluso no es posible), o se puede romper el sistema. En cambio, crea Boost por tu cuenta.