Mac OS X e librerie boost statiche -> std :: string fail

Question

Sto riscontrando alcuni problemi molto bizzarri con le librerie boost statiche (Boost 1.45.0-2 da MacPorts, compilato come librerie fat/universal (x86/x86_64)) in Mac OS X 10.6.6 con GCC 4.5.

Il messaggio di errore è

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) 

e un po 'di codice di esempio che attiverà questo 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'; 
} 

Questo problema si verifica sempre quando si collegano le librerie boost statico nel binario. Il collegamento dinamico funzionerà bene, però.

ancora più informazioni: versioni

gcc testate/usato: di Apple GCC 4.2.1 (opere/corre), MacPorts GCC 4.5.2 (non)

bandiere testati/usati: nessuno, -fPIC, -fPIC -g, -fPIC -g -ggdb3 -gdwarf-2 -O0

uscita gdb con MP GCC 4.5.2/eventuali bandiere di cui sopra:

(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 

Sembra che stia funzionando bene con la versione GCC (piuttosto vecchia) di Apple, ma non funziona male con la nuova build GCC di 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) 

Ho visto vari rapporti per tutto simile OS X bug con GCC 4.2 e il macro serie _GLIBCXX_DEBUG, ma questo sembra ancora più generici, come Non utilizzo né XCode né l'impostazione della macro (anche la definizione non definitiva non è d'aiuto. L'ho provata solo per assicurarmi che non sia realmente correlata a questo problema.) Non sembra essere correlato a questo problema, come lo stesso codice funziona perfettamente con GCC di Apple.

Come GCC di Apple non include ancora le funzionalità di C++ 0x, mi piacerebbe davvero usare la versione GCC attualmente stabile.

Qualcuno ha qualche indicazione sul perché questo sta accadendo o magari su una soluzione (piuttosto che usare la soluzione alternativa della libreria dinamica)?

Con i migliori saluti,

Mihai

Answer 1

Il problema era che Boost è stato costruito utilizzando Apple GCC 4.2.1, mentre Ho costruito il progetto con un compilatore diverso.

Come ho tentato di collegare le librerie Boost statiche, anche il libstdC++ di GCC 4.2.1 è stato inserito nel binario. Tuttavia, allo stesso tempo l'altra versione di GCC stava collegando nel suo libstdC++ e i problemi di spazio dei nomi erano inerenti, quindi venivano chiamate le funzioni sbagliate e simili.

La soluzione più semplice è la ricostruzione di Boost con la versione GCC di destinazione e riprovare la costruzione del programma (utilizzando il Boost auto-costruito.)

Attenzione: non tentare di modificare il compilatore MacPorts utilizza per la creazione di Boost (non è nemmeno facilmente possibile), o si può verificare la rottura del sistema. Invece, costruisci Boost per conto tuo.