Tcl Source Code

View Ticket
Login
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 Leaf 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:

$ tclsh
% expr rand()
wrong digit!
Abort (core dumped)

It turned out, after comparing against an earlier GCC 13 build, that the GCC 14 build was incorrectly being built with -DWORDS_BIGENDIAN=1, and this is because the configure test for endianness is now broken:

-conftest.c:54:3: warning: implicit declaration of function 'exit' [-Wimplicit-function-declaration]
+conftest.c:54:3: error: implicit declaration of function 'exit' [-Wimplicit-function-declaration]
    54 |   exit (u.c[sizeof (long) - 1] == 1);
       |   ^~~~

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?

mandir=${prefix}/man
AC_SUBST(mandir)


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 AC_C_BIGENDIAN, which is in case of 8.6 a bit outdated, because unix/configure is built with autoconf 2.59 and TCT is very conservative here for whatever reason (@Jan, why?!).

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 configure by yourself, e. g. invoke autoreconf -f in unix directory before starting configure. I'd always recommend it as long as the autoconf/automake is installed and still compatible with obsolete macros like AC_HEADER_TIME.