FS#61160 - [lib32-mesa] PKGBUILD uses autotools variables that are not supported by meson
Attached to Project:
Community Packages
Opened by Lone_Wolf (Lone_Wolf) - Sunday, 23 December 2018, 12:15 GMT
Last edited by freswa (frederik) - Monday, 07 September 2020, 15:16 GMT
Opened by Lone_Wolf (Lone_Wolf) - Sunday, 23 December 2018, 12:15 GMT
Last edited by freswa (frederik) - Monday, 07 September 2020, 15:16 GMT
|
Details
In build() lib32-mesa uses
export PKG_CONFIG_PATH="/usr/lib32/pkgconfig" export LLVM_CONFIG="/usr/bin/llvm-config32" When autotools was the buildsystem this worked fine, but the meson build system does not use these variables. Meson does support a PKG_CONFIG environment variable but expects it to point to an executable. For llvm_config meson took another approach and added a new directive --native in 0.49 . Both issues have been extensively troubleshooted and discussed on archlinux forum, https://bbs.archlinux.org/viewtopic.php?id=241990 For an example how this could be implemented check my AUR lib32-mesa-git package . https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=lib32-mesa-git https://aur.archlinux.org/cgit/aur.git/tree/llvm32.native?h=lib32-mesa-git |
This task depends upon
Closed by freswa (frederik)
Monday, 07 September 2020, 15:16 GMT
Reason for closing: Not a bug
Additional comments about closing: multilib builds are not crosscompile builds
Monday, 07 September 2020, 15:16 GMT
Reason for closing: Not a bug
Additional comments about closing: multilib builds are not crosscompile builds
'export CC="gcc -m32"' it works but 'export CC="clang -m32"' not. It seems to me that lib32-* (meson build) should use a complete cross-files.
https://bugs.archlinux.org/task/61268
Progandy found atleast one issue with meson crossbuilds in the linked forum thread.
The meson-cross-x86-linux-gnu package linked in 61268 doesn't appear to deal with that.
I've opened a github issue for it to alert upstream of this.
https://github.com/Oxalin/meson-cross-x86-linux-gnu/issues/2
<inline asm>:8:36: error: register %rip is only available in 64-bit mode
So, quite obviously not meson's fault I'd say.
In fact the clang command line is in fact using -m32 just fine, so the build system is correctly teaching meson about its desires -- it is simply that clang does not work to compile lib32-mesa using the options suggested.
Since arch uses gcc, not clang, as the default compiler, and since arch uses gcc, not clang, to compile lib32-mesa, I'm not sure what the problem here is or why it might relate to the LLVM_CONFIG variable.
@Lone_Wolf, every time I hear more about meson cross builds, I get more confused and put off. :D
Anyway, here's a great solution that guarantees that the correct llvm-config will always be used in any and all circumstances no matter what other methods may or may not be available on *any* build system:
mkdir -p path
ln -sf /usr/bin/llvm-config32 path/llvm-config
export PATH="$PWD/path:$PATH"
This applies to all multilib packages built with meson.
The correct way is to use a cross-file, therefore the meson package should provide the official cross-files for Arch Linux
Please also see https://github.com/mesonbuild/meson/issues/4664
rule cpp_COMPILER
command = clang -m32 $ARGS -MD -MQ $out -MF '$DEPFILE' -o $out -c $in
And ninja prints the command line for failing commands, for example:
[6/2204] Compiling C object 'src/mapi/glapi/64e7e5d@@glapi_static@sta/.._entry.c.o'.
FAILED: src/mapi/glapi/64e7e5d@@glapi_static@sta/.._entry.c.o
clang -m32 -Isrc/mapi/glapi/64e7e5d@@glapi_static@sta -Isrc/mapi/glapi -I../mesa-18.3.1/src/mapi/glapi -Isrc/mesa -I../mesa-18.3.1/src/mesa -Iinclude -I../mesa-18.3.1/include -Isrc -I../mesa-18.3.1/src -Isrc/mapi -I../mesa-18.3.1/src/mapi -Isrc/mapi/glapi/gen -Xclang -fcolor-diagnostics -DNDEBUG -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -O3 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DVERSION="18.3.1"' -DPACKAGE_VERSION=VERSION '-DPACKAGE_BUGREPORT="https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa"' -DGLX_USE_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM -DHAVE_SURFACELESS_PLATFORM -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -D_GNU_SOURCE -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM -DMAJOR_IN_SYSMACROS -DHAVE_SYS_SYSCTL_H -DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_POSIX_MEMALIGN -DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_PTHREAD -DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DHAVE_LLVM=0x0700 -DMESA_LLVM_VERSION_PATCH=1 -DUSE_LIBGLVND=1 -DHAVE_WAYLAND_PLATFORM -DWL_HIDE_DEPRECATED -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_GALLIUM_EXTRA_HUD=1 -DHAVE_LIBSENSORS=1 -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -fno-math-errno -fno-trapping-math -Qunused-arguments -Wno-missing-field-initializers -march=native -O2 -fstack-protector-strong -fdiagnostics-color=always -D_FORTIFY_SOURCE=2 -fPIC -pthread -Werror=pointer-arith -Werror=vla -DMAPI_MODE_BRIDGE '-DMAPI_ABI_HEADER="/var/cache/svnrepos/community/lib32-mesa/trunk/src/build/src/mapi/glapi/gen/glapi_mapi_tmp.h"' -MD -MQ 'src/mapi/glapi/64e7e5d@@glapi_static@sta/.._entry.c.o' -MF 'src/mapi/glapi/64e7e5d@@glapi_static@sta/.._entry.c.o.d' -o 'src/mapi/glapi/64e7e5d@@glapi_static@sta/.._entry.c.o' -c ../mesa-18.3.1/src/mapi/entry.c
So as I said, "In fact the clang command line is in fact using -m32 just fine"
as for crossbuild files for multilib pacakges I have not seen any proof yet they have advantages over the method used in my lib32-mesa-git package.
I have seen issues with crossbuilding in general though, f.e. https://github.com/mesonbuild/meson/issues/4694 and https://github.com/mesonbuild/meson/issues/1772
Maybe the discussion about crossbuilding could be taken somewhere else like arch-dev-public, arch-general or a feature request ?
>FAILED: src/mapi/glapi/64e7e5d@@glapi_static@sta/.._entry.c.o
>clang -m32 -Isrc/mapi/glapi/64e7e5d@@glapi_static@sta -Isrc/mapi/glapi.....
This does't mean that you use the '-m32' flag only you run 'clang -m32'
Test:
#1 'export CC="clang -m32"' and 'export CXX='clang++ -m32'
https://gist.github.com/fafryd1125/5dd35bf17974bccd01d53db9a4fb3a17
#2 cross-file
https://gist.github.com/fafryd1125/fbf0b4719e5509d4b0bb932f240ab1c0
>I'm also unsure what clang has to do with this bug, since our official toolchain uses gcc,...
I just want to point out that for gcc a cross-file should also be used. 'clang -m32' is just an example of what can go wrong.
If even the 'export gcc -m32' (and other variables) works, it does't mean that it is technically correct.
https://mesa3d.org/meson.html#cross-compilation
It does look like archlinux devs (and myself) don't consider multilib builds to be crosscompile builds.
I'm ok with this and am requesting closing.
( If a discussion about multilib / meson / crosscompiling is needed this bug is the wrong place for it imo)