The 32bit game I am using, enemy territory can not find the correct libraries for hardware acceration. I belive the problem I am seeing will effect all 32bit applications that use OpenGL Reproducible: Always Steps to Reproduce: 1. lauch xterm 1. run 'et' command Actual Results: You are using software Mesa (no hardware acceleration)! Driver DLL used: libGL.so.1 If this is intentional, add "+set r_allowSoftwareGL 1" to the command line when starting the game. Expected Results: game launches with hardware acceration :-) I got around the problem by defining the variable LIBGL_DRIVERS_PATH I have edited the script file /usr/games/bin/et and added a line: "export LIBGL_DRIVERS_PATH=/usr/lib32/modules/dri" I got this workaround info from this fourm thread: http://forums.gentoo.org/viewtopic-t-257085-view-next.html
I see the same problem, and your fix works for me too. Notes: amd64 causes >=app-emulation/emul-linux-x86-xlibs-1.0-r1 to be a RDEPEND. However, the /emul libraries are very far down on the /etc/ld.so.conf list. I tried running et with strace using this script: #!/bin/sh cd "/opt/enemy-territory" #export LIBGL_DRIVERS_PATH="/usr/lib32/modules/dri" export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:" strace ./et.x86 "$@" 2>~/et.trace Here is some partial output relating to libGL.so.1: write(2, "...loading libGL.so.1: ", 23...loading libGL.so.1: ) = 23 open("tls/i686/sse2/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i686/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/sse2/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i686/sse2/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i686/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("sse2/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 7 fstat64(0x7, 0xffffbe54) = 0 mmap2(NULL, 61838, PROT_READ, MAP_PRIVATE, 7, 0) = 0x5c0db000 close(7) = 0 open("/usr/lib32/opengl/ati/lib/libGL.so.1", O_RDONLY) = 7 read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\367"..., 512) = 512 fstat64(0x7, 0xffffbec8) = 0 mmap2(NULL, 703284, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 7, 0) = 0x5c0eb000 mmap2(0x5c18f000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 7, 0xa4) = 0x5c18f000 mmap2(0x5c194000, 11060, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x5c194000 close(7) = 0 Note that it DOES file the correct ATI OpenGL libraries. However, it still reports that Mesa GLX Indirect is used. Anyway, setting LIBGL_DRIVERS_PATH=/usr/lib32/modules/dri does solve the immediate problems, but this is not neceessary for locally-built OpenGL apps, such as various xscreensaver modules and tuxracer. Another solution is to modify /etc/env.d/09ati to include the line: LIBGL_DRIVERS_PATH=/usr/lib64/modules/dri:/usr/lib32/modules/dri and then run env-update and source /etc/profile (or logout, reboot, etc.)
It appears 8.14.13-r5 addresses this issue. However the digests are currently botched. See bug #105927.
I think the current ebuilds have had this fixed for awhile as they have multilib support and set LIBGL_DRIVERS_PATH accordingly.
I don't have gentoo install anymore, so I can not check this this is fixed. Andy can you check this is fixed, so this bug can be closed ??
Looks fixed to me. There would be many screams if it were not.
Closing.
