Я создавал библиотеку C ++, которую я хочу распространять в виде единого файла .so для своих пользователей, и, надеюсь, этот файл .so будет, по большей части, независимым от дистрибутивов. Таким образом, я статически связывал сторонние библиотеки (но все еще динамически связывал со стандартной библиотекой)
Сейчас он прекрасно работает с g ++ на CentOS 6.2 (64-битной), но у него есть проблемы, связанные с CentOS 5.3. Компиляция проходит нормально, но я получаю ошибку компоновщика:
cpu_timer.cpp:(.text+0x288): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<long double>(long double)'
Я провел некоторый поиск ошибки, и похоже, что проблема связана с управлением версиями самой стандартной библиотеки. Мой код, точнее код boost :: thread, пытается вызвать более новую версию чего-то, чего нет в стандартной библиотеке, включенной в CentOS 5.3.
Понятный. Поэтому мне нужно либо:
- Статическая связь со стандартной библиотекой C ++ (я провел некоторые исследования по этому поводу, и это очень беспокоит 64-битные системы. Libstdc ++. A, включенный в большинство 64-битных систем, не собран с -fPIC, и -fPIC на самом деле является необходимостью для статической компоновки на 64-битных системах . Мне бы пришлось на самом деле собрать libstdc ++. a самостоятельно. Тьфу ...
- Вернуть boost :: timer к более совместимой версии. Я в основном использую его для переносимых мьютексов, поэтому мне не нужны передовые функции boost :: thread. Но это связано со своей проблемой: где на веб-сайте Boost они документируют свои зависимости в стандартной библиотеке (и в каких версиях). Они документируют это вообще? Я не могу найти информацию. Кроме того, это мудрый выбор? Какие еще неприятные сюрпризы может принести мне стандартная библиотека?
Учитывая мою цель (как можно ближе к дистрибутивной агностике), какой маршрут вы бы порекомендовали?