Mac OS X и статические надстройки -> std :: string fail

Question

У меня возникают очень странные проблемы с библиотеками статического повышения (Boost 1.45.0-2 из MacPorts, скомпилированные как библиотеки fat / universal (x86 / x86_64)) в Mac OS X 10.6.6 с GCC 4.5.

Сообщение об ошибке:

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)

и небольшой пример кода, который вызовет эту проблему:

#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';
}

Эта проблема всегда возникает при соединении библиотек статического усиления в двоичном файле. Однако динамическое связывание будет работать нормально.

Еще больше информации:

версии gcc проверены / использованы: Apple GCC 4.2.1 (работает / работает), MacPorts GCC 4.5.2 (не работает)

флаги протестированы / использованы: нет, -fPIC, -fPIC -g, -fPIC -g -ggdb3 -gdwarf-2 -O0

вывод gdb с MP GCC 4.5.2 / любые флаги из вышеперечисленного:

(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

Похоже, что он работает нормально с (довольно старой) версией GCC от Apple, но плохо работает с новой сборкой GCC от 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)

Я видел различные отчеты для довольно похожей ошибки OS X с GCC 4.2 и набором макросов _GLIBCXX_DEBUG, но этот кажется еще более общим, так как я не использую XCode и не устанавливаю макрос (даже отмена определения не помогает. Я попробовал сделать это просто для того, чтобы убедиться, что это действительно не связано с этой проблемой.) Кажется, что это вообще не связано с этой проблемой, так как тот же код хорошо работает с GCC от Apple.

Поскольку в GCC Apple пока нет функций C ++ 0x, я бы действительно хотел использовать стабильную версию GCC.

Кто-нибудь знает, почему это происходит, или даже может быть решением (вместо использования обходного пути динамической библиотеки)?

С уважением,

Михай

Answer 1

Проблема заключалась в том, что Boost был собран с использованием Apple GCC 4.2.1, в то время как я собирал проект с использованием другого компилятора.

Когда я попытался связать статические библиотеки Boost, в двоичный файл был также включен libstdc ++ GCC 4.2.1. Однако в то же время другая версия GCC была связана с libstdc ++, и проблемы с пространством имен были присущи, поэтому были вызваны неправильные функции и тому подобное.

Самое простое исправление - это перестроить Boost с вашей целевой версией GCC и повторить сборку вашей программы (вкл., Используя самосозданный Boost.)

Будьте осторожны: не пытайтесь изменить компилятор, который MacPorts использует для сборки Boost (это даже не легко возможно), иначе может произойти сбой системы. Вместо этого постройте Boost самостоятельно.