Страница 1 из 2
Проблема с Nvidia libGL
Добавлено: 29 июл 2006, 16:00
michael
При установке драйверов nVidia все приложения слинкованные с libGL вылетают с segmentation fault. Даже простейшая программа test.c
скомпилированная с -lGL тоже сегфолтится. Я думал, может я glibc или иксы как-то не так собрал, взял готовые rpm от ASPа, скопировал все нужные библиотеки в отдельный каталог и запускал с тот же test с установленным LD_LIBRARY_PATH.
Вот вывод команды LD_LIBRARY_PATH=. ldd ./test
Код: Выделить всё
libGL.so.1 => ./libGL.so.1 (0x00002b55c8b37000)
libGLcore.so.1 => ./libGLcore.so.1 (0x00002b55c8ced000)
libnvidia-tls.so.1 => ./libnvidia-tls.so.1 (0x00002b55c956c000)
libc.so.6 => ./libc.so.6 (0x00002b55c966d000)
libm.so.6 => ./libm.so.6 (0x00002b55c98a1000)
libXext.so.6 => ./libXext.so.6 (0x00002b55c9a27000)
libX11.so.6 => ./libX11.so.6 (0x00002b55c9b38000)
libdl.so.2 => ./libdl.so.2 (0x00002b55c9d32000)
/lib64/ld-linux-x86-64.so.2 (0x00002b55c8a21000)
/lib64/ld-linux-x86-64.so.2 это симлинк на ./ld-2.3.4.so
Все равно test завершается с segfault. Проблема, похоже, не в библиотеках. Куда копать?
Добавлено: 30 июл 2006, 19:46
booxter
А што за дыстрыбутыў, што ты glibc перазбіраў самастойна?:/
Добавлено: 30 июл 2006, 21:12
michael
LFS
Добавлено: 30 июл 2006, 21:54
booxter
А якія параметры кампілятара і яго версія?
Добавлено: 31 июл 2006, 09:24
michael
В смысле, параметры компилятора? Сейчас gcc 4.1.0. Собирал систему также с gcc 3.3.6, имел те же грабли.
Добавлено: 31 июл 2006, 12:18
booxter
А што за libGL? Xorg? Xfree? ATI? Nvidia?
Добавлено: 31 июл 2006, 14:47
michael
libGL NVidia. Версии пробовал разные. Xorg 6.9.0. Пробовал XFree86 4.4.0 и 4.5.0, та же фигня. Сейчас у меня x86_64, но была сборка и на i386 с той же проблемой. Я подозреваю, что дело не в библиотеках или компиляторе (блин, глюк даже с дистрибутивными библиотеками наблюдается), а либо в каких-нибудь конфигах, либо в настройках ядра.
Добавлено: 03 авг 2006, 09:43
michael
Код: Выделить всё
(gdb) bt
#0 0x00002ae5b7a20650 in memset () from ./libc.so.6
#1 0x00002ae5b75f86fe in _nv000380gl () from ./libGLcore.so.1
#2 0x00002ae5b75f92ae in _nv000367gl () from ./libGLcore.so.1
#3 0x00002ae5b738b362 in _nv000361gl () from ./libGLcore.so.1
#4 0x00002ae5b6ece3a2 in _init () from ./libGL.so.1
#5 0x00002ae5b6d6ecaf in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#6 0x00002ae5b6d64abb in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#7 0x0000000000000001 in ?? ()
#8 0x00007ffff3d45d31 in ?? ()
#9 0x0000000000000000 in ?? ()
Добавлено: 08 авг 2006, 03:13
michael
Никто помочь не может?
Добавлено: 08 авг 2006, 09:45
fa3a
дай file ./libGLcore.so.1, file ./libGL.so и file ./libc.so.6 (если симлинки, то соответсвенно повторить комманду file на реальный объект).. Проблема похоже связана с отсутсвием 64-битных либ.
Добавлено: 08 авг 2006, 16:06
michael
Код: Выделить всё
libGL.so.1.0.8762: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped
libGLcore.so.1.0.8762: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped
libc-2.3.4.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, not stripped
Это не родная libc, а взятая с ASP'а забыл какого. Вроде у них только одна 64-битная версия была. С родной libc эффект тот же.
Эффект тот же и для 32-битной сборки.
Код: Выделить всё
> i686-pc-linux-gnu-gcc -o test -L. -L/usr/lib32 -lGL -lGLcore -lnvidia-tls test.c
> LD_LIBRARY_PATH=. ldd ./test
linux-gate.so.1 => (0xffffe000)
libGL.so.1 => ./libGL.so.1 (0xf7ee8000)
libGLcore.so.1 => ./libGLcore.so.1 (0xf7726000)
libnvidia-tls.so.1 => ./libnvidia-tls.so.1 (0xf7724000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7706000)
libc.so.6 => /usr/lib32/libc.so.6 (0xf75c1000)
libm.so.6 => /usr/lib32/libm.so.6 (0xf7598000)
libXext.so.6 => /usr/lib32/libXext.so.6 (0xf758a000)
libX11.so.6 => /usr/lib32/libX11.so.6 (0xf74c5000)
libdl.so.2 => /usr/lib32/libdl.so.2 (0xf74c1000)
/lib/ld-linux.so.2 (0xf7f6e000)
libXau.so.6 => /opt/32/lib/libXau.so.6 (0xf74be000)
libXdmcp.so.6 => /opt/32/lib/libXdmcp.so.6 (0xf74b8000)
> LD_LIBRARY_PATH=. ./test
Segmentation fault
Может кто-нибудь проверить работу бинарников test на своей системе? Они маленькие, 32-битный - ~6kb, а 64-битный - ~8kb. Именно с libGL от Nvidia, так как с Mesa всё работает.
Добавлено: 08 авг 2006, 16:33
fa3a
если ты сравнишь два своих ldd outputs для 64-bit и 32-bit, то заметишь одно явное отличие, а именно -- в 64-битном остутсвует
linux-gate.so.1. Да и адрес у нее странноватый:
linux-gate.so.1 => (0xffffe000)
Вообще говоря linux-gate.so.1 это т.н. DSO (dynamically shared object):
this DSO is all about: it's a gateway between user and kernel
space.
Короче копай зачем OpenGL ее пытается юзать. Вот линк, который я случайно обнаружил на каком-то румынском или вообще албанском сайте
common name for the kernel DSO
Добавлено: 08 авг 2006, 16:55
ZvK
linux-gate.so.1 -- это виртуальная .so, которая делается кернелом для реализации vsyscall. Дело в том, что сисколы на x86 могут быть реализованы через int 0x80, а могут через более быструю инструкцию, которая появилась в более поздних процессорах. Ядро процессор знает и подставляет нужный вариант вызова, libc же использует только vsyscall.
Нормальный у нее адрес.
Добавлено: 08 авг 2006, 17:31
fa3a
ZvK, согласно линку, который я привел выше:
Both x86 and ia64 now provide a dynamically shared object (DSO) for
system call purposes (e.g., to speed up system calls and for signal
trampoline/sigreturn purposes). At the moment, the names of these
DSOs are different:
x86: linux-vsyscall.so.1
ia64: linux-gate.so.1
я так понимаю, что AMD x86-64 это совсем не IA64.. может должна была грузиться linux-vsyscall.so.1? Хотя документ датирован 2003 годом..
Добавлено: 08 авг 2006, 17:34
fa3a
michael, кстати, интересно кору и для 32-bit версии посмотреть..