Bug#1035615: xz-utils: Fix hurd-amd64 build
Package: xz-utils Version: 5.4.1-0.2 Severity: important Tags: patch Hello, debian/rules is passing --enable-assembler=x86_64 to configure, but that case was removed, see ChangeLog: commit ac10b1b3622e70881595586edfb8a3ebdcd76bb6 Author: Lasse Collin Date: 2022-11-14 17:58:07 +0200 Build: Omit x86_64 from --enable-assembler. It didn't do anything. There are only 32-bit x86 assembly files and it feels likely that new files won't be added as intrinsics in C are more portable across toolchains and OSes. The attached patch fixes that by dropping that option, since it's not useful for amd64 ports anyway. Samuel -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.2.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xz-utils depends on: ii libc6 2.36-9 ii liblzma5 5.4.1-0.2 xz-utils recommends no packages. xz-utils suggests no packages. -- no debconf information -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. --- debian/rules.original 2023-05-05 20:24:10.897225010 +0200 +++ debian/rules2023-05-05 20:24:12.997235137 +0200 @@ -91,10 +91,6 @@ opt_optimize += --enable-assembler=x86 opt_optimize_small += --enable-assembler=x86 endif -ifeq (amd64,$(cputype)) -opt_optimize += --enable-assembler=x86_64 -opt_optimize_small += --enable-assembler=x86_64 -endif endif ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
Bug#1035615: xz-utils: Fix hurd-amd64 build
Jeffrey Walton, le sam. 06 mai 2023 13:01:06 -0400, a ecrit: > On Sat, May 6, 2023 at 10:41 AM Samuel Thibault wrote: > > debian/rules is passing --enable-assembler=x86_64 to configure, but that > > case was removed, see ChangeLog: > > > > commit ac10b1b3622e70881595586edfb8a3ebdcd76bb6 > > Author: Lasse Collin > > Date: 2022-11-14 17:58:07 +0200 > > > > Build: Omit x86_64 from --enable-assembler. > > > > It didn't do anything. There are only 32-bit x86 assembly files > > and it feels likely that new files won't be added as intrinsics > > in C are more portable across toolchains and OSes. > > > > The attached patch fixes that by dropping that option, since it's not > > useful for amd64 ports anyway. > > I think it is a bad idea to rely solely on intrinsics. Well, that's to be discussed with upstream, not here. Samuel
Bug#1035615: xz-utils: Fix hurd-amd64 build
On Sat, May 6, 2023 at 10:41 AM Samuel Thibault wrote: > > Package: xz-utils > Version: 5.4.1-0.2 > Severity: important > Tags: patch > > debian/rules is passing --enable-assembler=x86_64 to configure, but that > case was removed, see ChangeLog: > > commit ac10b1b3622e70881595586edfb8a3ebdcd76bb6 > Author: Lasse Collin > Date: 2022-11-14 17:58:07 +0200 > > Build: Omit x86_64 from --enable-assembler. > > It didn't do anything. There are only 32-bit x86 assembly files > and it feels likely that new files won't be added as intrinsics > in C are more portable across toolchains and OSes. > > The attached patch fixes that by dropping that option, since it's not > useful for amd64 ports anyway. I think it is a bad idea to rely solely on intrinsics. Intrinsics have their own problems. For example, suppose you have a function that is implemented in C, SSE4 and AVX. Your project would be setup with: * my_func.c compiled with base ISA options * my_func_sse4.c compiled with -march=sse_41 * my_func_avx.c compiled with -march=avx * a function pointer to select a C, SSE4 or AVX implementation * an initializer that sets the function pointer at startup. If you run on a SSE4 machine (or below), then you could segfault in my_func_avx translation unit _if_ the compiler uses AVX instructions in the TU. I've had the exact situation happen to me with both GCC and Clang. My code was guarded behind a feature test, but the GCC and Clang code was not guarded. The unguarded compiler code caused a SIGILL. I had it happen to me with both GCC and Clang on PowerPC, i686, and x86_64. See, for example, https://lists.llvm.org/pipermail/llvm-dev/2018-December/128159.html . The fix is to have the compiler _stop_ hijacking my ISA. We are forced to use an option like -march=avx. That does not mean the compiler should assume it can use it. But the GCC and Clang compilers got it wrong. Microsoft compilers got it right. You can use any intrinsic the compiler supports without an option. If you supply an option, like /arch:avx, then Microsoft compilers take that as a signal they can generate code for AVX. Otherwise, Microsoft compilers just use the base ISA. So be careful about using those intrinsics. > -- System Information: > Debian Release: 12.0 > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, > 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, > 'proposed-updates-debug'), (500, 'proposed-updates'), (500, > 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, > 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), > (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386, arm64 > > Kernel: Linux 6.2.0 (SMP w/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages xz-utils depends on: > ii libc6 2.36-9 > ii liblzma5 5.4.1-0.2 > > xz-utils recommends no packages. > > xz-utils suggests no packages. > > -- no debconf information
Bug#1035615: xz-utils: Fix hurd-amd64 build
On 2023-05-06 15:49:33 [+0200], Samuel Thibault wrote: > debian/rules is passing --enable-assembler=x86_64 to configure, but that > case was removed, see ChangeLog: > > commit ac10b1b3622e70881595586edfb8a3ebdcd76bb6 > Author: Lasse Collin > Date: 2022-11-14 17:58:07 +0200 > > Build: Omit x86_64 from --enable-assembler. > > It didn't do anything. There are only 32-bit x86 assembly files > and it feels likely that new files won't be added as intrinsics > in C are more portable across toolchains and OSes. > > The attached patch fixes that by dropping that option, since it's not > useful for amd64 ports anyway. So this is a simple clean up right? No function change? At least this is what it looks like based on your description and options I've been looking at. I'm a little confused with "Fix hurd-amd64 build" since it should be a nop there, right? > Samuel Sebastian
Bug#1035615: xz-utils: Fix hurd-amd64 build
Sebastian Andrzej Siewior, le mar. 09 mai 2023 22:17:21 +0200, a ecrit: > On 2023-05-06 15:49:33 [+0200], Samuel Thibault wrote: > > debian/rules is passing --enable-assembler=x86_64 to configure, but that > > case was removed, see ChangeLog: > > > > commit ac10b1b3622e70881595586edfb8a3ebdcd76bb6 > > Author: Lasse Collin > > Date: 2022-11-14 17:58:07 +0200 > > > > Build: Omit x86_64 from --enable-assembler. > > > > It didn't do anything. There are only 32-bit x86 assembly files > > and it feels likely that new files won't be added as intrinsics > > in C are more portable across toolchains and OSes. > > > > The attached patch fixes that by dropping that option, since it's not > > useful for amd64 ports anyway. > > So this is a simple clean up right? No function change? At least this is > what it looks like based on your description and options I've been > looking at. I'm a little confused with "Fix hurd-amd64 build" since it > should be a nop there, right? My patch is not a nop. Previously to Lasse's commit, the --enable-assembler=x86_64 option would make no difference from --enable-assembler=no. With Lasse's commit, --enable-assembler=x86_64 is now *refused* by ./configure. And thus amd64 builds break... But only on hurd, because that's only where debian/rules passes an --enable-assembler option at all. Samuel
Bug#1035615: xz-utils: Fix hurd-amd64 build
On 2023-05-09 22:58:43 [+0200], Samuel Thibault wrote: > My patch is not a nop. Previously to Lasse's commit, the > --enable-assembler=x86_64 option would make no difference from > --enable-assembler=no. With Lasse's commit, --enable-assembler=x86_64 > is now *refused* by ./configure. And thus amd64 builds break... But > only on hurd, because that's only where debian/rules passes an > --enable-assembler option at all. It also passes it on amd64 but this gets filtered out due to linux as the host os. Eitherway, I'm going to stash for an upload post release. > Samuel Sebastian
