C++: все операции над расширением segfault (OSX/GCC)

Question

Я получаю согласованные segfaults практически с любой операцией, которую я пытаюсь выполнить с помощью ускоренного пути.

(Edit: Оказывается, что все segfaulting функции связаны с current_path())

Sample program: 

#include <boost/filesystem/operations.hpp> 
#include <boost/filesystem/path.hpp> 
#include <iostream> 

using namespace std; 
using namespace boost::filesystem; 
using namespace boost::system; 


int main(int argc, const char * argv[]) 
{ 
    error_code err; 
    auto p = path("hello/../world"); 
    cout << p.string() << endl; 
    path c = canonical(p, err); 
    cout << c.string() << endl; 
} 

выше, является только примером, следующий также сегментации:
auto p = current_path(err);

И:
auto p = initial_path(err);

Скомпилировано:
g++-4.9 -lboost_filesystem -lboost_system -std=c++11 main.cpp -o ./path-test

Выход:

hello/../world 
Segmentation fault: 11 

Оба GCC и бустер установлен с помощью Homebrew.

Системные характеристики:

OSX: 10.9.4 
GCC: 4.9.1 
Boost: 1.0.55_2 

---

Edit:

Собран с -g и установлен обработчик сигнала согласно комментарию, выход:

hello/../world 
Segfault: 
0 path-test       0x000000010ea215b8 _Z7handleri + 28 
1 libsystem_platform.dylib   0x00007fff8b9285aa _sigtramp + 26 
2 ???         0x00007fff67bdf1a1 0x0 + 140734933889441 
3 path-test       0x000000010ea2196d _ZN5boost10filesystem9canonicalERKNS0_4pathERNS_6system10error_codeE + 69 
4 path-test       0x000000010ea21518 main + 138 
5 libdyld.dylib      0x00007fff832c35fd start + 1 
6 ???         0x0000000000000001 0x0 + 1 

обработчик сигнала Segfault (Получено с this question):

void handler(int sig) 
{ 
    void *array[10]; 
    size_t size; 

    size = backtrace(array, 10); 

    fprintf(stderr, "Segfault:\n"); 
    backtrace_symbols_fd(array, size, STDERR_FILENO); 
    exit(1); 
} 

Answer 1

Вы смешиваете реализации стандартной библиотеки C++.

Boost, при установке через варево, будет скомпилирован с использованием clang++. Эта инструментальная цепочка по умолчанию использует libc++.

g++ настаивает на использовании собственного libstdc++ внедрения.

Эти реализации не совместимы с бинарными данными, в которых возникают проблемы.

Я извлек свежую копию импульса в подкаталог, сделал:

$ ./bootstrap.sh --prefix=/usr/local/boost156 cxxflags="-arch i386 -arch x86_64" address-model=32_64 threading=multi macos-version=10.9 toolset=g++-4.8 stage 

Тогда встроенным его (статический только, есть проблема сборки, где он не может сделать динамические библиотеки в этой ситуации при OSX - л.д. жалуется, что опция -h не поддерживается):

$ ./b2 --layout=tagged threading=multi link=static toolset=gcc-4.8 

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

$ g++-4.8 -g -std=c++11 -Iboost_1_56_0 -Lboost_1_56_0/stage/lib -lboost_filesystem-mt -lboost_system-mt main.cpp -o ./path-test 
$ ./path-test 
hello/../world 

$ 

В этом случае он работал отлично.

Что это значит?

• C++ библиотека на OSX является полным PITA, если вы пытаетесь смешать g++ и clang++
• потому что все clang++ код по умолчанию для строятся с libc++ вы собираетесь иметь собственные копии любого c++ библиотеки, если вы собираетесь строить их с g++
• самогон просто выполняют приказы при компиляции с clang++

это это беспорядок, но если вы придерживаетесь сарказма < > один настоящий компилятор </sarcasm >, тогда со мной все будет в порядке. TBH Я предпочитаю сообщения об ошибках clang, и статический анализ превосходный; но если вам нужно использовать g++, вам придется хранить личные копии любых c++ библиотек, которые вы хотите использовать, также скомпилированные с g++.

Answer 2

В дополнении к Petesh отличного ответа, для тех, кто борется со строительным наддувом с помощью GCC через доморощенный:

brew install boost --build-from-source --env=superenv --cc=gcc-<Your GCC version> 

Обратите внимание на --env=superenv переключателе, который является последним дополнением к Homebrew, поэтому убедитесь, что ваш квас до Дата!

Если вы работаете с проблемами и не уверены, что если импульс был скомпилирован с помощью GCC или звона, используйте otool -L на любой повышающей динамической библиотеке (.dylib файла) и искать записи libc++ или libstdc++.

Например, выполнив следующую команду после того, как я, наконец, получил это работает правильно:

otool -L /usr/local/lib/libboost_system.dylib 

Производит следующий вывод:

/usr/local/lib/libboost_system.dylib: 
    /usr/local/lib/libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0) 
    /usr/local/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.20.0) 
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) 
    /usr/local/Cellar/gcc/4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) 

Вторая запись показывает, что такой подъем Lib ссылки против ССЗ libstd++ , Если вместо этого он сказал /usr/lib/libc++.dylib, то он все еще связан с временем выполнения Clang Apple.

Обратите внимание, что использование варочной панели позволяет использовать все варианты (одиночные/мульти/статические/динамические), так как составители формулы включают патчи, чтобы убедиться, что они успешно компилируются на OSX, что не может быть базой с повышением ванили.