Am Sat, 20 Jun 2020 15:03:32 +0200 schrieb Christian Klein <dvl...@gmail.com>:
> 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
