Переносимость с использованием c ++ 11 / последних версий g ++ (4.7 / 4.6)
В последнее время я разрабатывал программу с использованием g ++ 4.6 и g ++ 4.7. В настоящее время я пользуюсь многими возможностями C ++ 11.
Я принял это решение, думая, что смогу просто связать библиотеки вместе с программой в подкаталог и использовать LD_LIBRARY_PATH. С тех пор я обнаружил, что это вызывает мою программу в segfault. Я, наверное, должен был проверить это немного раньше, да. Похоже, что это является связанным libc.so.6, который его вызывает (возможно, другие, но определенно libc).
В прошлом я использовал эту технику, когда не было возможности установить библиотеки, и она работала нормально, но мне никогда не приходилось включать libc и libstdc ++ вместе с программой.
Есть ли способ обойти эту проблему, или мне придется откатиться к более старой версии c ++ / libc / libstdc ++? (и кошмар изменений кода, который идет с этим)
Решение
Я бы не стал полагаться на LD_LIBRARY_PATH — используйте его для тестирования или разработки, но не для производственных развертываний.
Вместо ссылки '-Wl,-rpath,$ORIGIN' создать DT_RPATH тег, содержащий $ORIGIN Это означает, что динамический компоновщик будет искать общие библиотеки в том же каталоге, что и исполняемый файл (или, например, использовать ‘-Wl, -rpath, $ ORIGIN /../ lib’ для поиска в ../lib)
Если какие-либо части вашей программы были собраны с помощью G ++ 4.7, то вам нужно использовать libstdc ++. Так из GCC 4.7 во время выполнения.
Но если проблема в libc.so.6, это не проблема GCC, и мой совет будет не пытаться связать libc … попытка заменить систему libc, вероятно, не очень хорошая идея.
Другие решения
Я бы сказал, используйте только g ++ 4.6 или 4.7, но не оба.
Также…
ldconfig попытается заставить вашу программу запустить / lib или / usr / lib версию libc.so, поэтому, если у вас есть другая, я не уверен, как это будет работать. Так что, возможно, вам стоит просто использовать систему libc.
Если у кого-то есть другие идеи, опубликуйте их тоже.
detector