Bug#1067247: pulseaudio: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"

[Simon McVittie]

On Wed, 20 Mar 2024 at 20:00:32 +0000, Thorsten Glaser wrote:
> Unfortunately, as with umockdev, I have no idea what is going on
> here… does it #undef _FILE_OFFSET_BITS or something?

Yes it does. padsp(1) is based on a LD_PRELOAD module similar to those
used in fakeroot, fakechroot, umockdev and so on, which works by
interposing a bunch of glibc functions including stat(). As currently
implemented, it achieves this by #undef'ing the _FILE_OFFSET_BITS feature
test so that it can interpose all flavours of stat(), including
stat64() and so on.

Since glibc 2.34, on 32-bit architectures all such LD_PRELOAD modules
need updating to also interpose __lstat64_time64(), __stat64_time64(),
__fstat64_time64() and __fstatat64_time64() on architectures where they
exist - otherwise, programs and libraries compiled with 64-bit time_t
will bypass the wrapped stat(), stat64() etc. and call __stat64_time64()
instead, and therefore the wrapping will be ineffective and padsp will
not work as intended.

Because padsp is not core functionality for pulseaudio, a brute-force
approach to unblocking this could be to disable it on 32-bit non-i386
architectures. Untested pseudocode:

--- meson.build
+++ meson.build
 if cc.has_header('sys/soundcard.h', required: get_option('oss-output'))
   # OSS output via daemon module-detect
   cdata.set('HAVE_OSS_OUTPUT', 1)
   # OSS wrapper
-  cdata.set('HAVE_OSS_WRAPPER', 1)
+  if cc.sizeof('void *') >= 8 or host_machine.cpu_family() == 'x86'
+    cdata.set('HAVE_OSS_WRAPPER', 1)
+  endif
   cdata.set('PULSEDSP_LOCATION', pulsedsp_location)
 endif

(and then change the packaging to tolerate it not being installed)

In practice padsp is mainly useful for legacy i386 binaries and maybe
a few very early legacy amd64 binaries (late 90s/early 00s era games,
especially ported by Loki Games) which might assume OSS audio, and not
support ALSA or PulseAudio directly. Since we're breaking the platform ABI
on armel/armhf/etc. *anyway*, we can't rely on the ability to run legacy
binaries even if they exist, so it's probably no longer interesting to
provide padsp on those architectures.

    smcv