Summary: | >=media-libs/mesa-9.2.1[gallium,llvm-shared-libs,video_cards_intel]: i915g: libLLVM-3.3.so: cannot open shared object file: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mao PU <mao.c.pu> |
Component: | [OLD] GNOME | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander, EoD, gnome, mgorny, nikoli |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 500368 | ||
Attachments: | Xorg.0.log with mesa-9.2.1 |
Description
Mao PU
2013-10-16 11:42:47 UTC
Which graphics chipset / driver do you use? Also provide "emerge -Opv gnome-shell cogl" output # emerge -Opv gnome-shell cogl These are the packages that would be merged, in order: [ebuild R ] gnome-base/gnome-shell-3.8.4-r1 USE="i18n -bluetooth -networkmanager (-openrc-force)" PYTHON_TARGETS="python2_7 -python2_6" 0 kB [ebuild R ] media-libs/cogl-1.14.1_pre20130901:1.0/12 USE="introspection opengl pango -debug -examples -gles2 {-test}" 1,449 kB Total: 2 packages (2 reinstalls), Size of downloads: 1,449 kB (In reply to Chí-Thanh Christopher Nguyễn from comment #1) > Which graphics chipset / driver do you use? This info is also needed for sure, also /var/log/Xorg.0.log, you can also look to journalctl for related error messages > System uname: Linux-3.11.3-gentoo-i686-Intel-R-_Core-TM-2_CPU_T5600_@_1.83GHz-with-gentoo-2.2
> ...
>VIDEO_CARDS="intel i915"
i915 with a Core 2? Seems unlikely. Are you sure you're not using the software rasterizer?
I use the following (lshw): display:0 description: VGA compatible controller product: Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller vendor: Intel Corporation physical id: 2 bus info: pci@0000:00:02.0 version: 03 width: 32 bits clock: 33MHz capabilities: msi pm vga_controller bus_master cap_list rom configuration: driver=i915 latency=0 resources: irq:11 memory:eff00000-eff7ffff ioport:eff8(size=8) memory:d0000000-dfffffff memory:efec0000-efefffff Created attachment 361374 [details]
Xorg.0.log with mesa-9.2.1
...and
# cat /proc/cpuinfo
[...]model name : Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz[...]
So yes, in my case its a i915 with Core2 which works on mesa-9.2.0 with a configuration that does not on mesa-9.2.1.
What seems interesting on Xorg.0.log are the following lines:
[ 80.540] (EE) AIGLX error: dlopen of /usr/lib/dri/i915_dri.so failed (libLLVM-3.3.so: cannot open shared object file: No such file or directory)
[ 80.540] (EE) AIGLX: reverting to software rendering
What does that mean? How to solve the problem? Is there a (temporary) workaround?
Maybe "revdep-rebuild" could help No, that does not help. revdep-rebuild does not pick up on any missing dependency: revdep-rebuild -i -- -a * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 100% ] * Dynamic linking on your system is consistent... All done. Are you getting X11 from some overlay? http://forums.gentoo.org/viewtopic-p-7318268.html (In reply to Pacho Ramos from comment #10) > Are you getting X11 from some overlay? > http://forums.gentoo.org/viewtopic-p-7318268.html I'm actually having similar issue (one suspect could be gcc-4.8 upgrade). xorg packages are all from main tree. x11-libs/libdrm-2.4.47 USE="libkms -static-libs" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="intel (-exynos) (-freedreno) -nouveau (-omap) -radeon -vmware" sys-devel/llvm-3.3-r1:0/3.3 USE="clang libffi static-analyzer -debug -doc -gold -multitarget -ocaml -python {-test} -udis86" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7 -pypy2_0 -python2_6" VIDEO_CARDS="-radeon" media-libs/mesa-9.2.1 USE="bindist classic egl gallium gbm llvm nptl openvg xa xvmc -debug -gles1 -gles2 -opencl -osmesa -pax_kernel -pic -r600-llvm-compiler (-selinux) -vdpau -wayland -xorg" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="intel (-freedreno) -i915 -i965 -ilo -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi -vmware" x11-base/xorg-server-1.14.3-r2:0/1.14.3 USE="ipv6 kdrive nptl suid udev xorg xvfb -dmx -doc -minimal (-selinux) -static-libs -tslib -xnest" 5,374 kB x11-drivers/xf86-video-intel-2.99.903 USE="dri glamor sna udev xvmc -uxa" (In reply to Priit Laes (IRC: plaes) from comment #11) > (In reply to Pacho Ramos from comment #10) > > Are you getting X11 from some overlay? > > http://forums.gentoo.org/viewtopic-p-7318268.html > > I'm actually having similar issue (one suspect could be gcc-4.8 upgrade). > xorg packages are all from main tree. > Also, simple way to detect this issue: plaes@chi ~/code/procom $ LIBGL_DEBUG=verbose glxgears libGL: OpenDriver: trying /usr/lib64/dri/tls/i915_dri.so libGL: OpenDriver: trying /usr/lib64/dri/i915_dri.so libGL error: dlopen /usr/lib64/dri/i915_dri.so failed (libLLVM-3.3.so: cannot open shared object file: No such file or directory) libGL error: unable to load driver: i915_dri.so libGL error: driver pointer missing libGL error: failed to load driver: i915 libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so And some debugging... plaes@chi ~ $ ldd /usr/lib64/mesa/i915g_dri.so linux-vdso.so.1 (0x00007fff6d16d000) libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f7ae86a6000) libdrm_intel.so.1 => /usr/lib64/libdrm_intel.so.1 (0x00007f7ae8485000) libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007f7ae8278000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7ae805b000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f7ae7e57000) libLLVM-3.3.so => not found libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/libstdc++.so.6 (0x00007f7ae7b4e000) libm.so.6 => /lib64/libm.so.6 (0x00007f7ae7851000) libc.so.6 => /lib64/libc.so.6 (0x00007f7ae74a5000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/libgcc_s.so.1 (0x00007f7ae728e000) libpciaccess.so.0 => /usr/lib64/libpciaccess.so.0 (0x00007f7ae7085000) /lib64/ld-linux-x86-64.so.2 (0x00007f7ae9293000) libz.so.1 => /lib64/libz.so.1 (0x00007f7ae6e6e000) plaes@chi ~ $ qlist llvm |grep libLLVM-3.3 /usr/lib64/llvm/libLLVM-3.3.so plaes@chi ~ $ ldd /usr/lib64/llvm/libLLVM-3.3.so linux-vdso.so.1 (0x00007ffff2195000) libz.so.1 => /lib64/libz.so.1 (0x00007f2321da5000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2321b87000) libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007f232197f000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f232177b000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/libstdc++.so.6 (0x00007f2321472000) libm.so.6 => /lib64/libm.so.6 (0x00007f2321175000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/libgcc_s.so.1 (0x00007f2320f5e000) libc.so.6 => /lib64/libc.so.6 (0x00007f2320bb2000) /lib64/ld-linux-x86-64.so.2 (0x00007f232317e000) plaes@chi ~ $ strace -e open glxgears 2>&1 |egrep -e '(LLVM|error)' open("/lib64/tls/x86_64/libLLVM-3.3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib64/tls/libLLVM-3.3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib64/x86_64/libLLVM-3.3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib64/libLLVM-3.3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/x86_64/libLLVM-3.3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/libLLVM-3.3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/x86_64/libLLVM-3.3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/libLLVM-3.3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) libGL error: failed to load driver: i915 libGL error: Try again with LIBGL_DEBUG=verbose for more details. open("/usr/lib64/llvm/libLLVM-3.3.so", O_RDONLY|O_CLOEXEC) = 4 I am also not using xorg from an overlay, currently xorg-server-1.14.3-r2. I can verify, that I see a similar issue with glxgears: # LIBGL_DEBUG=verbose glxgears libGL: OpenDriver: trying /usr/lib/dri/tls/i915_dri.so libGL: OpenDriver: trying /usr/lib/dri/i915_dri.so libGL error: dlopen /usr/lib/dri/i915_dri.so failed (libLLVM-3.3.so: cannot open shared object file: No such file or directory) libGL error: unable to load driver: i915_dri.so libGL error: driver pointer missing libGL error: failed to load driver: i915 libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so On my system I had the same problem, these steps solved it: # echo 'LDPATH=/usr/lib64/llvm' > /etc/env.d/99llvm # env-update # ldconfig and then, restart X. If it's right, the llvm ebuild should do the same when installing. (In reply to Chí-Thanh Christopher Nguyễn from comment #1) > Which graphics chipset / driver do you use? I have two systems using identical gentoo binaries and config settings. Only one system is effected by this bug. One is a desktop system using an A10 Richland AMD APU. Works fine. The other is a laptop using an A6 Piledriver APU. It will only have working OpenGL if I revert to the previous version of mesa. (9.2.0-r1) Adding the path to llvm to $LDPATH seems to solve the issue. In my case (32bit system) the statement was of course: # echo 'LDPATH=/usr/lib/llvm' > /etc/env.d/99llvm After Xorg restart, I don't see the AIGLX-Error specified in Comment 7 any more. Instead I see [ 63793.692] (II) AIGLX: Loaded and initialized i915 Also glxgears starts up without the error descibed at Comment 13. For my understanding: So this is rather an llvm-error which just surfaced with mesa? This could be related to bug 474450. For i915, another workaround would be to switch from gallium to classic with "eselect mesa". The issue is due to i915g dynamically linking to libLLVM-3.3.so when --enable-llvm-shared-libs is passed to configure. Unlike the other drivers (r300g, r600g, llvmpipe) which appear to have correct RPATH according to objdump -x, i915g does not. If this is related to bug 474450, then llvm-3.3-r1 does not solve it (I have llvm-3.3-r1 installed sind 2013-09-10) -- or it is another issue. In the first case one might reopen bug 474450, in the latter case we are looking for another cause... How can I help to solve this problem? It is only related to that bug, but will need its own fix. The current workaround is to drop --enable-llvm-shared-libs or switch i915 to classic with eselect mesa. For properly fixing this, a patch is needed to set correct RPATH in src/gallium/drivers/i915/Makefile.am I hit the same bug using VirtualBox with swrast. [ 124.451] (II) Next line is added to allow vboxvideo_drv.so to appear as whitelisted driver [ 124.451] (II) The file referenced, is *NOT* loaded [ 124.451] (II) Loading /usr/lib/xorg/modules/drivers//ati_drv.so [ 124.451] (EE) AIGLX error: vboxvideo does not export required DRI extension [ 124.451] (EE) AIGLX: reverting to software rendering [ 124.452] (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (libLLVM-3.3.so: cannot open shared object file: No such file or directory) [ 124.452] (EE) GLX: could not load software renderer [ 124.452] (II) GLX: no usable GL providers found for screen 0 Basically, it does dlopen() (which is why my QA scripts didn't catch it earlier), so in this case llvm is also a runtime dependency (and not just build time). (In reply to Chí-Thanh Christopher Nguyễn from comment #21) > It is only related to that bug, but will need its own fix. > > The current workaround is to drop --enable-llvm-shared-libs or switch i915 > to classic with eselect mesa. > > For properly fixing this, a patch is needed to set correct RPATH in > src/gallium/drivers/i915/Makefile.am Is it that it's missing $(LLVM_CFLAGS) from AM_CFLAGS? (In reply to Matt Turner from comment #23) > (In reply to Chí-Thanh Christopher Nguyễn from comment #21) > > It is only related to that bug, but will need its own fix. > > > > The current workaround is to drop --enable-llvm-shared-libs or switch i915 > > to classic with eselect mesa. > > > > For properly fixing this, a patch is needed to set correct RPATH in > > src/gallium/drivers/i915/Makefile.am > > Is it that it's missing $(LLVM_CFLAGS) from AM_CFLAGS? More likely $(LLVM_LDFLAGS) which sets the RPATH. LLVM_CFLAGS doesn't help much. llvm-shared-libs is now optional in >=mesa-9.2.4 I've just removed the "llvm" sub-dir in llvm-9999, effectively fixing all the issues caused by it. If noone shouts at me, I will either use that in 3.4 release when it comes out or backport as 3.3-r2. *llvm-3.3-r2 (28 Dec 2013) 28 Dec 2013; Michał Górny <mgorny@gentoo.org> +files/llvm-3.3-r2-gentoo-install.patch, +llvm-3.3-r2.ebuild: Backport all the fixes and install design changes from -9999 to -3.3. Fixes bugs #425844 (install CMake modules), #462554 (install bfd-plugins symlink), #489586 (multilib portage compat.), #488216, #492554 (RPATH issues). I'd suggest the following course of action for mesa: 1. depend on >=3.3-r2, 2. replace the conditional LLVM_CONFIG=llvm-config.${ABI} with LLVM_CONFIG=${CHOST}-llvm-config (I'd like to remove the .${ABI} hack from llvm soon), or wait till [1] is fixed upstream, 3. force shared libs :). [1]:https://bugs.freedesktop.org/show_bug.cgi?id=73100 Just FYI, the AC_PATH_TOOL patch has been merged upstream, and will probably make it to the stable branch. (In reply to Michał Górny from comment #28) > Just FYI, the AC_PATH_TOOL patch has been merged upstream, and will probably > make it to the stable branch. It has been merged to 10.0 stable branch and is in the 10.0.3 release. http://cgit.freedesktop.org/mesa/mesa/commit/?h=10.0&id=dbc0ae1079d6ce5349b25a86a91c78371c226809 Fixed in 9.2.5-r1 and 10.0.3 |