Bug#1055573: dh_makeshlibs: time64 compatibility is wrong for some architectures
On Sat, Dec 02, 2023 at 02:58:00PM +0100, John Paul Adrian Glaubitz wrote: > > Maybe instead of duplicating this, debhelper can access it? > I agree with Helmut's suggestion. debhelper should be able to deal with > 32-bit architectures that already support 64-bit time_t. > If we ignore these, we could run into issues with potential new 32-bit ports > such as ARC. debhelper handling of 64-bit time_t is limited to deciding whether or not to emit Provides: for the library package name without the 't64' tag. It is only of value for maintaining dependency compatibility with existing runtime library packages built before the transition. The impact for *NEW* architectures is therefore moot, regardless. For similar reasons, I expect it to be low impact for the other already-defined architectures here as well. If any of these named architectures have public stable archives at all, it is nevertheless exceedingly unlikely that there are third-party packages built *against* such an archive that anyone cares about maintaining binary compatibility with. So while this bug is 100% technically correct, I can't see that there is any practical impact at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1055573: dh_makeshlibs: time64 compatibility is wrong for some architectures
Hi! > Guillem curated a list in /usr/share/perl5/Dpkg/Vendor/Debian.pm: > > * arm > * armeb > * armel > * armhf > * hppa > * i386 > * hurd-i386 > * kfreebsd-i386 > * m68k > * mips > * mipsel > * mipsn32 > * mipsn32el > * mipsn32r6 > * mipsn32r6el > * mipsr6 > * mipsr6el > * nios2 > * powerpc > * powerpcel > * powerpcspe > * s390 > * sh3 > * sh3eb > * sh4 > * sh4eb > * sparc > > This looks more complete, but it misses arm64ilp32. > > Maybe instead of duplicating this, debhelper can access it? I agree with Helmut's suggestion. debhelper should be able to deal with 32-bit architectures that already support 64-bit time_t. If we ignore these, we could run into issues with potential new 32-bit ports such as ARC. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1055573: dh_makeshlibs: time64 compatibility is wrong for some architectures
On Wed, Nov 08, 2023 at 10:43:32AM +0100, Helmut Grohne wrote: > So I think rather than evaluating the bits here, I think we should > enumerate all architectures that currently are time32 and assume that > all others (and future ones) will be time64. That list would be: > > * arm<- I know it's dead. Completeness. > * arm64ilp32 > * armel > * armhf > * hppa > * i386 <- You want to delete this. > * m68k > * mips > * mips32r6 > * mips32r6el > * mipsel > * mipsn32 > * mipsn32el > * powerpc > * s390 > * sh3 > * sh4 > * sparc Guillem curated a list in /usr/share/perl5/Dpkg/Vendor/Debian.pm: * arm * armeb * armel * armhf * hppa * i386 * hurd-i386 * kfreebsd-i386 * m68k * mips * mipsel * mipsn32 * mipsn32el * mipsn32r6 * mipsn32r6el * mipsr6 * mipsr6el * nios2 * powerpc * powerpcel * powerpcspe * s390 * sh3 * sh3eb * sh4 * sh4eb * sparc This looks more complete, but it misses arm64ilp32. Maybe instead of duplicating this, debhelper can access it? Helmut
Bug#1055573: dh_makeshlibs: time64 compatibility is wrong for some architectures
Package: debhelper Version: 13.11.7 Severity: important X-Debbugs-Cc: vor...@debian.org Hi Steve, I was made aware that your extension to dh_makeshlibs was wrong and since I happened to upload it, I figured it was my duty to report the issue. We may think if time bits as 64bit architectures have 64bit time already and that's right. However, the converse is wrong. Some 32bit architectures have 64bit time as well. In particular, Linux mandates a time64 ABI for new architectures. That happens to cover at least x32, riscv32 and arc. If new architectures are about to appear later, we should also assume them to be 64bit time. Uwe Kleine-König was kind enough to update https://wiki.debian.org/ArchitectureSpecificsMemo with a column concerning time_t. He also suggested a test: printf '#include \n__TIMESIZE' | cpp | tail -n1 I ran this for architectures that Debian has cross toolchains for: aarch64-linux-gnu-cpp 64 alpha-linux-gnu-cpp 64 arc-linux-gnu-cpp 64 arm-linux-gnueabi-cpp 32 arm-linux-gnueabihf-cpp 32 hppa-linux-gnu-cpp 32 i686-linux-gnu-cpp 32 m68k-linux-gnu-cpp 32 mips-linux-gnu-cpp 32 mips64-linux-gnuabi64-cpp 64 mips64el-linux-gnuabi64-cpp 64 mipsel-linux-gnu-cpp 32 mipsisa32r6-linux-gnu-cpp 32 mipsisa32r6el-linux-gnu-cpp 32 mipsisa64r6-linux-gnuabi64-cpp 64 mipsisa64r6el-linux-gnuabi64-cpp 64 powerpc-linux-gnu-cpp 32 powerpc64-linux-gnu-cpp 64 powerpc64le-linux-gnu-cpp 64 riscv64-linux-gnu-cpp 64 s390x-linux-gnu-cpp 64 sh4-linux-gnu-cpp 32 sparc64-linux-gnu-cpp 64 x86_64-linux-gnux32-cpp 64 So I think rather than evaluating the bits here, I think we should enumerate all architectures that currently are time32 and assume that all others (and future ones) will be time64. That list would be: * arm<- I know it's dead. Completeness. * arm64ilp32 * armel * armhf * hppa * i386 <- You want to delete this. * m68k * mips * mips32r6 * mips32r6el * mipsel * mipsn32 * mipsn32el * powerpc * s390 * sh3 * sh4 * sparc Also notably absent from this list is musl-linux-any, which will be time64 everywhere. So I recommend changing that condition from cpu_bits!=32 to a non-member test of this list. I'll be doing a debhelper upload soon to change dh_installsystemd. Helmut
