Bug#805836: glibc: __NO_LONG_DOUBLE_MATH needs to be defined on hppa
On 2015-11-22 17:44, John David Anglin wrote: > Source: glibc > Version: 2.19-22 > Severity: normal > Tags: patch > > Dear Maintainer, > > The attached fixes a problem found building the gmt package. See BZ 19270: > https://sourceware.org/bugzilla/show_bug.cgi?id=19270 > > Normally gcc optimizes the isnan macro so the __isnanl call is eliminated. > Thus the problem was hidden for some time. > > As noted in the bug report, __NO_LONG_DOUBLE_MATH needs to be defined on hppa > to ensure consistency with the library build. > > The attached patch has been submitted here: > https://sourceware.org/ml/libc-alpha/2015-11/msg00520.html > > Please add this change to hppa patch set. It is now in 2.19-22+b6. This caused the following regression on the build daemon: https://buildd.debian.org/status/fetch.php?pkg=glibc=hppa=2.21-0experimental4=1448872617 TEST elf/check-abi-libc: --- ../sysdeps/unix/sysv/linux/hppa/libc.abilist2015-02-06 06:40:18.0 + +++ /<>/build-tree/hppa-libc/libc.symlist 2015-11-30 08:36:41.03200 + @@ -276,0 +277 @@ GLIBC_2.2 + __finitel F @@ -307,0 +309 @@ GLIBC_2.2 + __isinfl F @@ -310,0 +313 @@ GLIBC_2.2 + __isnanl F TEST math/check-abi-libm: --- ../sysdeps/unix/sysv/linux/hppa/libm.abilist2015-02-06 06:40:18.0 + +++ /<>/build-tree/hppa-libc/math/libm.symlist 2015-11-30 01:31:31.04400 + @@ -68,0 +69 @@ GLIBC_2.2 + __finitel F In short this patch added, as expected, new symbols and thus the ABI baseline has to be updated. I have just done that on the Debian package, please do the same for the upstream patch. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#805836: glibc: __NO_LONG_DOUBLE_MATH needs to be defined on hppa
Source: glibc Version: 2.19-22 Severity: normal Tags: patch Dear Maintainer, The attached fixes a problem found building the gmt package. See BZ 19270: https://sourceware.org/bugzilla/show_bug.cgi?id=19270 Normally gcc optimizes the isnan macro so the __isnanl call is eliminated. Thus the problem was hidden for some time. As noted in the bug report, __NO_LONG_DOUBLE_MATH needs to be defined on hppa to ensure consistency with the library build. The attached patch has been submitted here: https://sourceware.org/ml/libc-alpha/2015-11/msg00520.html Please add this change to hppa patch set. It is now in 2.19-22+b6. Regards, Dave Anglin -- System Information: Debian Release: stretch/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 3.18.24+ (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Index: glibc-2.19/ports/sysdeps/hppa/fpu/bits/mathdef.h === --- glibc-2.19.orig/ports/sysdeps/hppa/fpu/bits/mathdef.h +++ glibc-2.19/ports/sysdeps/hppa/fpu/bits/mathdef.h @@ -34,6 +34,10 @@ typedef double double_t; /* `double' exp #endif /* ISO C99 */ -/* On hppa `long double' is 64-bits. */ -#undef __NO_LONG_DOUBLE_MATH - +#ifndef __NO_LONG_DOUBLE_MATH +/* On hppa `long double' and `double' are 64-bits. So, libm is built + with NO_LONG_DOUBLE defined. The following define ensures the library + and headers are consistent. This disables the declaration of all the + `long double' function variants. */ +# define __NO_LONG_DOUBLE_MATH 1 +#endif
