mainAutoconf - Support: sr #110399, turning off preference for newest...

 
 

sr #110399: turning off preference for newest supported C?

Submitter:  Karl Berry <karl>
Submitted:  Wed 09 Dec 2020 10:58:19 PM UTC
   
 
Priority:  * 5 - Unprioritized Severity:  3 - Normal
Status:  Duplicate Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 12 Dec 2020 02:22:04 AM UTC, comment #5: 


> the Gnulib stdint module assumed that AC_INCLUDES_DEFAULT was being called
> and that it set ac_cv_header_inttypes_h and ac_cv_header_sys_types_h.
> This assumption is no longer true in Autoconf 2.70


AC_INCLUDES_DEFAULT (when called without arguments) does still do AC_CHECK_HEADERS_ONCE for both sys/types.h and inttypes.h.  See https://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/autoconf/headers.m4#n324 .  I don't know what changed exactly, but I'd guess AC_INCLUDES_DEFAULT somehow isn't getting called in the first place.

Zack Weinberg <zackw>
Group administrator
Sat 12 Dec 2020 02:11:32 AM UTC, comment #4: 

For what it's worth, I ran into a similar problem on Fedora 33 with Gnulib, and found that it occurred because the Gnulib stdint module assumed that AC_INCLUDES_DEFAULT was being called and that it set ac_cv_header_inttypes_h and ac_cv_header_sys_types_h. This assumption is no longer true in Autoconf 2.70 (not sure whether that was intended). I fixed the problem by calling AC_CHECK_HEADERS_ONCE([inttypes.h]) before using ac_cv_header_inttypes_h, and by calling AC_CHECK_HEADERS_ONCE([sys/types.h]) before using ac_cv_header_sys_types_h; see:

https://lists.gnu.org/r/bug-gnulib/2020-12/msg00118.html

I notice at least one similar issue in texlive, namely texk/dvipng/dvipng-src/configure.ac uses ac_cv_header_inttypes_h without invoking AC_CHECK_HEADERS([inttypes.h]). There may be other occurrences of the problem.

I can't easily test the obvious fix for texk/dvipng/dvipng-src/configure.ac, as texlive doesn't build for me on Fedora 33 (with the old Autoconf, not that this matters when building without changing configure.ac etc.); the build fails as follows:


checking for FT_Init_FreeType... no
configure: error: libfreetype2 not found
=== configuring in gd failed
make[2]: *** [Makefile:918: recurse] Error 1
make[2]: Leaving directory '/home/eggert/src/tug/source/Work/libs'
make[1]: *** [Makefile:488: all-recursive] Error 1
make[1]: Leaving directory '/home/eggert/src/tug/source/Work/libs'
make: *** [Makefile:582: all-recursive] Error 1


Paul Eggert <eggert>
Group administrator
Thu 10 Dec 2020 10:55:00 PM UTC, comment #3: 

When a longstanding core existing feature (AC_PROG_CC) is changed in a backward-incompatible way, a way to get the heretofore standard behavior feels more like a bug fix than a feature request to me. For that matter, it feels like a new macro or option would have been more desirable than incompatibly changing existing behavior.

Anyway. Semantics aside, I had the same reaction to the weird error about "long int". I haven't had a chance to look into it yet, but my expectation is that it is something specific to the TL autoconfigury. (I mean, presumably int64_t should not be getting #define-d in the first place.) I've been using Autoconf for TeX since Autoconf first existed, and never had to change most of it. So I won't be surprised that something is going awry now.

If something is actually going wrong on the Autoconf side, I'll post a separate report.



Karl Berry <karl>
Group Member
Wed 09 Dec 2020 11:30:20 PM UTC, comment #2: 

Although this is a feature request, isn't there a bug report buried in it too? Karl reports:


./c-auto.h:164:22: error: two or more data types in declaration specifiers
#define int64_t long int


and ascribes this to 'gcc -std=gnu11'. However, 'long int foo;' is a perfectly valid declaration in C11, just as it was in C99, and compiling with -std=gnu11 shouldn't affect whether such a declaration is accepted. So there must be something else going on here.

Paul Eggert <eggert>
Group administrator
Wed 09 Dec 2020 11:06:27 PM UTC, comment #1: 

The PostgreSQL developers also requested this feature, see bug #110286. I'm going to close this as a duplicate and add you to the cc list over there.

I had hoped to get this feature implemented for 2.70 but ran out of time. I have to concentrate on my day job between now and mid-January, but I will try to get it done as soon as possible after that. TeX Live may be best served sticking to 2.69 for now.

Zack Weinberg <zackw>
Group administrator
Wed 09 Dec 2020 10:58:19 PM UTC, original submission:  

In autoconf 2.70 (and not 2.69e, I believe), the basic C
compiler check "prefers" the newest supported standard. That
is, autoconf.texi now says:

> If necessary, options are added to @code{CC} to enable support
> for ISO Standard C features with extensions, preferring the
> newest C standard that is supported.


Is it possible to turn off these extra checks and just get
the "classic" behavior of looking for a working C compiler,
not adding these extra flags to support the newest-possible
standard? I looked in the manual and the code but nothing
jumped out at me. Advice appreciated.

Because different standards versions introduce
incompatibilities, the result of "forcing" the latest
standard is painful failures. The TeX Live build, which
succeeded (modulo the "obsolete warning" agony) all through
the pretests, now fails with:

./c-auto.h:164:22: error: two or more data types in declaration specifiers
 #define int64_t long int
                      ^
./c-auto.h:171:18: error: duplicate 'unsigned'
 #define uint64_t unsigned long int
                  ^
./c-auto.h:171:32: error: two or more data types in declaration specifiers
 #define uint64_t unsigned long int


I believe this is because the compiler is now "gcc
-std=gnu11" and not just "gcc". (The autoconfigured types
would be different.)

No doubt our code needs to be (painfully) changed to placate
the standards eventually, but it doesn't seem like Autoconf's place to force this unconditionally.

Thanks,
Karl

Karl Berry <karl>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by eggert (Posted a comment)
  • -email is unavailable- added by zackw (Posted a comment)
  • -email is unavailable- added by karl (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-09 zackw StatusNone Duplicate
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code