> ldd -a /usr/local/lib/vdpau/libvdpau_r600.so /usr/local/lib/vdpau/libvdpau_r600.so: libX11-xcb.so.1 => /usr/local/lib/libX11-xcb.so.1 (0x80197d000) libX11.so.6 => /usr/local/lib/libX11.so.6 (0x801b7e000) libxcb-dri2.so.0 => /usr/local/lib/libxcb-dri2.so.0 (0x801eb7000) libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x8020bb000) libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x8022da000) libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x802501000) libz.so.6 => /lib/libz.so.6 (0x80270e000) libthr.so.3 => /lib/libthr.so.3 (0x802924000) libncurses.so.8 => /lib/libncurses.so.8 (0x802b49000) libelf.so.1 => /usr/lib/libelf.so.1 (0x802d96000) libdrm_radeon.so.1 => /usr/local/lib/libdrm_radeon.so.1 (0x802fab000) libLLVM-3.4.so => /usr/local/llvm34/lib/libLLVM-3.4.so (0x8031b6000) libc++.so.1 => /usr/lib/libc++.so.1 (0x804b4a000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x804e0c000) libm.so.5 => /lib/libm.so.5 (0x805028000) libc.so.7 => /lib/libc.so.7 (0x80081f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80524f000) /usr/local/lib/libX11-xcb.so.1: libX11.so.6 => /usr/local/lib/libX11.so.6 (0x801b7e000) libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x8020bb000) librpcsvc.so.5 => /usr/lib/librpcsvc.so.5 (0x80545d000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/lib/libX11.so.6: libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x8020bb000) librpcsvc.so.5 => /usr/lib/librpcsvc.so.5 (0x80545d000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/lib/libxcb-dri2.so.0: libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x8020bb000) libpthread-stubs.so.0 => /usr/local/lib/libpthread-stubs.so.0 (0x805666000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/lib/libxcb.so.1: libXau.so.6 => /usr/local/lib/libXau.so.6 (0x805867000) libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x805a69000) libpthread-stubs.so.0 => /usr/local/lib/libpthread-stubs.so.0 (0x805666000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/lib/libexpat.so.6: libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/lib/libdrm.so.2: libc.so.7 => /lib/libc.so.7 (0x80081f000) /lib/libz.so.6: libc.so.7 => /lib/libc.so.7 (0x80081f000) /lib/libthr.so.3: libc.so.7 => /lib/libc.so.7 (0x80081f000) /lib/libncurses.so.8: libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/lib/libelf.so.1: libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/lib/libdrm_radeon.so.1: libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x802501000) libpthread-stubs.so.0 => /usr/local/lib/libpthread-stubs.so.0 (0x805666000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/llvm34/lib/libLLVM-3.4.so: libz.so.6 => /lib/libz.so.6 (0x80270e000) libthr.so.3 => /lib/libthr.so.3 (0x802924000) libncurses.so.8 => /lib/libncurses.so.8 (0x802b49000) libm.so.5 => /lib/libm.so.5 (0x805028000) libc++.so.1 => /usr/lib/libc++.so.1 (0x804b4a000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x804e0c000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80524f000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/lib/libc++.so.1: libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x804e0c000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80524f000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /lib/libcxxrt.so.1: libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80524f000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /lib/libm.so.5: libc.so.7 => /lib/libc.so.7 (0x80081f000) /lib/libgcc_s.so.1: libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/lib/librpcsvc.so.5: libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/lib/libpthread-stubs.so.0: libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/lib/libXau.so.6: libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/lib/libXdmcp.so.6: libc.so.7 => /lib/libc.so.7 (0x80081f000)
Maintainers CC'd
add kwm@ explicitly too.
Created attachment 149018 [details] convert from BUILD_ to LIB_ depends I think this would do.
(In reply to arcade from comment #3) > Created attachment 149018 [details] > convert from BUILD_ to LIB_ depends > > I think this would do. I'd suggest to add --with-llvm-shared-libs to CONFIGURE_ARGS so that the Gallium drivers are linked with the shared libLLVM as well. I've been doing this for several months (with the stuff from the experimental xorg repo). There's a huge difference in file sizes, and pkg takes (or used to take?) considerably less time to make a binary (backup-) package in this case.
(In reply to wjenkner from comment #4) > (In reply to arcade from comment #3) > > Created attachment 149018 [details] > > convert from BUILD_ to LIB_ depends > > > > I think this would do. > > I'd suggest to add --with-llvm-shared-libs to CONFIGURE_ARGS so that the > Gallium drivers are linked with the shared libLLVM as well. I've been doing > this for several months (with the stuff from the experimental xorg repo). > There's a huge difference in file sizes, and pkg takes (or used to take?) > considerably less time to make a binary (backup-) package in this case. I'm not sure this is related. But felt I should post here, before opening a new pr(1). I am unable to build graphics/dri on a recent 11-CURRNET. In the past (on RELENG_9), I could overcome this issue (using gcc, not clang), by modifying the conditional in the Makefile to both being USE_GCC=yes But this won't fire on 11, because it only looks to 10(ish) as the top. modifying the conditional to seek upwards to infinity _did_ get it to continue quite a ways into the process. But ultimately failed at: CC libvdpau_gallium_la-target.lo CXXLD libvdpau_gallium.la ../../../../src/gallium/auxiliary/.libs/libgallium.a(lp_bld_misc.o):(.data.rel.r o._ZTV26DelegatingJITMemoryManager[_ZTV26DelegatingJITMemoryManager]+0x40): unde fined reference to `llvm::RTDyldMemoryManager::getSymbolAddress(std::string cons t&)' ../../../../src/gallium/auxiliary/.libs/libgallium.a(lp_bld_misc.o):(.data.rel.r o._ZTV19ShaderMemoryManager[_ZTV19ShaderMemoryManager]+0x40): undefined referenc e to `llvm::RTDyldMemoryManager::getSymbolAddress(std::string const&)' collect2: error: ld returned 1 exit status Makefile:743: recipe for target 'libvdpau_gallium.la' failed gmake[8]: *** [libvdpau_gallium.la] Error 1 gmake[8]: Leaving directory '/usr/ports/graphics/dri/work/Mesa-10.3.2/src/galliu m/targets/vdpau' Makefile:549: recipe for target 'all-recursive' failed gmake[7]: *** [all-recursive] Error 1 gmake[7]: Leaving directory '/usr/ports/graphics/dri/work/Mesa-10.3.2/src/galliu m' Makefile:518: recipe for target 'all-recursive' failed gmake[6]: *** [all-recursive] Error 1 gmake[6]: Leaving directory '/usr/ports/graphics/dri/work/Mesa-10.3.2/src' Makefile:585: recipe for target 'all-recursive' failed gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory '/usr/ports/graphics/dri/work/Mesa-10.3.2' ===> Compilation failed unexpectedly. I'm not sure where exactly to go from here. FWIW uname 11-CURRENT #1 r274134 Nov 5 12:56:14 PST 2014 amd64 svn info /usr/ports Revision: 372176 Thank you for all your time, and consideration. --Chris
(In reply to arcade from comment #3) > Created attachment 149018 [details] > convert from BUILD_ to LIB_ depends > > I think this would do. Applying the patch above didn't make it any more possible to build graphics/dri. It resulted in the same error (failure) I pasted the output from, above. Thanks again, for all your time, and consideration. --Chris
OK I got a little closer to getting graphics/dri installed by unticking GALLIUM in the config dialog (and VDPAU ticked). I was able to successfully get it built, but fails at the end of the make(1) process with: gmake[6]: Leaving directory '/usr/ports/graphics/dri/work/Mesa-10.3.2' gmake[5]: Leaving directory '/usr/ports/graphics/dri/work/Mesa-10.3.2' ====> Compressing man pages (compress-man) ===> Installing for dri-10.3.2,2 ===> Checking if dri already installed ===> Registering installation for dri-10.3.2,2 as automatic pkg-static: lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/vdpau/libvdpa u_r600.so): No such file or directory pkg-static: lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/vdpau/libvdpa u_r600.so.1): No such file or directory pkg-static: lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/vdpau/libvdpa u_r600.so.1.0): No such file or directory pkg-static: lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/vdpau/libvdpa u_r600.so.1.0.0): No such file or directory pkg-static: lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/vdpau/libvdpa u_radeonsi.so): No such file or directory pkg-static: lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/vdpau/libvdpa u_radeonsi.so.1): No such file or directory pkg-static: lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/vdpau/libvdpa u_radeonsi.so.1.0): No such file or directory pkg-static: lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/vdpau/libvdpa u_radeonsi.so.1.0.0): No such file or directory *** Error code 74 This was with the diff(1) provided by arcade@, above. Thank you for all your time, and consideration. --Chris
Created attachment 149161 [details] same as first one but adds --with-llvm-shared-libs
The original problem is fixed in our development ports tree. It should be committed in the coming week hopefully. (In reply to C Hutchinson from comment #7) > OK I got a little closer to getting graphics/dri installed by unticking > GALLIUM in the config dialog (and VDPAU ticked). I was able to > successfully get it built, but fails at the end of the make(1) > process with: > > gmake[6]: Leaving directory '/usr/ports/graphics/dri/work/Mesa-10.3.2' > gmake[5]: Leaving directory '/usr/ports/graphics/dri/work/Mesa-10.3.2' > ====> Compressing man pages (compress-man) > ===> Installing for dri-10.3.2,2 > ===> Checking if dri already installed > ===> Registering installation for dri-10.3.2,2 as automatic > pkg-static: > lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/vdpau/libvdpa > u_r600.so): No such file or directory VDPAU depends on Gallium. Therefore, when Gallium is disabled, Mesa doesn't build VDPAU. In our development tree, VDPAU now requires Gallium (and fails to build otherwise).
(In reply to Jean-Sebastien Pedron from comment #9) > The original problem is fixed in our development ports tree. It should be > committed in the coming week hopefully. > > (In reply to C Hutchinson from comment #7) > > OK I got a little closer to getting graphics/dri installed by unticking > > GALLIUM in the config dialog (and VDPAU ticked). I was able to > > successfully get it built, but fails at the end of the make(1) > > process with: > > > > gmake[6]: Leaving directory '/usr/ports/graphics/dri/work/Mesa-10.3.2' > > gmake[5]: Leaving directory '/usr/ports/graphics/dri/work/Mesa-10.3.2' > > ====> Compressing man pages (compress-man) > > ===> Installing for dri-10.3.2,2 > > ===> Checking if dri already installed > > ===> Registering installation for dri-10.3.2,2 as automatic > > pkg-static: > > lstat(/usr/ports/graphics/dri/work/stage/usr/local/lib/vdpau/libvdpa > > u_r600.so): No such file or directory > > VDPAU depends on Gallium. Therefore, when Gallium is disabled, Mesa doesn't > build VDPAU. > > In our development tree, VDPAU now requires Gallium (and fails to build > otherwise). Shouldn't OPTIONS reconcile this?
(In reply to C Hutchinson from comment #10) > (In reply to Jean-Sebastien Pedron from comment #9) > > In our development tree, VDPAU now requires Gallium (and fails to build > > otherwise). > > Shouldn't OPTIONS reconcile this? I'm a newbie with the ports framework and I don't know if dependencies can be expressed with OPTIONS. In our development tree, we mark the graphics/dri as "IGNORE" if VDPAU is selected but not GALLIUM. Also, VDPAU is disabled by default, because currently, the Radeon kernel drivers doesn't support hardware-assisted video decoding (and Gallium/VDPAU doesn't support the Intel driver).
A commit references this bug: Author: kwm Date: Fri Nov 21 11:34:06 UTC 2014 New revision: 372988 URL: https://svnweb.freebsd.org/changeset/ports/372988 Log: Update mesa to 10.3.3. graphics/dri: Move gettext:build to bsd.mesalib.mk so it present for all mesa ports. [1] VDPAU needs GALLIUM so check for that, since it a Gallium state tracker. [1][2] Rework llvm33/llvm34 selection so we can use the llvm version later on. VDPAU links against the llvm libraries so we need to depend on the llvm port as a run dependency .[1] After discussion remove the VDPAU option for now. Radeon kernel drivers currently don't support hardware-assisted video decoding. And Gallium/VDPAU doesn't support the intel driver. PR: 194655 [1] PR: 194580 [2] Changes: head/graphics/dri/Makefile head/graphics/libGL/bsd.mesalib.mk head/graphics/libGL/distinfo
I must say this one is not fixed yet. After building the updated version I get: /usr/local/lib/dri/kms_swrast_dri.so: libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x801e6a000) libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x802091000) libelf.so.1 => /usr/lib/libelf.so.1 (0x80229e000) libdrm_radeon.so.1 => /usr/local/lib/libdrm_radeon.so.1 (0x8024b3000) libz.so.6 => /lib/libz.so.6 (0x8026be000) libthr.so.3 => /lib/libthr.so.3 (0x8028d4000) libncurses.so.8 => /lib/libncurses.so.8 (0x802af9000) libLLVM-3.4.so => /usr/local/llvm34/lib/libLLVM-3.4.so (0x802d46000) libc++.so.1 => /usr/lib/libc++.so.1 (0x8046f0000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8049b2000) libm.so.5 => /lib/libm.so.5 (0x804bce000) libc.so.7 => /lib/libc.so.7 (0x80081f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x804df5000) /usr/local/lib/libexpat.so.6: libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/lib/libdrm.so.2: libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/lib/libelf.so.1: libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/lib/libdrm_radeon.so.1: libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x802091000) libpthread-stubs.so.0 => /usr/local/lib/libpthread-stubs.so.0 (0x805003000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /lib/libz.so.6: libc.so.7 => /lib/libc.so.7 (0x80081f000) /lib/libthr.so.3: libc.so.7 => /lib/libc.so.7 (0x80081f000) /lib/libncurses.so.8: libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/llvm34/lib/libLLVM-3.4.so: libz.so.6 => /lib/libz.so.6 (0x8026be000) libthr.so.3 => /lib/libthr.so.3 (0x8028d4000) libncurses.so.8 => /lib/libncurses.so.8 (0x802af9000) libm.so.5 => /lib/libm.so.5 (0x804bce000) libc++.so.1 => /usr/lib/libc++.so.1 (0x8046f0000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8049b2000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x804df5000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/lib/libc++.so.1: libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8049b2000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x804df5000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /lib/libcxxrt.so.1: libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x804df5000) libc.so.7 => /lib/libc.so.7 (0x80081f000) /lib/libm.so.5: libc.so.7 => /lib/libc.so.7 (0x80081f000) /lib/libgcc_s.so.1: libc.so.7 => /lib/libc.so.7 (0x80081f000) /usr/local/lib/libpthread-stubs.so.0: libc.so.7 => /lib/libc.so.7 (0x80081f000) I still stand on converting llvm BUILD_ to LIB_ depends.
(In reply to c.kworr from comment #13) > I must say this one is not fixed yet. After building the updated version I > get: > > /usr/local/lib/dri/kms_swrast_dri.so: [...] > libLLVM-3.4.so => /usr/local/llvm34/lib/libLLVM-3.4.so (0x802d46000) Linking to the shared libLLVM has been the default for a while now, see http://mesa3d.org/relnotes/10.2.html Also, the corresponding options has been renamed, so my suggestion above was bogus.
A commit references this bug: Author: kwm Date: Thu Nov 27 14:48:50 UTC 2014 New revision: 373491 URL: https://svnweb.freebsd.org/changeset/ports/373491 Log: Update to 10.3.4. Enable TEXTURE option in dri by default [1]. This allows for OpenGL higher then 2.1 to be supported. Make sure we depend on llvm at run time when gallium is enabled. The gallium based modules link to the llvm shared libraries. [2] PR: followup on 194655 [2] Approved by: core@ [1] Obtained from: xorg-dev repo Changes: head/graphics/dri/Makefile head/graphics/libEGL/Makefile head/graphics/libGL/Makefile head/graphics/libGL/bsd.mesalib.mk head/graphics/libGL/distinfo head/graphics/libglesv2/Makefile