This is an auto-filled bug because media-libs/libglvnd calls nm directly. The issue was originally discovered on arm64, but it may be reproducible on other arches as well. If you think that a different summary clarifies the issue better, feel free to change it. Attached build log and emerge --info. NOTE: If you think it doesn't make sense fix these type of issues, I'd like to point out that won't be possible use a different NM implementation (like llvm-nm) by setting the NM variable. So this issue has been reproduced by setting the NM variable to aarch64-unknown-linux-gnu-nm and by removing the /usr/bin/nm binary.
Created attachment 635906 [details] build.log build log and emerge --info
*** Bug 724740 has been marked as a duplicate of this bug. ***
""" * Package: media-libs/libglvnd-1.3.1 * Repository: gentoo * Maintainer: x11@gentoo.org * USE: arm64 elibc_glibc kernel_linux test userland_GNU * FEATURES: network-sandbox preserve-libs sandbox splitdebug test userpriv usersandbox * Using python3.6 to build >>> Unpacking source... >>> Unpacking libglvnd-1.3.1.tar.bz2 to /var/tmp/portage/media-libs/libglvnd-1.3.1/work >>> Source unpacked in /var/tmp/portage/media-libs/libglvnd-1.3.1/work >>> Preparing source in /var/tmp/portage/media-libs/libglvnd-1.3.1/work/libglvnd-v1.3.1 ... >>> Source prepared. >>> Configuring source in /var/tmp/portage/media-libs/libglvnd-1.3.1/work/libglvnd-v1.3.1 ... * .arm64: running multilib-minimal_abi_src_configure * Unable to trace static ELF: /sbin/ldconfig: /sbin/ldconfig -p meson setup --buildtype plain --libdir lib64 --localstatedir /var/lib --prefix /usr --sysconfdir /etc --wrap-mode nodownload --build.pkg-config-path /usr/share/pkgconfig --pkg-config-path /usr/share/pkgconfig --native-file /var/tmp/portage/media-libs/libglvnd-1.3.1/temp/meson.aarch64-unknown-linux-gnu.arm64.ini -Dx11=disabled -Dglx=disabled /var/tmp/portage/media-libs/libglvnd-1.3.1/work/libglvnd-v1.3.1 /var/tmp/portage/media-libs/libglvnd-1.3.1/work/libglvnd-v1.3.1-.arm64 * Unable to trace static ELF: /sbin/ldconfig: /sbin/ldconfig -p The Meson build system Version: 0.53.1 Source dir: /var/tmp/portage/media-libs/libglvnd-1.3.1/work/libglvnd-v1.3.1 Build dir: /var/tmp/portage/media-libs/libglvnd-1.3.1/work/libglvnd-v1.3.1-.arm64 Build type: native build Project name: glvnd Project version: 1.3.1 WARNING: Env var CC seems to point to the cross compiler. This is probably wrong, it should always point to the native compiler. Appending CFLAGS from environment: '-O2 -pipe -march=native -g -ggdb -frecord-gcc-switches' Appending LDFLAGS from environment: ['-Wl,-O1', '-Wl,--as-needed', '-Wl,--defsym=__gentoo_check_ldflags__=0'] WARNING: Env var AR seems to point to the cross compiler. This is probably wrong, it should always point to the native compiler. WARNING: Env var CC seems to point to the cross compiler. This is probably wrong, it should always point to the native compiler. Appending CFLAGS from environment: '-O2 -pipe -march=native -g -ggdb -frecord-gcc-switches' Appending LDFLAGS from environment: ['-Wl,-O1', '-Wl,--as-needed', '-Wl,--defsym=__gentoo_check_ldflags__=0'] C compiler for the host machine: aarch64-unknown-linux-gnu-gcc (gcc 9.3.0 "aarch64-unknown-linux-gnu-gcc (Gentoo 9.3.0 p2) 9.3.0") C linker for the host machine: aarch64-unknown-linux-gnu-gcc GNU ld.bfd 2.34 WARNING: Env var AR seems to point to the cross compiler. This is probably wrong, it should always point to the native compiler. Host machine cpu family: aarch64 Host machine cpu: aarch64 Program python3 found: YES (/usr/bin/python3.6) Program nm found: NO meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable A full log can be found at /var/tmp/portage/media-libs/libglvnd-1.3.1/work/libglvnd-v1.3.1-.arm64/meson-logs/meson-log.txt * ERROR: media-libs/libglvnd-1.3.1::gentoo failed (configure phase): * (no error message) """ Looks like libglvnd's 'meson.build' discovers 'nm' as: prog_nm = find_program('nm') Is it a correct way to find ${CHOST}-prefixed nm or $NM?
+meason.eclass maintainers. The following workaround seems to help: --- a/eclass/meson.eclass +++ b/eclass/meson.eclass @@ -233,6 +233,7 @@ _meson_create_native_file() { pkgconfig = '$(tc-getBUILD_PKG_CONFIG)' strip = $(_meson_env_array "$(tc-getBUILD_STRIP)") windres = $(_meson_env_array "$(tc-getBUILD_PROG RC windres)") + nm = $(_meson_env_array "$(tc-getBUILD_PROG NM nm)") [properties] c_args = $(_meson_env_array "${BUILD_CFLAGS} ${BUILD_CPPFLAGS}") Is it a reasonable fix?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=da03d40f146a646c38e75fd0a6fc299b5aeba505 commit da03d40f146a646c38e75fd0a6fc299b5aeba505 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-06-12 18:34:10 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-06-12 23:46:28 +0000 meson.eclass: override 'nm' tool with tuple-prefixed one x11-libs/libdrm and media-libs/libglvnd fail to find 'nm' tool on sys-devel/binutils-config[-native-symlinks] system as: `meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable` It's caused by the code that locates the tool as: `prog_nm = find_program('nm')`. The change adds 'nm' tool along with other binutils tools. Closes: https://bugs.gentoo.org/720886 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/meson.eclass | 2 ++ 1 file changed, 2 insertions(+)
