On Wed, 2017-12-13 at 13:54 -0800, Dylan Baker wrote: > Quoting Jan Vesely (2017-12-13 12:53:25) > > On Wed, 2017-12-13 at 09:47 -0800, Dylan Baker wrote: > > > +if (with_gallium_va or with_gallium_vdpau or with_gallium_omx or > > > + with_gallium_xvmc or with_dri) > > > + pipe_loader_link_with += libgalliumvl > > > +else > > > + pipe_loader_link_with += libgalliumvl_stubs > > > +endif > > > +if with_gallium_va or with_gallium_vdpau or with_gallium_omx or > > > with_gallium_xvmc > > > > git am complains about whitespace errors at the end of the above line. > > I can fix that. > > > > > I tested with: > > meson -Ddri-drivers= -Dgallium-drivers=r600 -Dopengl=true -Dplatforms=x11 > > -Dopencl=true > > > > meson asked for libdrm_amdgpu dependency even though I'm only building > > clover+r600g driver. > > That's probably because you didn't add `-Dvulkan-drivers=`, since radv does > depend > on libdrm_amdgpu. If you add that and still get a request for libdrm_amdgpu > let > me know and I'll look into it further.
right, that fixes it. sorry for the noise. > > > after a bit of fiddling with PATH and PK_CONFIG_PATH to pick up the latest > > llvm/liblclc > > linking failed with: > > src/gallium/auxiliary/libgallium.a(gallivm_lp_bld_misc.cpp.o):(.data.rel.ro._ZTI26DelegatingJITMemoryManager[_ZTI26DelegatingJITMemoryManager]+0x10): > > undefined reference to `typeinfo for llvm::RTDyldMemoryManager' > > collect2: error: ld returned 1 exit status > > > > this looks like it did not pick up the rtti setting from llvm-config: > > $ ~/.local/bin/llvm-config --has-rtti > > NO > > $ ~/.local/bin/llvm-config --cxxflags | grep -o fno-rtti > > fno-rtti > > > > rtti setting is quite messy since clover uses dynamic_cast. I think it > > should be OK to only support rtti build of llvm if it's detected at > > configure time > > > > it'd also be nice for meson to remember llvm-config location provided > > at configure time. otherwise I need to set PATH every time I run ninja > > in case it tries to reconfigure. I guess that's what "TODO llvm-prefix" > > will achieve, right? > > I'm not sure what the right way to solve this is, maybe to cache any relavent > environment variables between runs in meson itself, since pkg-config has the > same problem with PKG_CONFIG_PATH. ATM there is no way to implement the > llvm-prefix in meson the way it is in autotools. would it be easier to explicitly set location of llvm-config and libclc.pc? currently it works OK with system packages, you can add Tested-by: Jan Vesely <jan.ves...@rutgers.edu> I'd need a way to permanently redirect the configuration to use local builds of both llvm and libclc to use meson as my daily driver. > > > > > > in the end I got meson built clover to run (clinfo + simple demo) on my > > turks with these changes: > > * build and install libdrm_amdgpu -- should not be necessary for r600g > > only build > > * switch to distro (fedora) provided libclc and llvm -- avoids rtti > > build problem (note libclc is just tagging along llvm since my local > > builds install headers to the same location) > > * fiddle with pipe-loader dir, for some reason LIBGL_DRIVERS_PATH did > > not work when pointed to meson built pipe_r600.so. I'm not sure if this > > is meson specific, it might be just my ignorance. > > I'm not certain, though Curro probably knows, but the dynamic pipeloader is > hard-coded to search $install/$libdir/gallium-pipe for pipe drivers, so you > may > need to run ninja install to make it work. Alternatively LD_LIBRARY_PATH might > work as well. I assumed that it was some loader configuration outside meson. the surprising part was that it tried to open cwd local paths: openat(AT_FDCWD, "lib64/gallium-pipe/pipe_r600.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) Is this expected without explicitly setting install prefix? Jan > > Dylan
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
