| Summary: | Build problem: meson build can not find wayland-scanner | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | markus <shevegen> |
| Component: | Other | Assignee: | mesa-dev |
| Status: | RESOLVED NOTOURBUG | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | CC: | baker.dylan.c, emil.l.velikov, fdo-bugs, jljusten |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Hi. How did you try to compile mesa exactly? Provide plz build script. Also, provide output of "/Depot/Temp/rbt/mesa-19.1.2/BUILD_DIRECTORY/meson-logs/meson-log.txt" - as I remember similar issues with packages, it prints there exact "try" for the package. I also saw this on debian sid after upgrading from meson 0.49 to 0.51. Downgrading to 0.49 fixed it. In the meson log, it suspiciously lists the PKG_CONFIG_PATH as empty, but for several previously found libraries, PKG_CONFIG_PATH is printed as non-empty: Pkg-config binary for MachineChoice.BUILD is not cached. Pkg-config binary missing from cross or native file, or env var undefined. Trying a default pkg-config fallback at pkg-config Trying pkg-config binary pkg-config for machine MachineChoice.BUILD at ['/usr/bin/pkg-config'] Found pkg-config: /usr/bin/pkg-config (0.29) Determining dependency 'wayland-scanner' with pkg-config executable '/usr/bin/pkg-config' PKG_CONFIG_PATH: Called `/usr/bin/pkg-config --modversion wayland-scanner` -> 1 Emil, in:
commit c077b74ee8187042ad3ad8001d94074e73e3e9ea
meson: use dependency()+find_program() for wayland-scanner
You added "native: true". How is that used? I notice that if I
remove it, then mesa will configure with meson 0.51.
BTH it's been a while, so I don't recall the details. It was either: - target machine was missing wayland-scanner (correct), so we had to tell meson to use the one of the build host, or - meson was trying to run the target wayland-scanner on the build host, and failing since they are different architectures Quick look around shows that meson 0.51 release notes mentions something about this in "Specifying options per mer machine". Yet I cannot see a clear example having meson.build compatible with old and new meson :-\ FWIW I'm inclined to call this a meson bug - changing behaviour is w/o a big fat preemptive WARNING is not nice. Yet I won't object if you want to revert my patch. Are you doing a cross compile? (In reply to Emil Velikov from comment #4) > Yet I won't object if you want to revert my patch. I don't want to revert this patch. I'm hoping that either you or Dylan can reproduce it with 0.51, and figure out the best fix. :) (In reply to Dylan Baker from comment #5) > Are you doing a cross compile? I am not cross compiling. I do set PKG_CONFIG_PATH, but it includes the system path where the wayland-scanner.pc is at. Yet, from the meson log output, it looks like when searching for wayland-scanner.pc, it uses an empty set of paths. When pkg-config is used for other deps, the meson log shows my PKG_CONFIG_PATH is used. I found a fix for my build environment. I have to add this to my meson configuration: --build.pkg-config-path "$PKG_CONFIG_PATH" It looks like meson now ignores PKG_CONFIG_PATH if a "native" library is being located. I'm not sure if there might be a way to detect if an actual cross compilation is happening. If we are not cross compiling, then we could set "native" to false, and PKG_CONFIG_PATH could be used without the additional meson parameter. Are you passing PKG_CONFIG_PATH at meson setup time? such as 'PKG_CONFIG_PATH="..." meson builddir'? Because if you are this is definitely a meson bug, and there might be a PR for this already. (In reply to Dylan Baker from comment #9) > Are you passing PKG_CONFIG_PATH at meson setup time? such as > 'PKG_CONFIG_PATH="..." meson builddir'? Because if you are this is > definitely a meson bug, and there might be a PR for this already. Yes, PKG_CONFIG_PATH is set in the environment before running meson. In looking through meson's code (mesonmesonbuild/dependencies/base.py), it seems some effort may have been taken to ignore PKG_CONFIG_PATH if a dependency sets native. The first meson commit that seems to take related steps is 11e3011a6bf0adeb51582c590c90b0f4dccb4df8. It seems like the related code has been reworked substantially since then. Hmm, I guess af2d7af9983a04fa2dd6c073bdc41847a23012c8 is what has changed the behavior recently. It's a meson bug. There's a PR discussing what to do here: https://github.com/mesonbuild/meson/pull/5674 Could someone please test if this issue is fixed if you use the following Meson PR: https://github.com/mesonbuild/meson/pull/5674 Upon confirmation we'll get the 0.52.2 release out. Thanks, |
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.
I am trying to compile mesa 19.1.2 from source. Meson version is: 0.51.1 Here is the log so far: Version: 0.51.1 Source dir: /Depot/Temp/rbt/mesa-19.1.2 Build dir: /Depot/Temp/rbt/mesa-19.1.2/BUILD_DIRECTORY Build type: native build Program python found: YES (/System/Index/bin/python) Project name: mesa Project version: 19.1.2 Appending CFLAGS from environment: '-O2 -fPIC -fno-strict-overflow -Wno-error' C compiler for the build machine: ccache cc (gcc 9.1.0 "cc (GCC) 9.1.0") C++ compiler for the build machine: ccache c++ (gcc 9.1.0 "c++ (GCC) 9.1.0") Appending CFLAGS from environment: '-O2 -fPIC -fno-strict-overflow -Wno-error' C compiler for the host machine: ccache cc (gcc 9.1.0 "cc (GCC) 9.1.0") C++ compiler for the host machine: ccache c++ (gcc 9.1.0 "c++ (GCC) 9.1.0") Build machine cpu family: x86_64 Build machine cpu: x86_64 Program pkg-config found: YES (/System/Index/bin/pkg-config) Found pkg-config: /System/Index/bin/pkg-config (0.29.2) Run-time dependency vdpau found: YES 1.2 Run-time dependency xvmc found: YES 1.0.11 Found CMake: /System/Index/bin/cmake (3.14.5) Run-time dependency libomxil-bellagio found: NO (tried pkgconfig and cmake) Run-time dependency libtizonia found: NO (tried pkgconfig and cmake) Run-time dependency libtizplatform found: NO (tried pkgconfig and cmake) Run-time dependency tizilheaders found: NO (tried pkgconfig and cmake) Run-time dependency libva found: YES 1.5.0 WARNING: Project targetting '>= 0.45' but tried to use feature introduced in '0.46.0': Python Module Program python3 found: YES (/System/Index/bin/python3) Checking for function "bswap32" : YES Checking for function "bswap64" : YES Checking for function "clz" : YES Checking for function "clzll" : YES Checking for function "ctz" : YES Checking for function "expect" : YES Checking for function "ffs" : YES Checking for function "ffsll" : YES Checking for function "popcount" : YES Checking for function "popcountll" : YES Checking for function "unreachable" : YES Checking if "__attribute__((const))" compiles: YES Checking if "__attribute__((flatten))" compiles: YES Checking if "__attribute__((malloc))" compiles: YES Checking if "__attribute__((pure))" compiles: YES Checking if "__attribute__((unused))" compiles: YES Checking if "__attribute__((warn_unused_result))" compiles: YES Checking if "__attribute__((weak))" compiles: YES Checking if "__attribute__((format(...)))" compiles: YES Checking if "__attribute__((packed))" compiles: YES Checking if "__attribute__((returns_nonnull))" compiles: YES Checking if "__attribute__((visibility(...)))" compiles: YES Checking if "__attribute__((alias(...)))" compiles: YES Checking if "__attribute__((__noreturn__))" compiles: YES Compiler for C supports arguments -Werror=implicit-function-declaration: YES Compiler for C supports arguments -Werror=missing-prototypes: YES Compiler for C supports arguments -Werror=return-type: YES Compiler for C supports arguments -Werror=incompatible-pointer-types: YES Compiler for C supports arguments -fno-math-errno: YES Compiler for C supports arguments -fno-trapping-math: YES Compiler for C supports arguments -Qunused-arguments: NO Compiler for C supports arguments -Wmissing-field-initializers: YES Compiler for C supports arguments -Wformat-truncation: YES Compiler for C supports arguments -fvisibility=hidden: YES Compiler for C++ supports arguments -Werror=return-type: YES Compiler for C++ supports arguments -fno-math-errno: YES Compiler for C++ supports arguments -fno-trapping-math: YES Compiler for C++ supports arguments -Qunused-arguments: NO Compiler for C++ supports arguments -Wnon-virtual-dtor: YES Compiler for C++ supports arguments -Wmissing-field-initializers: YES Compiler for C++ supports arguments -Wformat-truncation: YES Compiler for C supports arguments -Woverride-init: YES Compiler for C supports arguments -Winitializer-overrides: NO Compiler for C++ supports arguments -fvisibility=hidden: YES Compiler for C supports arguments -Werror=pointer-arith: YES Compiler for C++ supports arguments -Werror=pointer-arith: YES Compiler for C supports arguments -Werror=vla: YES Compiler for C++ supports arguments -Werror=vla: YES Checking if "GCC atomic builtins" compiles: YES Checking if "GCC atomic builtins required -latomic" links: YES Checking if "GCC 64bit atomics" with dependency not-found links: YES Header <sys/sysmacros.h> has symbol "major" : YES Checking if "xlocale.h" compiles: NO Checking if "sys/sysctl.h" compiles: YES Checking if "linux/futex.h" compiles: YES Checking if "endian.h" compiles: YES Checking if "dlfcn.h" compiles: YES Checking if "execinfo.h" compiles: YES Checking for function "strtof" : YES Checking for function "mkostemp" : YES Checking for function "posix_memalign" : YES Checking for function "timespec_get" : YES Checking for function "memfd_create" : YES Checking if "strtod has locale support" links: YES Checking if "Bsymbolic" links: YES Checking if "gc-sections" links: YES Checking if "version-script" links: YES Checking if "dynamic-list" links: YES Checking for function "dlopen" : NO Library dl found: YES Checking for function "dladdr" with dependency -ldl: YES Checking for function "dl_iterate_phdr" : YES Checking for function "clock_gettime" : YES Run-time dependency zlib found: YES 1.2.11 Run-time dependency threads found: YES Checking for function "pthread_setaffinity_np" with dependency threads: YES Run-time dependency expat found: YES 2.2.6 Library m found: YES Message: libdrm 2.4.97 needed because amdgpu has the highest requirement Run-time dependency libdrm_intel found: YES 2.4.99 Run-time dependency libdrm_amdgpu found: YES 2.4.99 Run-time dependency libdrm_radeon found: YES 2.4.99 Run-time dependency libdrm_nouveau found: YES 2.4.99 Run-time dependency libdrm found: YES 2.4.99 llvm-config found: YES (/System/Index/bin/llvm-config) 8.0.0 Run-time dependency LLVM (modules: amdgpu, asmparser, bitreader, bitwriter, engine, ipo, mcdisassembler, mcjit, native) found: YES 8.0.0 Run-time dependency libelf found: YES 0.176 Run-time dependency valgrind found: NO (tried pkgconfig) Program bison found: YES (/System/Index/bin/bison) Program flex found: YES (/System/Index/bin/flex) Run-time dependency libunwind found: YES 1.3.1 Found pkg-config: /System/Index/bin/pkg-config (0.29.2) Found CMake: /System/Index/bin/cmake (3.14.5) Build-time dependency wayland-scanner found: NO (tried pkgconfig and cmake) meson.build:1361:2: ERROR: Dependency "wayland-scanner" not found, tried pkgconfig and cmake A full log can be found at /Depot/Temp/rbt/mesa-19.1.2/BUILD_DIRECTORY/meson-logs/meson-log.txt ----------------------------------------------------------------------------- meson can not find wayland scanner, but it is right at /usr/bin/wayland-scanner. Additionally all the .pc files of wayland reside at /usr/lib/pkgconfig/. Note that I have wayland installed via appdir-prefix at /Programs/Wayland/1.17.0/ and then use symlinks (similar to what the program called stow does). llvm on the other hand is installed into the prefix /usr/. I am not sure why the meson build can find cmake and pkg-config without a problem, but not wayland-scanner. cmake version is: 3.14.5 Content of wayland-scanner.pc is: prefix=/Programs/Wayland/1.17.0 exec_prefix=${prefix} datarootdir=${prefix}/share pkgdatadir=${datarootdir}/wayland wayland_scanner=${exec_prefix}/bin/wayland-scanner Name: Wayland Scanner Description: Wayland scanner Version: 1.17.0 I think there may be something failing but it is not stating why. If possible it may be useful to have meson report a bit more to the user in such an event, because "stat /usr/bin/wayland-scanner" works fine, and the .pc file is there too, so I have no idea why meson can not find it.