|
2025-07-04
| ||
| 12:14 | • Ticket [6b0f776c52] gcc 14 breaks configure test for bigendian leading to broken floating point status still Closed with 5 other changes artifact: 157a7d58fd user: jan.nijtmans | |
|
2025-07-03
| ||
| 15:50 | • Ticket [6b0f776c52]: 5 changes artifact: b2dd5c394f user: sebres | |
| 08:08 | • Closed ticket [6b0f776c52]. artifact: ccd1d04fe0 user: jan.nijtmans | |
| 07:45 | Fix [6b0f776c52]: gcc 14 breaks configure test for bigendian leading to broken floating point check-in: 95268bca5e user: jan.nijtmans tags: core-8-6-branch | |
|
2025-07-02
| ||
| 21:16 | • Ticket [6b0f776c52] gcc 14 breaks configure test for bigendian leading to broken floating point status still Open with 3 other changes artifact: 911fe24a6f user: sebres | |
| 18:54 | • Ticket [6b0f776c52]: 3 changes artifact: bd18371fef user: anonymous | |
| 16:17 | • New ticket [6b0f776c52]. artifact: df9bf7c576 user: anonymous | |
| Ticket UUID: | 6b0f776c52f9ae7ae9e079e83d31a8c624b22b90 | |||
| Title: | gcc 14 breaks configure test for bigendian leading to broken floating point | |||
| Type: | Bug | Version: | 8.6.16 | |
| Submitter: | anonymous | Created on: | 2025-07-02 16:17:32 | |
| Subsystem: | 53. Configuration and Build Tools | Assigned To: | jan.nijtmans | |
| Priority: | 5 Medium | Severity: | Severe | |
| Status: | Closed | Last Modified: | 2025-07-04 12:14:46 | |
| Resolution: | Fixed | Closed By: | jan.nijtmans | |
| Closed on: | 2025-07-04 12:14:46 | |||
| Description: |
I was trying to debug why a GCC 14 build of tcl 8.6.16 broke any use of floating point, for example: It turned out, after comparing against an earlier GCC 13 build, that the GCC 14 build was incorrectly being built with The failure to compile conftest is being interpreted as the test itself failing, thus determining that this x86_64 platform is now suddenly big endian, leading to sub-optimal behaviour. I'd recommend throwing GCC 14 in the bin for causing such disgustingly insidious fallout, but you may want to implement a more grown-up solution, such as the one I committed to pkgsrc here Thanks. | |||
| User Comments: |
jan.nijtmans added on 2025-07-04 12:14:46:
> Would not something like this help? What about people who deliberately are doing a autoreconf to force installation of the manpages in /usr/share/man*? That won't work the same any more. It's not worth the effort. sebres added on 2025-07-03 15:50:45: Would not something like this help? jan.nijtmans added on 2025-07-03 08:08:51: > TCT is very conservative here for whatever reason (@Jan, why?!) The reason for this is a change in autoconf-2.60: The following variables have new default values:datadir read-only architecture-independent data [DATAROOTDIR] infodir info documentation [DATAROOTDIR/info] mandir man documentation [DATAROOTDIR/man] The effect of this is that autoconf-2.59 has "mandir = ${prefix}/man", while autoconf-2.60+ has "mandir = ${datarootdir}/man" which resolves to "mandir = ${prefix}/share/man". So, if update the "configure" script, the man-pages will suddenly install in a different directory than before. That's not expected in a patch release, even though it is following the "GNU coding standards". So, we have to live with a manual "configure" patch for a while. Since the support for 8.6 is going to end soon anyway, I can live with that. sebres added on 2025-07-02 21:16:42: Well, it is known obsolescence and basically is a result of standard autoconf macro IIRC, the macro was fixed somewhere in autoconf 2.69 (it'll also check preprocessor directives now instead of naive byte comparison and so better suitable for cross-compile, etc)... Anyway, autoconf 2.71 does the job correct. The only option you have now - is to rebuild | |||