A meson/ninja install using option, "-Ddri-drivers-path" overrides the DESTDIR variable and install to the path specified by "-Ddri-drivers-path". Therefore files don't get packaged or logged with the files that do get installed to DESTDIR. The above behaviour differs from an autotools build and install in which, "--with-dri-driverdir" does not override DESTDIR. Slackware installs dri modules in, "/usr/lib64/xorg/modules/dri". Leaving, "-Ddri-drivers-path" to the default value allows DRI drivers to be installed in the DESTDIR directory but then xorg-server will need to be recompiled to find the new DRI driver location. Meson/ninja installing vdpau libraries (two bugs in one): 1.Symlink bug If using DESTDIR variable WITHOUT "-Dvdpau-libs-path" then the symlinks, "libvdpau_radeonsi.so.1.0 libvdpau_radeonsi.so.1 libvdpau_radeonsi.so" incorrectly point to, "${DESTDIR}/lib64/vdpau/libvdpau_radeonsi.so.1.0.0" and not, "/usr/lib64/vdpau/vdpau_radeonsi.so.1.0.0". Autotools building would have symlinked to, "/usr/lib64/vdpau/vdpau_radeonsi.so.1.0.0" when installing to DESTDIR. 2. DESTDIR bug/meson feature If using DESTDIR variable WITH "-Dvdpau-libs-path" then all vdpau related files and symlinks install to, "/usr/lib64/vdpau/". Symlinks correctly point to "/usr/lib64/vdpau/libvdpau_radeonsi.so.1.0.0". If installing in this manner then files and links cannot be packaged or logged with other files that do install to DESTDIR.
The symlink bug has also surfaced on arch linux. It affects both 18.0.0 and trunk. Arch linux mesa dev Heftig has created a patch see https://git.archlinux.org/svntogit/packages.git/tree/trunk/fix-install.diff?h=packages/mesa
Added Jan Steffens aka Heftig to cc list, as he's the autor of the patch. Also added the release manager for 18.0 , Emil Velikov , as this bug breaks vdpau hw accelereation in stable mesa 18.0 when built with meson.
I'm sorry I let this slip so long, someone had sent a patch to fix this and I'd asked them to make some changes and that never happened. I'm sending a patch for this.
Arch Linux currently carries two patches (fix-install.diff and fix-versions.diff) to reduce to differences between the Meson product and the Autotools one; it also adds the project version script that was missing from the 18.0.0 tarball.
patch here: https://patchwork.freedesktop.org/patch/214930/ As a side note, feel free to CC me on any meson related things. The missing version script should be fixed for 18.0.1, the change is in master as bc2fdb9759dc702ec351a044b3fd408c0701fedb. I've also sent a patch to fix the xa version which is missing: https://patchwork.freedesktop.org/series/41150/
Patches "meson-Set-.so-version-for-xa-like-autotools-does.patch" and "meson-fix-megadriver-symlinking.patch" makes correct vdpau symlinks using default options when installing to DESTDIR. 1) However when using option "-Ddri-drivers-path" (with sudo) I get the following error: Installing /dev/shm/x/mesa/mesa/build/meson-private/gl.pc to /dev/shm/x/mesaPackage/usr/lib64/pkgconfig Running custom install script '/dev/shm/x/mesa/mesa/bin/install_megadrivers.py /dev/shm/x/mesa/mesa/build/src/gallium/targets/dri/libgallium_dri.so /usr/lib64/xorg/modules/dri radeonsi_dri.so swrast_dri.so kms_swrast_dri.so vmwgfx_dri.so' Failed to run install script '/dev/shm/x/mesa/mesa/bin/install_megadrivers.py /dev/shm/x/mesa/mesa/build/src/gallium/targets/dri/libgallium_dri.so /usr/lib64/xorg/modules/dri radeonsi_dri.so swrast_dri.so kms_swrast_dri.so vmwgfx_dri.so' FAILED: meson-install /usr/bin/python3 /usr/bin/meson --internal install /dev/shm/x/mesa/mesa/build/meson-private/install.dat ninja: build stopped: subcommand failed. Building mesa/mesa unfinished. Traceback (most recent call last): File "/dev/shm/x/mesa/mesa/bin/install_megadrivers.py", line 69, in <module> main() File "/dev/shm/x/mesa/mesa/bin/install_megadrivers.py", line 43, in main shutil.copy(args.megadriver, master) File "/usr/lib64/python2.7/shutil.py", line 133, in copy copyfile(src, dst) File "/usr/lib64/python2.7/shutil.py", line 97, in copyfile with open(dst, 'wb') as fdst: IOError: [Errno 13] Permission denied: '/usr/lib64/xorg/modules/dri/libgallium_dri.so' __________________ 2) Also, when only "-Dgallium-drivers=radeonsi,svga,swrast" shouldn't the following vdpau drivers be excluded from building and installing: /usr/lib64/vdpau/libvdpau_nouveau.so /usr/lib64/vdpau/libvdpau_nouveau.so.1 /usr/lib64/vdpau/libvdpau_nouveau.so.1.0 /usr/lib64/vdpau/libvdpau_r600.so /usr/lib64/vdpau/libvdpau_r600.so.1 /usr/lib64/vdpau/libvdpau_r600.so.1.0 /usr/lib64/vdpau/libvdpau_r300.so /usr/lib64/vdpau/libvdpau_r300.so.1 /usr/lib64/vdpau/libvdpau_r300.so.1.0 and only the follwing remain: /usr/lib64/vdpau/libvdpau_radeonsi.so /usr/lib64/vdpau/libvdpau_radeonsi.so.1 /usr/lib64/vdpau/libvdpau_radeonsi.so.1.0 ? Or is it possible to exclude certain vdpau drivers?
1) What is the argument you're providing to -Ddri-drivers-path? 2) It's only supposed to install vdpau symlinks for drivers you've built. When I run `meson build -Dgallium-drivers=nouveau -Ddri-drivers= -Dvulkan-drivers= --prefix=/tmp/install; ninja -C build install` I only get vdpau symlinks. Are you sure there isn't a typo in -Dgallium-drivers?
1) "build.environment" (file) export LIBDIRSUFFIX='64' export XBUILD="/usr" ________________EOF -Ddri-drivers-path=${XBUILD}/lib${LIBDIRSUFFIX}/xorg/modules/dri 2) I don't believe there is a typo in my "mesa.cfg2.me" (file). -Dgallium-drivers=radeonsi,svga,swrast Perhaps I am building wrong: "if [[ -e build.ninja ]];then ninja -j$threads 2> build_error.log || exitOnError" The above is executed in a "build" directory after meson generates the build.ninja file. I thought that when "build.ninja" exists then ninja can be executed. I will try replacing "ninja" with "meson".
Your command looks fine, I was just wondering if you had set dri-drivers-path to an absolute or relative path, in the default case it will be relative, which may explain why it's failing.
My suspicion was correct, we're not handling absolute paths and DESTDIR correctly. I think that this patch should resolve it: https://patchwork.freedesktop.org/patch/216020/
"1-2-bin-install_megadrivers-fix-DESTDIR-and--D--path.patch" allows files to be installed to DESTDIR when using absolute paths in config options. No extra driver files are generated other than what is expected from configure options. ________ *.la files are not installed to DESTDIR and meson/ninja does not generate them. Should I submit a new bug report? I believe libEGL.la is needed to compile libwacom and audacity. Also, do I CC you for xorg-server meson bugs?
Also, after the patch was applied, there was an odd behaviour when switching to an absolute path in my config. The install "remembered" my old config as if it used an old meson compiling cache to install to "${DESTDIR}/usr/lib64/dri" and not "${DESTDIR}/usr/lib64/xorg/modules/dri". But I ran meson/ninja a second time with "-Dprefix" and the old /usr/lib64/dri path was "forgotten". Then for the third meson/ninja build WITHOUT "-Dprefix" meson/ninja built into "/usr/lib64/xorg/modules/dri". I suspected running meson/ninja twice triggered some cache renewal function
No sane project should depend on the .la files - that's why distros/packaging tools remove them by default. The only instances that come to mind are ones that use the libtools DL wrapper (for some platforms lack dlopen and friends) to manage internal modules. If you come across project that depend on a .la file, please file issues with the project.
.la files are generated by libtool, meson doesn't use libtool so there will be no .la files. It's not a bug, it's actually a feature. As Emil said, projects should not be dependent on .la files, that's bad behavior. It doesn't surprise me that you needed to regenerate the ninja files to make the install work correctly.
On the first compile attempt with "1-2-bin-install_megadrivers-fix-DESTDIR-and--D--path.patch" applied, the ninja file was regenerated because the git mesa directory is deleted from /dev/shm and a clean copy of origin/master (git reset --hard) is then copied from disk to /dev/shm. The copy of origin/master in /dev/shm is then used to compile. I also logged out before the first attempt to make sure all environment variables were wiped. So I found it odd that there was no change in my build config except for adding "-Dprefix" on my second attempt and have "-Ddri-drivers-path=${XBUILD}/lib${LIBDIRSUFFIX}/xorg/modules/dri" finally working. So I suspected some meson cache not related to the regeneration of the "build.ninja" file needed to be 'refreshed'.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.