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