Hi again,
(after Easter hiatus … or rather xz backdoor meltdown?)
I had a stab at this, detecting a system that forces 64 bit offsets on
a 32 bit base in configure. This is to ensure that you do not encounter
the same symbol (like mpg123_tell() on two builds of the library on the
same platform offering a differing ABI (32 or 64 bit argument or return
value).
This is supposed to look like that:
$ CPPFLAGS=-D_FILE_OFFSET_BITS=64 ./configure
[…]
checking switched off_t size... 8
checking unswitched off_t size... 4
checking size of off_t... 8
configure: Detected system with enforced 64 bit offsets, dropping suffixless
symbols for uncryptic ABI breakage.
checking if native off_t is already 64 bits... yes
[…]
default offsets ......... 64
explicit 64 bit offsets . no
forced 64 bit offsets ... yes
[…]
This removes the ambiguous symbols from libmpg123.so and libsyn123.so.
With unchanged soversion, client code built for the earlier version
before the off_t/time_t 64 bit switch will fall in two categories:
1. Built with enabled large file support: Continues to work, no
breakage.
2. Built without large file support: Will break early at runtime
linking stage.
There might be applications that just use API not affected by off_t
changes and thus are fine either way.
Can you verify that the prospective 1.32.6 (named 1.32.6-dev) under
http://mpg123.org/snapshot/mpg123-1.32.6-dev+20240403022201.tar.bz2
works fine in the debian build and meets expectations? I'd do a proper
release of it soon, then.
It's up to you (Debian) to decide what to do with binary package naming
for the transition (it is your business anyway;-), but I feel strongly
about the change to avoid an existing symbol changing ABI with subtle
breakage. I also think it is reasonable not to invest work into yet
another set of wrappers to put 32 bit offsets on life suppport on a
system that follows the decision to enforce 64 bits. The setup of
wrappers and alias calls in mpg123 code is confusing enough already.
Alrighty then,
Thomas
