Created attachment 528448 [details] output of sudo armv7a-pip-linux-gnueabi-emerge --info I am building a Gentoo system for my ARM based Beaglebone Black from scratch using a toolchain setup with crossdev. Most packages in @system build fine, but a handful fail, including this one. More detailed error message below: Checking for size of "pid_t": 4 Checking for size of "uid_t": 4 Checking for size of "gid_t": 4 Checking for size of "dev_t": 8 Checking for size of "ino_t": 8 Checking for size of "time_t": 4 Checking for size of "rlim_t": 8 Checking for size of "char16_t": 2 Checking for size of "char32_t": 4 Checking for size of "key_serial_t": -1 Checking for size of "struct ethtool_link_settings": 48 Checking for size of "struct fib_rule_uid_range": 8 meson.build:483:8: ERROR: Cross-compile check overflowed A full log can be found at /usr/armv7a-pip-linux-gnueabi/tmp/portage/sys-apps/systemd-238-r6/work/systemd-238-.arm/meson-logs/meson-log.txt * ERROR: sys-apps/systemd-238-r6::gentoo failed (configure phase): * (no error message) [snip] Relevant meson-log.txt output below: Running compile: Working directory: /usr/armv7a-pip-linux-gnueabi/tmp/portage/sys-apps/systemd-238-r6/temp/tmp09ze0z1e Command line: armv7a-pip-linux-gnueabi-gcc /usr/armv7a-pip-linux-gnueabi/tmp/portage/sys-apps/systemd-238-r6/temp/tmp09ze0z1e/testfile.c -O0 -std=gnu99 -pipe -D_FILE_OFFSET_BITS=64 -c -o /usr/armv7a-pip-linux-gnueabi/tmp/portage/sys-apps/systemd-238-r6/temp/tmp09ze0z1e/output.obj Code: #include <stdio.h> #include <uchar.h> #include <linux/ethtool.h> #include <linux/fib_rules.h> #include <linux/stat.h> #include <sys/stat.h> int main() { static int a[1-2*!(sizeof(struct statx) == 127)]; a[0]=0; return 0; } Compiler stdout: Compiler stderr: /usr/armv7a-pip-linux-gnueabi/tmp/portage/sys-apps/systemd-238-r6/temp/tmp09ze0z1e/testfile.c: In function ‘main’: /usr/armv7a-pip-linux-gnueabi/tmp/portage/sys-apps/systemd-238-r6/temp/tmp09ze0z1e/testfile.c:9:33: error: size of array ‘a’ is negative int main() { static int a[1-2*!(sizeof(struct statx) == 127)]; a[0]=0; return 0; } ^ meson.build:483:8: ERROR: Cross-compile check overflowed [snip] I compiled a modified version of that source code (additionally declared a global struct statx variable) and used gdb to determine whta sizeof(struct statx) is. It's 256 both for my native compiler and the armv7a-pip-linux-gnueabi cross compiler. From what I can glean, the only purpose of this test is to verify that sizeof struct statx is 127 bytes. But that doesn't make much sense, so I must be missing something.
Created attachment 528450 [details] output of sudo emerge --info
Created attachment 528452 [details] build.log
Created attachment 528454 [details] build-.arm.log
Created attachment 528456 [details] meson-arm7va-pip-linux-gnueabi
Created attachment 528458 [details] meson-log.txt
Created attachment 528460 [details] eclass-debug.log
Created attachment 528462 [details] environment
Created attachment 528464 [details] configure
Created attachment 528466 [details, diff] meson.build work/systemd-238/meson.build Look at line 483. Relevant excerpt: ##################################################################### # compilation result tests conf.set('_GNU_SOURCE', true) conf.set('__SANE_USERSPACE_TYPES__', true) conf.set('SIZEOF_PID_T', cc.sizeof('pid_t', prefix : '#include <sys/types.h>')) conf.set('SIZEOF_UID_T', cc.sizeof('uid_t', prefix : '#include <sys/types.h>')) conf.set('SIZEOF_GID_T', cc.sizeof('gid_t', prefix : '#include <sys/types.h>')) conf.set('SIZEOF_DEV_T', cc.sizeof('dev_t', prefix : '#include <sys/types.h>')) conf.set('SIZEOF_INO_T', cc.sizeof('ino_t', prefix : '#include <sys/types.h>')) conf.set('SIZEOF_TIME_T', cc.sizeof('time_t', prefix : '#include <sys/time.h>')) conf.set('SIZEOF_RLIM_T', cc.sizeof('rlim_t', prefix : '#include <sys/resource.h>')) decl_headers = ''' #include <uchar.h> #include <linux/ethtool.h> #include <linux/fib_rules.h> #include <linux/stat.h> #include <sys/stat.h> ''' # FIXME: key_serial_t is only defined in keyutils.h, this is bound to fail foreach decl : ['char16_t', 'char32_t', 'key_serial_t', 'struct ethtool_link_settings', 'struct fib_rule_uid_range', 'struct statx', ] # We get -1 if the size cannot be determined have = cc.sizeof(decl, prefix : decl_headers) > 0 conf.set10('HAVE_' + decl.underscorify().to_upper(), have) endforeach
Looks like meson may be broken. This commit is suspect: https://github.com/mesonbuild/meson/commit/df1480fe11e5d4f20b7305abc2129d3c6494d1b5
(In reply to Joe Harvell from comment #10) > Looks like meson may be broken. This commit is suspect: > https://github.com/mesonbuild/meson/commit/ > df1480fe11e5d4f20b7305abc2129d3c6494d1b5 I see what's happening. When cross compiling, meson code tries to figure out the size of a type by guessing the size of the struct (using a low and high guess), and sequentially compiling test programs that will pass/fail compile based on whether the guess is >= or == the actual size. But this only works if the size is in the range of the low/high guess. In this case, the logic that is guessing at the size of statx assumes it must be less than or equal to 128 bytes, but it is actually 256 bytes. Now I just need to find where the logic is that guesses 128 bytes.
The meson code that checks for the sizes on a cross system only supports structures up to 128 bytes. So meson is the reason this is failing. The meson project commit that broke it is https://github.com/mesonbuild/meson/commit/df1480fe11e5d4f20b7305abc2129d3c6494d1b5 And the line number in that commit that has the 128 byte limitation mesonbuild/compilers.py (new) line 1061: return self.cross_compute_int('sizeof(%s)' % typename, 1, 128, None, prefix, env, extra_args, dependencies) This parameters 1 and 128 are the min/max sizes.
I added a comment to the merged Pull Request: https://github.com/mesonbuild/meson/pull/1456/files
Looks like meson already fixed this bug. This build of systemd is using meson 0.45.1. There is 0.46.0 in which this bug is fixed. Apparently, this build is using meson installed on the build system, not the host system. I am going to do a version bump for meson to fix this issue. By the way, shouldn't the build be using meson on the host, not the build system? Part of the problem is when you build with gentoo-cross it ignores build dependencies for some reason. So when I am doing emerge -ea1v @system, it is not build meson in the build system prior to systemd even though systemd needs it to build and probaly lists it as a DEPEND. Ugh!
I upgraded meson from 0.45.1 to 0.46.0 on the build machine and I can see from the cross compile of systemd that it is using 0.46.0. So I can confirm it is using the build system of meson instead of building it as a build dependency of systemd then using from the host system. Also, the error reported in this defect no longer occurs. It successfully detects the size of struct statx to be 256. But the build is now breaking in configure with the following message: Dependency threads found: YES Library rt found: YES Library m found: YES Library dl found: YES Library crypt found: YES Cross dependency libcap found: YES 2.25 meson.build:845:0: ERROR: Cross dependency 'mount' not found A full log can be found at /usr/armv7a-pip-linux-gnueabi/tmp/portage/sys-apps/systemd-238-r6/work/systemd-238-.arm/meson-logs/meson-log.txt * ERROR: sys-apps/systemd-238-r6::gentoo failed (configure phase):
Created attachment 528470 [details] meson-log.txt after upgrading to meson 0.46.1
It looks like the new configure error "cross dependency mount not found" is because the host system does not have the mount program installed yet. This is provided by package sys-apps/util-linux, which is listed as a DEPENDS in the systemd ebuild. However, emerging with cross-emerge passes --root-deps=rdeps to the emerge command. See below: --root-deps[=rdeps] If no argument is given then build-time dependencies of packages for ROOT are installed to ROOT instead of /. If the rdeps argument is given then discard all build-time dependencies of packages for ROOT. This option is only meaningful when used together with ROOT and it should not be enabled under normal circumstances! Not sure why cross-emerge is trying to build packages whose build dependencies are not satisfied. I will have to follow up with the crossdev team. At this point, I have filed a version bump for meson, so there is no valid problem left for systemd.
Just one last note in case anyone is looking at this. I have now successfully installed systemd as follows: sudo "USE=build -systemd" armv7a-pip-linux-gnueabi-emerge -a1v sys-apps/util-linux sudo armv7a-pip-linux-gnueabi-emerge -a1v sys-apps/systemd Now I should be able to rebuild util-linux without the special USE flags
Same issue with sys-apps/systemd-238-r7 - after updating to dev-util/meson-0.46.0 - what is flagged as unstable - the build works.
Same issue with systemd-238-r7 abi_x86_32 compilation on amd64 system
