Bug#963205: libmpg123-dev no longer multiarch installable
Am Sun, 21 Jun 2020 11:23:32 +0200
schrieb Sebastian Ramacher :
> I am wondering why syn123 and mpg123 use different approaches to achieve
> the same thing. The mpg123-way of handling off_t using functions is
> known to work and doesn't require any quirks on the Debian packaging
> side. Why doesn't syn123 also use MPG123_LARGENAME?
Well, then. I need to dive into this myself, again. First: syn123 is
using the same approach as MPG123_LARGENAME, actually. It is just
avoiding the flexible macro machinery to cover only two functions that
are affected. But the basic behaviour is the same
- _FILE_OFFSET_BITS==32: foo123_func → foo123_func_32
- _FILE_OFFSET_BITS==64: foo123_func → foo123_func_64
A difference is in how the libraries are built. In libmpg123, I used
off_t in the library, and it appeared in the API for a while, without
dealing with the issues of possible mismatch in large file support in
lib and client applications. There was a very painful transition to
make libmpg123 offer both LFS settings in one library like glibc does.
This resulted in warts like
src/libmpg123/lfs_alias.c
src/libmpg123/lfs_wrap.c
for the need to sport foo123_func, foo123_func_32, and foo123_func_64
in the same library (any of those can be an alias or wrapper, depening
on mpg123 build setup), to be compatible with all user binaries.
For syn123, off_t entered late in the game and there' actually no I/O
involved. It's just about function argument types. I decided to
simplify things by hardcoding _32 and _64 variants and having the
header decide at compile time which one is used.
The case of no _FILE_OFFSET_BITS being defined, in lack of a generic
suffix-less function for that case, results in the value LFS_ALIAS_BITS
being used. This results from this configure code:
dnl The native type used for aliases is what off_t maps to without any
largefile-
dnl enabling switches. So, it's long int if the system is largefile-senstive,
dnl but it is actual plain off_t if the system does not have such switches.
if test "x$largefile_sensitive" = xyes; then
lfs_alias_type=long
lfs_alias_size=$ac_cv_sizeof_long
elif test "x$android_build" = xyes; then
lfs_alias_type=off64_t
lfs_alias_size=$ac_cv_sizeof_off64_t
else
lfs_alias_type=off_t
lfs_alias_size=$ac_cv_sizeof_off_t
fi
if test "x$lfs_alias_size" = "x"; then
AC_MSG_ERROR([Cannot determine sizeof(lfs_alias_t)?])
else
LFS_ALIAS_BITS=`expr "$lfs_alias_size" "*" "8"`
AC_DEFINE_UNQUOTED([lfs_alias_t], $lfs_alias_type,
[Define to the native offset type (long or actually off_t).])
AC_DEFINE_UNQUOTED([LFS_ALIAS_BITS], $LFS_ALIAS_BITS,
[Define this to the size of native offset type in bits, used for LFS alias
functions.])
fi
If we can get that logic into the header itself, it would be
arch-agnostic again. Is that easy enough? Otherwise, I'd have to add
plain wrappers named syn123_resample_total and syn123_resample_intotal,
like:
lfs_alias_t syn123_resample_total(long inrate, long outrate, lfs_alias_t ins)
{
#if LFS_ALIAS_BITS+0 == 64
return syn123_resample_total_64(inrate, outrate, ins);
#elif LFS_ALIAS_BITS+0 == 32
return syn123_resample_total_32(inrate, outrate, ins);
#else
#error "Unexpected LFS_ALIAS_BITS value."
#endif
}
lfs_alias_t syn123_resample_intotal(long inrate, long outrate, lfs_alias_t outs)
{
#if LFS_ALIAS_BITS+0 == 64
return syn123_resample_intotal_64(inrate, outrate, outs);
#elif LFS_ALIAS_BITS+0 == 32
return syn123_resample_intotal_32(inrate, outrate, outs);
#else
#error "Unexpected LFS_ALIAS_BITS value."
#endif
}
It's all ugly crap that we could avoid if we'd only settle for LFS
support being a fixed property of an architecture/OS setup, off_t not
being a chimera depending on a preprocessor switch.
Do you have a suggestion to avoid using @LFS_ALIAS_BITS@ in the header
and still keep the correct logic catering for the cases for choosing
lfs_alias_t?
If not, I guess I could add these two wrappers and forget about them,
as the code in question won't change much and I don't intend to add
more LFS-aware functions to syn123.
But I really was burned by what I had to do for libmpg123 and did not
want to repeat all that cruft.
Alrighty then,
Thomas
pgpGTJc_xhdDc.pgp
Description: Firma digital OpenPGP
Bug#963205: libmpg123-dev no longer multiarch installable
On 2020-06-20 20:37:08 +0200, Thomas Orgis wrote: > Am Sat, 20 Jun 2020 15:03:32 +0200 > schrieb Christian Klein : > > > A diff of the header files reveals that the i386 and amd64 versions are now > > different: > > > -#define syn123_resample_total syn123_resample_total_32 > > -#define syn123_resample_intotal syn123_resample_intotal_32 > > +#define syn123_resample_total syn123_resample_total_64 > > +#define syn123_resample_intotal syn123_resample_intotal_64 > > > I guess the problem was introduced by upstream. > > Indeed. I am upstream and I confirm that I wrote this. But I did not > intend to break multiarch … I just didn't think about it. This is a > fallback for _FILE_OFFSET_BITS not being defined by the client > application. The fallback is to define off_t as long, basically, which > differs on 32 or 64 bit arch. Well one could drop the fallback and > return an error that the client application needs to define > _FILE_OFFSET_BITS … but then, there is no good solution when you got > off_t sometimes as 32 bit and sometimes as 64 bit on the same platform, > depending on a switch. > > The largefile (off_t) stuff in libsyn123 is simpler than all the hoops > libmpg123 goes through, with implementing dual mode and wrappery in the > library. Here, the library works with fixed 64 or 32 bits and the > header shall choose the implementation that matches the client offset > size. It has the side effect of the fallback being different. > > You could argue that I should have just used int64_t externally, but > the unspecific off_t is the natural type for file/stream offsets … at > least I'd like to pretend that it is:-/ Same reason I use size_t for > memory sizes. > > Is it big trouble to separate the syn123 header into multiarch subdirs > to fix debian again? Would you rather have some switch in the same > header about native off_t/long size? I am wondering why syn123 and mpg123 use different approaches to achieve the same thing. The mpg123-way of handling off_t using functions is known to work and doesn't require any quirks on the Debian packaging side. Why doesn't syn123 also use MPG123_LARGENAME? Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#963205: libmpg123-dev no longer multiarch installable
Am Sat, 20 Jun 2020 15:03:32 +0200 schrieb Christian Klein : > A diff of the header files reveals that the i386 and amd64 versions are now > different: > -#define syn123_resample_total syn123_resample_total_32 > -#define syn123_resample_intotal syn123_resample_intotal_32 > +#define syn123_resample_total syn123_resample_total_64 > +#define syn123_resample_intotal syn123_resample_intotal_64 > I guess the problem was introduced by upstream. Indeed. I am upstream and I confirm that I wrote this. But I did not intend to break multiarch … I just didn't think about it. This is a fallback for _FILE_OFFSET_BITS not being defined by the client application. The fallback is to define off_t as long, basically, which differs on 32 or 64 bit arch. Well one could drop the fallback and return an error that the client application needs to define _FILE_OFFSET_BITS … but then, there is no good solution when you got off_t sometimes as 32 bit and sometimes as 64 bit on the same platform, depending on a switch. The largefile (off_t) stuff in libsyn123 is simpler than all the hoops libmpg123 goes through, with implementing dual mode and wrappery in the library. Here, the library works with fixed 64 or 32 bits and the header shall choose the implementation that matches the client offset size. It has the side effect of the fallback being different. You could argue that I should have just used int64_t externally, but the unspecific off_t is the natural type for file/stream offsets … at least I'd like to pretend that it is:-/ Same reason I use size_t for memory sizes. Is it big trouble to separate the syn123 header into multiarch subdirs to fix debian again? Would you rather have some switch in the same header about native off_t/long size? Alrighty then, Thomas
Bug#963205: libmpg123-dev no longer multiarch installable
Package: libmpg123-dev Version: 1.26.1-1 Severity: important The i386 and amd64 versions of the dev-package are no longer co-installable. Unpacking libmpg123-dev:i386 (1.26.1-1) ... dpkg: error processing archive /tmp/apt-dpkg-install- ZpltIr/09-libmpg123-dev_1.26.1-1_i386.deb (--unpack): trying to overwrite shared '/usr/include/syn123.h', which is different from other instances of package libmpg123-dev:i386 A diff of the header files reveals that the i386 and amd64 versions are now different: $ diff -Naur 32/usr/include/syn123.h 64/usr/include/syn123.h --- 32/usr/include/syn123.h 2020-06-19 23:19:16.0 +0200 +++ 64/usr/include/syn123.h 2020-06-19 23:19:16.0 +0200 @@ -978,8 +978,8 @@ #error "Unpredicted _FILE_OFFSET_BITS value." # endif #else -#define syn123_resample_total syn123_resample_total_32 -#define syn123_resample_intotal syn123_resample_intotal_32 +#define syn123_resample_total syn123_resample_total_64 +#define syn123_resample_intotal syn123_resample_intotal_64 #endif /** Give exact output sample count for total input sample count. $ I guess the problem was introduced by upstream. This makes it impossible (or at least very hard) to build multiarch software like, for example, wine. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (999, 'unstable'), (998, 'testing'), (990, 'stable'), (500, 'unstable-debug'), (350, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
