linux — создание закадрового контекста lib OSMesa не выполняется в C ++, но только в случае статической связи

Вот что я получаю от запуска инструмента:
Segmentation fault (core dumped)

Но ошибка сегментации не возникает, если я просто пропущу этап создания контекста OSmesa (и, очевидно, весь 3D-рендеринг)

Итак, есть проблема с созданием OSmesa. С вашей обратной трассировкой мы можем видеть, что функция top была выполнена из EIP с нуля (переход к NULL / вызов NULL), поэтому есть вызов некоторой функции в mtx_init, которая является частью создания контекста OS Mesa.

#0  0x0000000000000000 in ?? ()
#1  0x00000000004af20a in mtx_init (type=4, mtx=0xe10f70) at ../../include/c11/threads_posix.h:215
#2  _mesa_NewHashTable () at main/hash.c:135
#3  0x000000000052f295 in _mesa_alloc_shared_state (ctx=ctx@entry=0xdcc9b0) at main/shared.c:67
#4  0x000000000046e717 in _mesa_initialize_context (ctx=ctx@entry=0xdcc9b0, api=api@entry=API_OPENGL_COMPAT, visual=, share_list=share_list@entry=0x0, driverFunctions=driverFunctions@entry=0x7fffffffcd40) at main/context.c:1192
#5  0x000000000046c870 in OSMesaCreateContextAttribs (attribList=attribList@entry=0x7fffffffd290, sharelist=) at osmesa.c:834
#6  0x000000000046ccdc in OSMesaCreateContextExt (format=, depthBits=, stencilBits=, accumBits=, sharelist=) at osmesa.c:660
#7  0x0000000000468742 in generate_thumbnail(Model*, Json::Value) ()
#8  0x0000000000401c7d in main (argc=, argv=) at ./src/measure_model.cpp:107

Какая была функция? В соответствии с онлайн источники включают / c11 / threads_posix.h: mtx_init() на GitHub, есть только звонки pthread_mutex_init, pthread_mutexattr_init и несколько других связанных с мьютексом функций libpthread (-lpthread).

Почему вместо реальной функции был произведен вызов NULL? Вероятно, из-за использования статической связи glibc и / или libpthread. Точная проблема до сих пор не определена (Мне удалось найти отчет о статически связанном libpthread.a в какую-то общую библиотеку, которая неверна и никогда не будет работать).

В вашем случае есть только псевдоним (сильный) из pthread_mutex_init в glibc / nptl / pthread_mutex_init.c (строка 150) strong_alias (__pthread_mutex_init, pthread_mutex_init) и может быть некоторый слабый псевдоним символа в самом glibc, вероятно, неинициализированный. Некоторые были не правы в ваших ссылках или / и в ld возражать, и он не нашел / связать nptl/pthread_mutex_init.o (это часть архива libpthread.a) с реальным символом в конечном исполняемом файле (ld часто пропускает неиспользуемые / ненужные объекты архивов .a и не связывает их в конечный исполняемый файл), сохраняя перемещение, указывающее на NULL. Какой-то эксперт по glibc может знать, Занятый русский является одним из экспертов по SO.

Я предлагаю связывать статически только со своими внутренними библиотеками или, возможно, также с обычными несистемными библиотеками, такими как mesa (вы можете использование -Wl,-Bstatic -lyour_lib -Wl,-Bdynamic варианты временного изменения связи со статической для библиотек, перечисленных между; или используйте чит-опцию -l: как -l:libYour_lib.a найден Радеком в том же д.). Но не связывайте статически с большинством базовых библиотек glibc, таких как libc, libpthread, librt (существуют некоторые проблемы статического связывания glibc, когда используется nss: целевая система должна иметь точно такую ​​же версию динамического glibc, чтобы nss работал).

Если вы хотите упаковать свое приложение для более старых машин и вам нужны некоторые функции glibc, вы можете также попытаться упаковать свою собственную версию совместно используемых библиотек glibc с вашим приложением; поместите их в некоторый подкаталог, добавьте rpath возможность компоновщика изменить пути поиска в библиотеке, а также изменить Раздел INTERP по умолчанию ABI ld-linux.so.2 загрузите вашу собственную копию ld-linux.so.2 из вашей версии glibc, … И у вас все еще будут проблемы со слишком старыми ядрами, поскольку для новых glibcs ​​требуются некоторые современные функции (системные вызовы, структуры) относительно нового ядра.

Или вы можете упаковать свое приложение в какой-то контейнер, такой как Docker, или какой-то другой изоляция решение (или chroot?), чтобы всегда иметь ваши версии библиотек …

ОБНОВЛЕНИЕ: Просто найденный отчет о подобном bt с NULL вместо реализации мьютекса из nptl: https://bugzilla.redhat.com/show_bug.cgi?id=163083 «Статически связанная программа на C ++ с использованием pthreads приведет к сбою» (2005-2007) pthread_mutex_init(&lock, NULL); g++ -g -static foo.cpp -o foo -lpthread where #0 0x00000000 in ?? () #1 0x08048232 in main () at foo.cpp:7

По-видимому, это связано с тем, что некоторые функции pthreads не включены в исполняемый файл вывода. Эта ошибка может дублировать # 115157, и я прошу прощения, если так, но, надеюсь, включенный тестовый пример будет полезен.

Дополнительная информация:

Предложение в # 115157 принудительно ссылаться во всех файлах libpthread.a является допустимым обходным решением.

https://bugzilla.redhat.com/show_bug.cgi?id=115157 «исполняемые файлы, статически связанные с /usr/lib/nptl/libpthread.a fail» — 2004-2009 CLOSED WONTFIX

Jakub Jelinek 2004-10-29 05:26:10 ПО ВОСТОЧНОМУ ВРЕМЕНИ

Прежде всего, избегайте -static если вы можете, это только создает проблемы,
как с точки зрения мобильности, так и с другими.

Если вам действительно нужно создать статически связанный бинарный файл с -lpthread
связаны, то просто используйте -Wl,--whole-archive -lpthread -Wl,--no-whole-archive
вместо -pthread. У всего остального действительно много проблем.