[BUG] Cross Compiled meson not using cross compiled libraries and failing meson.build tests
Describe the bug
Whilst building glib 2.69.0 with glibc 2.34 the meson toolchain fails it's tests of frexp() and frexpl()
Program stderr:
/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-10.0-devel/build/glib-37e5dfd3a2ced10c395b38702ae15e0e128e457b/.x86_64-libreelec-linux-gnu/meson-private/tmpg908xy4s/output.exe: /lib/x86_64-linux-gnu/libc.so.6: version *GLIBC_2.34* not found (required by /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-10.0-devel/build/glib-37e5dfd3a2ced10c395b38702ae15e0e128e457b/.x86_64-libreelec-linux-gnu/meson-private/tmpg908xy4s/output.exe)
- Raised (and closed as glib issue) https://gitlab.gnome.org/GNOME/glib/-/issues/2453
A hack workaround is to comment out the following lines in meson.build
#if not gl_cv_func_frexp_works and gl_cv_func_frexp_broken_beyond_repair
# error ('frexp() is missing or broken beyond repair, and we have nothing to replace it with')
#endif
#if not gl_cv_func_frexpl_works and gl_cv_func_frexpl_broken_beyond_repair
# error ('frexpl() is missing or broken beyond repair, and we have nothing to replace it with')
#endif
Further testing being done.
As you can see from the log meson tries to run test program for frexp. Because we are crosscompiling this should not happen because target binaries can't run on a host directly. The reason for such behavior is (probably) because there is something wrong with meson config on LE (I have this bad feeling for a long time but I'm unable to pinpoint exactly).
If we look why meson tries to run target binary the reason is here https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gnulib/gl_cv_func_frexp_works/meson.build#L79
meson.is_cross_build() doesn't return true as it should. Because if it would then this would be set
gl_cv_func_frexp_works = true
gl_cv_func_frexp_broken_beyond_repair = false
and frexp error is not shown.
I'm not exactly sure how to fix this correctly. I tried in the past but I failed. But at least in this case this helps
diff --git a/config/functions b/config/functions
index 9954c23fba..8f56249606 100644
--- a/config/functions
+++ b/config/functions
@@ -513,6 +513,7 @@ cpu = '$TARGET_SUBARCH'
endian = 'little'
[properties]
+needs_exe_wrapper = true
root = '$SYSROOT_PREFIX/usr'
$(python3 -c "import os; print('c_args = {}'.format([x for x in os.getenv('TARGET_CFLAGS').split()]))")
$(python3 -c "import os; print('c_link_args = {}'.format([x for x in os.getenv('TARGET_LDFLAGS').split()]))")
With this patch https://gitlab.gnome.org/GNOME/glib/-/commit/b71117d89434db83d34bc1b981ca03d4be299576 glib is then build correctly.
I also noticed that bluez needs this patch https://src.fedoraproject.org/rpms/bluez/raw/fdda690e478cc1581c12265af16d043c757758dd/f/0005-media-rename-local-function-conflicting-with-pause-2.patch
Also at least in my case glib also needs pcre:host in PKG_DEPENDS_HOST.
diff --git a/packages/devel/glib/package.mk b/packages/devel/glib/package.mk
index c157de8206..3b253d61b0 100644
--- a/packages/devel/glib/package.mk
+++ b/packages/devel/glib/package.mk
@@ -5,10 +5,10 @@
PKG_LICENSE="LGPL"
PKG_SITE="http://www.gtk.org/"
PKG_URL="http://ftp.gnome.org/pub/gnome/sources/glib/$(get_pkg_version_maj_min)/${PKG_NAME}-${PKG_VERSION}.tar.xz"
-PKG_DEPENDS_HOST="libffi:host Python3:host meson:host ninja:host"
+PKG_DEPENDS_HOST="libffi:host Python3:host meson:host ninja:host pcre:host"
PKG_DEPENDS_TARGET="toolchain pcre zlib libffi Python3:host util-linux"
PKG_LONGDESC="A library which includes support routines for C such as lists, trees, hashes, memory allocation."
PKG_TOOLCHAIN="meson"
But now also gdb failed. Maybe bump to 10.2 will help. And bunch of other packages failed too.
Grub for example with same run issue - seems it needs build for host and target.
/home/peter/LibreELEC/LibreELEC.tv/build.LibreELEC-Generic.x86_64-10.0-devel/build/grub-635ef55ed1252f92fe3bf70caefd185dcc507c43/grub-mkimage: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.33 not found (required by /home/peter/LibreELEC/LibreELEC.tv/build.LibreELEC-Generic.x86_64-10.0-devel/build/grub-635ef55ed1252f92fe3bf70caefd185dcc507c43/grub-mkimage)
I’n my dev tree, there has been plenty of bumps and patches… blues and glib definitely. i don’t have the pcre:host in mine though. https://github.com/heitbaum/LibreELEC.tv/tree/dev your fix for config/functions got me thinking that this is similar to #5535 - in that need to check python properties options in that bug and see what is being set, if that is indeed an option.
Need to look in to these 2 properties too: git grep sys_root and git grep pkg_config_libdir https://mesonbuild.com/Cross-compilation.html
@vpeter4 - I think your solution is spot on. Might be some other things that are “wrong” in the cross compilers, but it is exactly the same symptoms as the rust/cargo issue host and target triples equaling.
I have added the fix to my dev tree and am going to run it through its paces. I want to read https://mesonbuild.com/Cross-compilation.html a few more times (understand how those other variables influence the build) and now to try to address the other identified build issues #5294, #5486 (fix in test), #5535, #5538.
No immediate need to PR it, as the build currently runs through fine, even with GLIBC differences 👍.
—
toolchain: always use cross compile and exe_wrapper with meson This needs to be done even on target=host due to libraries of the host being newer than the target. This fixes tests where target glibc is different from host glibc and meson tries to check existance of 2 functions which are in GLIBC_2.34 in this example. It is also correct functionality, as we will never be building for the host the compile is on.
`Program stderr:
/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-10.0-devel/build/glib-37e5dfd3a2ced10c395b38702ae15e0e128e457b/.x86_64-libreelec-linux-gnu/meson-private/tmpg908xy4s/output.exe:
/lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.34' not found (required by /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-10.0-devel/build/glib-37e5dfd3a2ced10c395b38702ae15e0e128e457b/.x86_64-libreelec-linux-gnu/meson-private/tmpg908xy4s/output.exe)
Running into sam issue on k1om Intel Xeon Phi architecture too.
@sigkill - does this fix your scenario?
diff --git a/config/functions b/config/functions
index 9954c23fba..8f56249606 100644
--- a/config/functions
+++ b/config/functions
@@ -513,6 +513,7 @@ cpu = '$TARGET_SUBARCH'
endian = 'little'
[properties]
+needs_exe_wrapper = true
root = '$SYSROOT_PREFIX/usr'
$(python3 -c "import os; print('c_args = {}'.format([x for x in os.getenv('TARGET_CFLAGS').split()]))")
$(python3 -c "import os; print('c_link_args = {}'.format([x for x in os.getenv('TARGET_LDFLAGS').split()]))")
Will give it a try!