LibreELEC.tv icon indicating copy to clipboard operation
LibreELEC.tv copied to clipboard

[BUG] Cross Compiled meson not using cross compiled libraries and failing meson.build tests

Open heitbaum opened this issue 4 years ago • 7 comments

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.

heitbaum avatar Aug 07 '21 08:08 heitbaum

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)

vpeter4 avatar Aug 07 '21 17:08 vpeter4

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.

heitbaum avatar Aug 07 '21 19:08 heitbaum

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

heitbaum avatar Aug 07 '21 20:08 heitbaum

@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)

heitbaum avatar Aug 08 '21 06:08 heitbaum

Running into sam issue on k1om Intel Xeon Phi architecture too.

sigkill avatar Aug 11 '21 22:08 sigkill

@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()]))")

heitbaum avatar Aug 11 '21 22:08 heitbaum

Will give it a try!

sigkill avatar Aug 12 '21 04:08 sigkill