[sr #110398] autoconf 2.70 breaks coreutils-8.32

[Bruce Dubbs]

Follow-up Comment #4, sr #110398 (project autoconf):

[comment #3 comment #3:]
> [comment #2 comment #2:]
> 
> > The problem of course is that every package that uses gnulib has to
update.
> 
> That's why we have a Gnulib. :-)
> 
> More precisely, if you want to use the latest Autoconf you should also use
the latest Gnulib. If you don't need to use the latest Autoconf, older Gnulib
will do.

I am not the maintainer.  At linuxfromscratch we show users how to build about
1000 open source packages, but we rely on the upstream source code.  Most of
the time upstream releases the package so that autoconf or autoreconf is not
needed by us, but sometimes we do need them. For those cases where it is
needed,  having different packages use different versions of gnulib makes
things difficult.

I will note that mozilla packages (firefox, seamonkey, thunderbird) still
require autoconf-2.13.  

There is not a lot autoconf developers can do about that, but it certainly
would be easier if gnulib could be installed system wide.

I do have a workaround for coreutils, so you can close this ticket.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110399] turning off preference for newest supported C?

[Paul Eggert]

Follow-up Comment #2, sr #110399 (project autoconf):

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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110399] turning off preference for newest supported C?

[Zack Weinberg]

Update of sr #110399 (project autoconf):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up 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.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110399] turning off preference for newest supported C?

[Karl Berry]

URL:
  

 Summary: turning off preference for newest supported C?
 Project: Autoconf
Submitted by: karl
Submitted on: Wed 09 Dec 2020 02:58:19 PM PST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

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





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110398] autoconf 2.70 breaks coreutils-8.32

[Bruce Dubbs]

Follow-up Comment #2, sr #110398 (project autoconf):

[comment #1 comment #1:]
> This should be a gnulib bug fixed in
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=a3b3fc85e3e632374811b27cb2111e50fa177e36

Yes, this fixes coreutils.  The problem of course is that every package that
uses gnulib has to update.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110398] autoconf 2.70 breaks coreutils-8.32

[anonymous]

Follow-up Comment #1, sr #110398 (project autoconf):

This should be a gnulib bug fixed in
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=a3b3fc85e3e632374811b27cb2111e50fa177e36

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110398] autoconf 2.70 breaks coreutils-8.32

[Bruce Dubbs]

URL:
  

 Summary: autoconf 2.70 breaks coreutils-8.32
 Project: Autoconf
Submitted by: bdubbs
Submitted on: Wed 09 Dec 2020 11:46:05 AM CST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

Running 'autoreconf -fiv' on coreutils creates a configure script that fails:

/configure: line 6425: syntax error near unexpected token
`ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89'
./configure: line 6425: `ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89'

I could not find any reference to this in configure.ac, but the offending part
of configure is:

for ac_arg in '' ac_prog_cc_stdc=c89
 ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89
do
  CC="$ac_save_CC $ac_arg"
  if ac_fn_c_try_compile "$LINENO"
then :
  ac_cv_prog_cc_c89=$ac_arg
fi
rm -f core conftest.err conftest.$ac_objext conftest.beam
  test "x$ac_cv_prog_cc_c89" != "xno" && break
done
---
I can fix this manually by changing to:

ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89
for ac_arg in '' ac_cv_prog_cc_stdc
do
...

but that is not a good solution.

More info is available upon request.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/