[Pkg-sssd-devel] Bug#1086769: uid-wrapper FTBFS on hppa, powerpc and x32

[Helge Deller]

Hi Simon,

On 11/6/24 09:26, Simon Josefsson wrote:
> Hi.  The uid-wrapper autopkgtest fails on armel and armhf:
>
> https://tracker.debian.org/pkg/uid-wrapper
> https://ci.debian.net/packages/u/uid-wrapper/testing/armel/54125843/
> https://ci.debian.net/packages/u/uid-wrapper/testing/armhf/54125865/
>
> The C flags are hidden, and I am working on unhiding them via
> -DCMAKE_VERBOSE_MAKEFILE=ON but it doesn't look like the self-tests are
> built with -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64, unless that comes
> from config.h: https://salsa.debian.org/jas/uid-wrapper/-/jobs/6543041
>
> The failing code here is uid-wrapper/tests/test_syscall.c line 53:
>
> 	assert_int_equal(tv1.tv_sec, tv2.tv_sec);
>
> Maybe the previous arm32 patch is still relevant?

No, the previous arm32 patch was just a hack and is completely wrong.

This is the error reported:
[  ERROR   ] --- 0x672a9fe1 != 0xf2839672a9fe1
0xf2839672a9fe1 is the value which is stored in tv2.tv_sec.
That number is a 64-bit value (you need more than 32bits to store that value).
So, "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" was definitively set in your build,
otherwise tv2.tv_sec would not be 64-bits wide.

> Reading that self-test makes me wonder if it really support
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64.  The code is low-level so
> shouldn't it have internal magic for the 32-bit vs 64-bit case?

This library should do no magic.
It should simply emulate the original syscalls correctly.

> uid-wrapper generally: the self test checks gettimeofday vs
> SYS_gettimeofday, but uid-wrapper never does anything related to
> gettimeofday.

Right.

> As discussed in
> https://gitlab.com/cwrap/uid_wrapper/-/issues/1 one fix would be to use
> a SYS_gettimeofday64 call instead, but that doesn't seem to exist.

Right. There is no such syscall.
Instead glibc uses clock_gettime() to provide a 64-bit time on 32-bit platforms.
So, there is no need for uid-wrapper to emulate such a call.

> Maybe the purpose of this self-test is to merely test the syscall
> facility, and that they happened to pick gettimeofday which used to be
> an uncomplicated interface but lately haven't been?

Yes, I think so.
As an example, the x32 build currently fails because the syscall isn't executed.

> Thoughts?  Maybe just add back Draw's patch?

No.

Helge