Bug 111126 - Build problem: meson build can not find wayland-scanner
Summary: Build problem: meson build can not find wayland-scanner
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-14 06:56 UTC by markus
Modified: 2019-08-05 16:37 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description markus 2019-07-14 06:56:29 UTC
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.
Comment 1 Denis 2019-07-15 12:48:22 UTC
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.
Comment 2 Jordan Justen 2019-07-22 18:55:59 UTC
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
Comment 3 Jordan Justen 2019-07-22 19:50:30 UTC
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.
Comment 4 Emil Velikov 2019-07-24 16:00:26 UTC
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.
Comment 5 Dylan Baker 2019-07-24 16:20:53 UTC
Are you doing a cross compile?
Comment 6 Jordan Justen 2019-07-26 08:46:48 UTC
(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. :)
Comment 7 Jordan Justen 2019-07-26 08:54:57 UTC
(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.
Comment 8 Jordan Justen 2019-07-31 20:38:03 UTC
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.
Comment 9 Dylan Baker 2019-07-31 20:51:49 UTC
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.
Comment 10 Jordan Justen 2019-07-31 21:13:45 UTC
(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.
Comment 11 Dylan Baker 2019-07-31 21:24:42 UTC
It's a meson bug. There's a PR discussing what to do here:
https://github.com/mesonbuild/meson/pull/5674
Comment 12 Jussi Pakkanen 2019-08-05 16:37:06 UTC
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.