Bug 15720 - socket_wrapper: armhf+armel failures due to 64-bit time_t on 32-bit host with _FILE_OFFSET_BITS=64
Summary: socket_wrapper: armhf+armel failures due to 64-bit time_t on 32-bit host with...
Status: NEW
Alias: None
Product: cwrap
Classification: Unclassified
Component: library (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Andreas Schneider
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-09-23 12:30 UTC by Simon Josefsson
Modified: 2024-09-30 06:57 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Josefsson 2024-09-23 12:30:29 UTC
Hi.

There is a Debian bug about build failures on armel+armhf after the recent time_t 64-bit transition in Debian.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069450

I am currently in the process of uploading a new version without support for armel+armhf because I do not what the proper fix for those platforms are.

What is upstream's thoughts on how to solve this?

/Simon

Btw, there were some IRC discussion around this:

jas4711
hi! seems like there are test failures for uid-wrapper, socket-wrapper and priv-wrapper on 32-bit arm (armhf, armel)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069425
#1069425 - uid-wrapper: FTBFS on armhf: 15: [ LINE ] --- ./tests/test_syscall.c:53: error: Failure! - Debian Bug report logs
Debian Bug report logs - #1069425 uid-wrapper: FTBFS on armhf: 15: [ LINE ] --- ./tests/test_syscall.c:53: error: Failure! Package: src:uid-wrapper ; Maintainer for src:uid-wrapper is
i did a new upload of uid-wrapper and debian's build robots also trigger this: https://buildd.debian.org/status/package.php?p=uid-wrapper
Buildd status for uid-wrapper (sid)
Debian Package Auto-Building Buildd status for uid-wrapper (sid) Tracker – Changelog – Bugs – packages.d.o – Source Package(s): Suite: sid trixie trixie-backports trixie-backports-sloppy
tests/test_syscall.c:53 is assert_int_equal(tv1.tv_sec, tv2.tv_sec) so this looks time 32-bit vs 64-bit related
does anyone have ideas?  source code is here: https://gitlab.com/cwrap/uid_wrapper/-/blob/c8bf3ae675b47726d65e83e3abf62cafa93b12e6/tests/test_syscall.c#L53
tests/test_syscall.c · c8bf3ae675b47726d65e83e3abf62cafa93b12e6 · cwrap / uid_wrapper · GitLab - GitLab
This is a tool to fake user and group switching. https://cwrap.org
socket-wrapper bug is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069450
#1069450 - socket-wrapper: FTBFS on armhf: features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" - Debian Bug report logs
Debian Bug report logs - #1069450 socket-wrapper: FTBFS on armhf: features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" Package: src:socket-wrapper
that also looks time 32-bit vs 64-bit related
priv-wrapper bug is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069486
#1069486 - priv-wrapper: FTBFS on armhf: 1: [ LINE ] --- ./tests/test_setrlimit.c:63: error: Failure! - Debian Bug report logs
Debian Bug report logs - #1069486 priv-wrapper: FTBFS on armhf: 1: [ LINE ] --- ./tests/test_setrlimit.c:63: error: Failure! Package: src:priv-wrapper ; Maintainer for src:priv-wrapper
that one looks a bit different, and may be due to something else
asn
maybe _FILE_OFFSET_BITS=64 needs to be set for the tests
mån 29 apr. 2024
Andrew Bartlett (abartlet)
I wondered when this would come up.  time_t as 64 bits enforced  _FILE_OFFSET_BITS=64 but our socket_wrapper fixes recently rely on being able to build without _FILE_OFFSET_BITS=64 otherwise the symbols get renamed in ways that break stuff
Andrew Bartlett (abartlet)
I've tried to reply to the bug with details to avoid folks wasting time creating a fix that will just break the delicate balance required to have the fcntl tests work
asn
Andrew Bartlett (abartlet): None of the wrappers should be built with _FILE_OFFSET_BITS=64!
Andrew Bartlett (abartlet)
exactly, but for the 64 bit time_t, that is the requirement
they didn't think it was sane to also support 32 bit files and 64 bit time
so there is a problem
if 32 bit files are now extinct on that platform, perhaps something can be worked out, but it is going to be ugly to have that and still have i386 working
and I think they were only rebuilding packages that seemed to reference time
asn
Only the tests which use time_t failed
It is fine to set _FILE_OFFSET_BITS=64 for executable tests
I would be more worried about libsmbclient ;-)
Andrew Bartlett (abartlet)
Sure, but see the socket_wrapper bug
Comment 1 Andreas Schneider 2024-09-24 08:32:15 UTC
Hi Simon,

if time_t moved to 64bit on 32bit platforms on Debian, then the question is how does libc handle that?

In the end getimeofday() is just a glibc wrapper for the syscall. So which syscall is glibc calling to do the right thing?
Comment 2 Andrew Bartlett 2024-09-25 01:09:12 UTC
https://wiki.debian.org/ReleaseGoals/64bit-time has the details, the challenge here is the glibc enforces LFS for 64-bit time_t.
Comment 3 Andreas Schneider 2024-09-30 06:57:20 UTC
https://wiki.debian.org/ReleaseGoals/64bit-time states:

Change gcc-* to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 by default. 


-D_FILE_OFFSET_BITS=64 should not be set for the wrappers. I think we also need an #undef _TIME_BITS.

socket_wrapper uses gettimeofday, it looks like there is an gettimeofday64 or __gettimeofday64. We probably have to check for that and use it.