[sr #111072] "[[]] attributes are a C23 extension warning" with clang

[anonymous]

URL:
  <https://savannah.gnu.org/support/?111072>

 Summary: "[[]] attributes are a C23 extension warning" with
clang
   Group: Autoconf
   Submitter: None
   Submitted: Fri 07 Jun 2024 11:49:01 PM UTC
Priority: 5 - Unprioritized
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: p...@lucasmail.org
 Open/Closed: Open
 Discussion Lock: Any
Operating System: *BSD


___

Follow-up Comments:


---
Date: Fri 07 Jun 2024 11:49:01 PM UTC By: Anonymous
Hello —

Recently, I started getting warnings like:


./slist.h:170:1: warning: [[]] attributes are a C23 extension
[-Wc23-extensions]
  170 | NODISCARD
  | ^
../lib/attribute.h:143:19: note: expanded from macro 'NODISCARD'
  143 | #define NODISCARD _GL_ATTRIBUTE_NODISCARD
  |   ^
./config.h:1392:37: note: expanded from macro '_GL_ATTRIBUTE_NODISCARD'
 1392 | #define _GL_ATTRIBUTE_NODISCARD [[__nodiscard__]]
  | ^


Specifically, the value defined for NODISCARD defined in config.h as generated
by configure as generated by autoconf causes the warning.

The relevant section from config.h is:


#ifndef _GL_ATTRIBUTE_NODISCARD
# ifndef _GL_BRACKET_BEFORE_ATTRIBUTE
#  if defined __clang__ && defined __cplusplus
  /* With clang up to 15.0.6 (at least), in C++ mode, [[__nodiscard__]]
produces
 a warning.
 The 1000 below means a yet unknown threshold.  When clang++ version X
 starts supporting [[__nodiscard__]] without warning about it, you can
 replace the 1000 with X.  */
#   if __clang_major__ >= 1000
#define _GL_ATTRIBUTE_NODISCARD [[__nodiscard__]]
#   endif
#  elif _GL_HAVE___HAS_C_ATTRIBUTE
#   if __has_c_attribute (__nodiscard__)
#define _GL_ATTRIBUTE_NODISCARD [[__nodiscard__]]
#   endif
#  endif
# endif
# if !defined _GL_ATTRIBUTE_NODISCARD && _GL_HAS_ATTRIBUTE
(warn_unused_result)
#  define _GL_ATTRIBUTE_NODISCARD __attribute__ ((__warn_unused_result__))
# endif
# ifndef _GL_ATTRIBUTE_NODISCARD
#  define _GL_ATTRIBUTE_NODISCARD
# endif
#endif


I think the problem is this line:


#  if defined __clang__ && defined __cplusplus


My project is a C project, not C++, so __cplusplus is not defined so that #if
fails which means this part happens:


#  elif _GL_HAVE___HAS_C_ATTRIBUTE
#   if __has_c_attribute (__nodiscard__)
#define _GL_ATTRIBUTE_NODISCARD [[__nodiscard__]]
#   endif


In this block, no check for __clang_major__ is done, so it always defines
_GL_ATTRIBUTE_NODISCARD to [[__nodiscard__]] and clang warns.

I don't think the && __cplusplus should be there at all. Attributes using [[
are supported in C23 or later or C++11 or later. Why not use
__STDC_VERSION__?

FYI:


$ clang --version
FreeBSD clang version 18.1.5 (https://github.com/llvm/llvm-project.git
llvmorg-18.1.5-0-g617a15a9eac9)
Target: x86_64-unknown-freebsd14.1
Thread model: posix
InstalledDir: /usr/bin

$ autoconf --version
autoconf (GNU Autoconf) 2.72
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>,
<https://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.


— Paul








___

Reply to this item at:

  <https://savannah.gnu.org/support/?111072>

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

[sr #110983] AC_SYS_LARGEFILE doesn't honor AC_LANG setting

[anonymous]

Follow-up Comment #7, sr #110983 (group autoconf):

This patch also works for me, thanks.

Jakub Bogusz


___

Reply to this item at:

  

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

[sr #110983] AC_SYS_LARGEFILE doesn't honor AC_LANG setting

[anonymous]

Follow-up Comment #5, sr #110983 (group autoconf):

Hi,

The attached patch seems to fix AC_SYS_LARGEFILE and co. with C++ for me (and
test suite passes on i686).

Jakub Bogusz 

(file #55940)

___

Additional Item Attachment:

File name: autoconf-largefile.patch   Size: 1KiB
   



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-4448d8da181e3133acac16b178e98513aa6405cd.tar.gz


___

Reply to this item at:

  

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

[sr #111048] Add a syntax check to code snippets

[anonymous]

URL:
  <https://savannah.gnu.org/support/?111048>

 Summary: Add a syntax check to code snippets
   Group: Autoconf
   Submitter: None
   Submitted: Fri 05 Apr 2024 07:44:13 AM UTC
Priority: 5 - Unprioritized
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: fbau...@amadeus.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux


___

Follow-up Comments:


---
Date: Fri 05 Apr 2024 07:44:13 AM UTC By: Anonymous
Hello,

As you may know, an attack related to XZ Utils (lzma) has been
discovered:

https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

The malicious account has disabled a feature by sneakily forging an
always-failing code.  This has been done by introducing a syntax error
in a CMake file (a dot at the beginning of a line):

https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7

So the CMake project is considering adding a preliminary syntax check
(with a verbose error message) in addition to the full check (which
fails rather silently), so that such disabling does not go unnoticed:

https://gitlab.kitware.com/cmake/cmake/-/issues/25846

This makes me think that Autoconf does compilation checks similar to
that of CMake, and therefore an attacker could similarly, sneakily
disable a feature.

Should Autoconf similarly add a syntax check?  I'm leaving this open
question to the community.

Thanks!

Best regards
Fabrice








___

Reply to this item at:

  <https://savannah.gnu.org/support/?111048>

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

[sr #111044] autoconf should assert existence of all subsidiary tools at startup

[anonymous]

Follow-up Comment #1, sr #111044 (group autoconf):

To elaborate on that, people may use the output of such tools to enable or
disable certain compiler features. An example of such a case was found when
building OpenVPN [0].

This was also reported in 2008 [1].

[0] https://twitter.com/disconnect3d_pl/status/1774747022362325263 (probably
change twitter to nitter to get access without logging in)

[1] https://lists.gnu.org/archive/html/bug-autoconf/2008-03/msg00033.html


___

Reply to this item at:

  

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

[sr #111044] autoconf should assert existence of all subsidiary tools at startup

[anonymous]

URL:
  <https://savannah.gnu.org/support/?111044>

 Summary: autoconf should assert existence of all subsidiary
tools at startup
   Group: Autoconf
   Submitter: None
   Submitted: Mon 01 Apr 2024 03:10:23 PM UTC
Priority: 5 - Unprioritized
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: f...@redhat.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None


___

Follow-up Comments:


---
Date: Mon 01 Apr 2024 03:10:23 PM UTC By: Anonymous
The script generated by autoconf may run in environments even sparser than the
gnu standards.  One recentish example is missing "diff", which results in
confusing diagnostics but not an outright failure.

It'd be helpful - and possibly improve security overall - if autoconf's
generated shell script were to enumerate and assert the existence of every
/usr/bin type basic utility its code relies on, and if absent, abort abort
abort.  Better that than partial or obscured failures leading to oddly
configured target programs.







___

Reply to this item at:

  <https://savannah.gnu.org/support/?111044>

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

[sr #111016] Configure script fails to detect sctp on Alpine linux

[anonymous]

Follow-up Comment #3, sr#111016 (group autoconf):

Yes, this is not an autoconf problem. If I could close/delete 111016 I would.


___

Reply to this item at:

  

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

[sr #111016] Configure script fails to detect sctp on Alpine linux

[anonymous]

Follow-up Comment #1, sr#111016 (group autoconf):

I found config.log file, with explanation why Alpine linux fail.
The include linux/types.h is not present.



___

Reply to this item at:

  

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

[sr #111016] Configure script fails to detect sctp on Alpine linux

[anonymous]

URL:
  <https://savannah.gnu.org/support/?111016>

 Summary: Configure script fails to detect sctp on Alpine
linux
   Group: Autoconf
   Submitter: None
   Submitted: Mon 05 Feb 2024 10:53:36 AM UTC
Priority: 5 - Unprioritized
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: bengt.kleb...@travelping.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux


___

Follow-up Comments:


---
Date: Mon 05 Feb 2024 10:53:36 AM UTC By: Anonymous
Greetings,

The configure.ac file below, produces a configure script that fail to detect
sctp on Alpine linux (Linux localhost 6.1.75-0-virt).
The same configure script will correctly detect sctp on Arch linux (Linux
alarm 6.2.10-1-aarch64-ARCH).
I used autoconf from their package manager (2.71 and 2.72 respectively), but
the two resulting configure scripts, despite differences, produces the same
results on both machines. Always fail on Alpine, always correct on Arch
linux.

Best Wishes,
bengt

configure.ac:
AC_INIT
AC_CHECK_HEADER(netinet/sctp.h,
[LIBSCTP=libsctp.so.1
 AC_DEFINE(HAVE_SCTP_H, [1],
[Define to 1 if you have the  header file])],
[],
[#if HAVE_SYS_SOCKET_H
 #include 
 #endif
])
AC_OUTPUT








___

Reply to this item at:

  <https://savannah.gnu.org/support/?111016>

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

[sr #111014] autoheader doesn't work with AC_DEFINE_UNQUOTED

[anonymous]

URL:
  <https://savannah.gnu.org/support/?111014>

 Summary: autoheader doesn't work with AC_DEFINE_UNQUOTED
   Group: Autoconf
   Submitter: None
   Submitted: Wed 31 Jan 2024 02:47:58 AM UTC
Priority: 5 - Unprioritized
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: h...@openldap.org
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None


___

Follow-up Comments:


---
Date: Wed 31 Jan 2024 02:47:58 AM UTC By: Anonymous
If you use AC_DEFINE_UNQUOTED to define symbols whose names are expanded from
variables, autoheader won't emit them to the template header file. Later when
you run configure, these symbols won't get defined because the matching
define/undef line that is looked for during substitution doesn't exist.








___

Reply to this item at:

  <https://savannah.gnu.org/support/?111014>

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

[sr #110990] AS_IF / AC_CHECK_LIB generates invalid shell on editline-1.17.1

[anonymous]

Follow-up Comment #1, sr#110990 (group autoconf):

Does quoting the 2nd argument help?


___

Reply to this item at:

  

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

[sr #110746] GNU Autoconf 2.71: F77 name-mangling fails when compiling with mpicxx

[anonymous]

Follow-up Comment #2, sr#110746 (group autoconf):

I tested configuring and compiling the library in the setup mentioned in my
original submission with autoconf 2.72d and it worked fine!
However, I was unable to recreate my problem using autoconf 2.71., so I am not
entirely sure I recreated the problem setup properly.


___

Reply to this item at:

  

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

[sr #110448] AC_CONFIG_AUX_DIRS fails with Windows paths

[anonymous]

Follow-up Comment #2, sr#110448 (group autoconf):

Cabal now sets `$PATH_SEPARATOR=";"` so we don't have the issue anymore with
newer releases:
- https://github.com/haskell/cabal/issues/7494
- https://github.com/haskell/cabal/pull/7510

This issue can be closed.


___

Reply to this item at:

  

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

[sr #110435] autoreconf: recognize when AM_ICONV is used without the rest of gettext

[anonymous]

Follow-up Comment #7, sr#110435 (group autoconf):

Yes, I have wrote in the first comment that the custom script which copies
config.rpath to current directory and then run autoreconf is a workaround.

I'm looking at autotools now again and seems that config.rpath is copied by
autopoint to current dir. But autopoint is called only when configure.ac uses
AM_GNU_GETTEXT_VERSION macro. But usage of AM_GNU_GETTEXT_VERSION in
configure.ac cause that autoreconf (or its subprocess) installs gettext stuff
which are not required for non-gettext projects.

So I think that solution for this problem can be:
Use current autoreconf detection if calling autopoint is needed and call it.
If autopoint was not called and configure.ac use AM_ICONV macro then copy
config.rpath to current directory.


___

Reply to this item at:

  

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

[sr #110435] autoreconf does not recognize AM_ICONV

[anonymous]

Follow-up Comment #4, sr#110435 (group autoconf):

Here is simple autogen.sh script which can be used to avoid this AM_ICONV
autoreconf bug:

#!/bin/sh

# Install config.rpath which is needed for AM_ICONV macro
for dir in "$GETTEXT_DIR" /usr/share/gettext /usr/local/share/gettext; do
  if test -f "$dir/config.rpath"; then
test -f config.rpath || echo "autogen.sh: installing './config.rpath'"
cp -f "$dir/config.rpath" .
break
  fi
done

autoreconf --install --force --verbose




___

Reply to this item at:

  

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

[sr #110961] 3 Vulnerabilities Result in Code Execution upon running `autoconf` with crafted `configure.ac` file

[anonymous]

URL:
  <https://savannah.gnu.org/support/?110961>

 Summary: 3 Vulnerabilities Result in Code Execution upon
running `autoconf` with crafted `configure.ac` file
   Group: Autoconf
   Submitter: None
   Submitted: Sun 26 Nov 2023 05:16:39 AM UTC
Category: None
Priority: 5 - Normal
Severity: 6 - Security
  Status: None
 Privacy: Private
 Assigned to: None
Originator Email: allypet...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux


___

Follow-up Comments:


---
Date: Sun 26 Nov 2023 05:16:39 AM UTC By: Anonymous
= Overview =

Arbitrary Code execution can be obtained up running `/usr/bin/autoconf` when a
crafted `configure.ac` exploits any of the following 3 vulnerabilities:

*  Command injection in M4sugar due to lack of input sanitization (CWE-78).
*  `cat` command being executed without absolute path in M4sugar, leaving it
vulnerable to an untrusted PATH (CWE-427).
* Invocation of arbitrary m4 macros in `configure.ac`.


*Date*: 11/25/2023
*Researcher*: Ally Petitt
*Product Tested*: Autoconf v2.71 (it is highly likely this still exists in
more recent releases)
*Impact*: Remote code execution that leads to the loss of availability,
confidentiality, and integrity of the system. In certain cases it can also
lead to privilege escalation.

= Technical Details =

== M4sugar - Multiple Vulnerabilities ==
The `m4_file_append` macro is defined starting on line 3272 of
`lib/m4sugar/m4sugar.m4`. 


m4_define([m4_file_append],
[m4_syscmd([cat >>$1 <<_m4eof
$2
_m4eof
])


This macro has 2 vulnerabilities. Proof-of-Concept examples of each will be
shown in the "PoC" section to provide both clarification and an easy way to
validate the issues.

1. The first vulnerability is that `cat` is called without an absolute path,
leaving it prone to modification of the $PATH environmental variable. A
privileged user on the system may set the $PATH to point to a directory they
control containing a malicious executable called `cat`. In scenarios where
`autoconf` has an SUID bit set or can otherwise be run with elevated
privileges, this can lead to privilege escalation.

*Mitigation*: Replace "cat" with "/usr/bin/cat" in the definition of
`m4_file_append`.

2. The arguments passed to `m4_file_append` are not sanitized before being
passed into `m4_syscmd`. This means that hackers can directly insert malicious
code as an argument to the macro and it will be executed when `autoconf` is
ran!

*Mitigation*: If possible, implement a more secure way to append to a file
that does not involve running shell commands. I wish I could provide more
guidance here but I am not very proficient in m4. In the case that this is not
feasible, treat `$1` and `$2` as untrusted input and sanitize them. 


== Autoconf - Invocation of Arbitrary M4 Macros == 
Autoconf appears to execute m4 macros directly through the `configure.ac`
file. Without any sanitization, adversaries are able invoke arbitrary macros
including `syscmd` and the aforementioned vulnerable `m4_file_append`. This
can lead to the execution of code upon running `autoconf`. An example will be
shown in the "PoC" section below.

It is worth noting that while executing macros is part of Autoconf's
functionality, I did not find evidence that the arbitrary execution of
commands was an intentional part of this design. As such, the lack of
restriction on the macros that can be called results in a larger attack
surface that can be taken advantage of by hackers.

*Mitigation*: Enforce a whitelist of macros that are able to be executed from
`configure.ac`.


= PoC =

This Proof-of-Concept involves the creation of 4 files within the same
directory. The contents of these files are the following (file names are
commented at the top of each code block):


# congfigure.ac
AC_INIT([hello], [1.0])
AC_CONFIG_SRCDIR([hello.c])
AC_CONFIG_AUX_DIR([build-aux])
AC_PROG_CC

# Trigger the vulnerabilities by writing to a file called `vulns`
syscmd(echo vuln1 > vulns) # vuln1
m4_file_append(test, `echo vuln2 >> vulns`) # vuln2 and vuln3


AC_CONFIG_FILES([Makefile])
AC_OUTPUT



# Makefile.am
bin_PROGRAMS = hello
hello_SOURCES = hello.c



# hello.c
#include 
int main(int argc, char** argv) {
  printf("hello world!\n");
  return 0;
}



# cat
#!/bin/bash
echo vuln3 >> vulns


The resulting directory listing should be the following:


$ ls
cat  configure.ac  hello.c  Makefile.am


Once the files are verified to be correct, the 3 vulnerabilities can be
exploited by running the command below.

$ export PATH=$(pwd):$PATH && autoconf


A new file will be created called `vulns`. Each vulnerability that was
exploited

[sr #110927] 30 tests fail building on macOS Venture 13.5.1 with Xcode 14.3.1

[anonymous]

URL:
  <https://savannah.gnu.org/support/?110927>

 Summary: 30 tests fail building on macOS Venture 13.5.1 with
Xcode 14.3.1
   Group: Autoconf
   Submitter: None
   Submitted: Thu 24 Aug 2023 06:27:58 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: johns...@usc.edu
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Mac OS


___

Follow-up Comments:


---
Date: Thu 24 Aug 2023 06:27:58 PM UTC By: Anonymous
The following 26 tests fail in building on (clean install of) macOS Venture
13.5.1 with Xcode 14.3.1: 010 011 012 014 037 092 236 238 239 240 293 299 397
430 431 432 433 434 435 436 437 438 439 440 509 514

See attached testsuite.log file.






___
File Attachments:


---
Date: Thu 24 Aug 2023 06:27:58 PM UTC  Name: testsuite.log  Size: 172KiB   By:
None

<http://savannah.gnu.org/support/download.php?file_id=55073>

___

Reply to this item at:

  <https://savannah.gnu.org/support/?110927>

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

[sr #110872] m4_warn differs in various ways from its documentation

[anonymous]

URL:
  <https://savannah.gnu.org/support/?110872>

 Summary: m4_warn differs in various ways from its
documentation
   Group: Autoconf
   Submitter: None
   Submitted: Sat 22 Apr 2023 11:01:15 AM UTC
Category: None
Priority: 5 - Normal
Severity: 2 - Minor
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux


___

Follow-up Comments:


---
Date: Sat 22 Apr 2023 11:01:15 AM UTC By: Anonymous
OS: Linux user-ThinkPad-X200 5.15.0-70-generic #77+11.0trisquel19 SMP Tue Apr
18 13:57:27 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Automake version: autoreconf (GNU Autoconf) 2.71

Test procedure: run autogen.sh (attached), possibly with 'dnl' comments
removed.

Expected result: I would expect to be able to uncomment all of the m4_warn
lines, and receive four warnings and no fatal errors

Actual result:  I receive one warning.  If I uncomment either of the 'dnl 
m4_warn' lines, I receive an ugly fatal error in autom4te.

Context: I was looking for the category in which to report that the
PKG_CHECK_MODULES macro is not defined in the default configuration of my
platform.  [[ I have worked out that I need to install pkg-config, thank you.
]]

Partners in guilt:

This page:
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Diagnostic-Macros.html#Diagnostic-Macros
- implicitly claims that using non-standard categories is possible
- claims that [] and [all] are categories
- does not refer me to the page below

This page:
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/autom4te-Invocation.html#autom4te-Invocation
-  reports that not all categories are enabled, which would have been useful
to know
- contains a different list of categories from my autoreconf's man page

Desired result: if any warnings are on, then categories "", "all" and
nonstandard are on.  If I do not get the last, then nonstandard categories
produce a user's error message, rather than a programmer's error message.

Regards,
James the pedant.






___
File Attachments:


---
Date: Sat 22 Apr 2023 11:01:15 AM UTC  Name: configure.ac  Size: 458B   By:
None
Test case
<http://savannah.gnu.org/support/download.php?file_id=54649>
---
Date: Sat 22 Apr 2023 11:01:15 AM UTC  Name: autogen.sh  Size: 154B   By: None
Test case
<http://savannah.gnu.org/support/download.php?file_id=54650>

___

Reply to this item at:

  <https://savannah.gnu.org/support/?110872>

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

[sr #110852] autoconf 2.71 checking command to parse /usr/bin/nm -B output from gcc object

[anonymous]

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

The configure file added as an attachment.

(file #54475)

___

Additional Item Attachment:

File name: configure.txt  Size:575 KB




___

Reply to this item at:

  

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

[sr #110852] autoconf 2.71 checking command to parse /usr/bin/nm -B output from gcc object

[anonymous]

URL:
  <https://savannah.gnu.org/support/?110852>

 Summary: autoconf 2.71 checking command to parse /usr/bin/nm
-B output from gcc object
   Group: Autoconf
   Submitter: None
   Submitted: Sat 11 Mar 2023 11:00:33 PM UTC
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


___

Follow-up Comments:


---
Date: Sat 11 Mar 2023 11:00:33 PM UTC By: Anonymous
This issue looks like the same as:

https://lists.gnu.org/archive/html/bug-autoconf/2019-11/msg1.html

autoconf version: 2.71 (Fedora 37)
binutils version: 2.38

Output:

checking command to parse /usr/bin/nm -B output from gcc object...
./configure: line 6181:  -e 's/^T .* \(.*\)$/extern int \1();/p' -e
's/^[ABCDGIRSTW][ABCDGIRSTW]* .* \(.*\)$/extern char \1;/p': No such file or
directory
ok







___

Reply to this item at:

  <https://savannah.gnu.org/support/?110852>

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

[sr #110846] cross-compilation is not entered when build_alias and host_alias are the same

[anonymous]

URL:
  <https://savannah.gnu.org/support/?110846>

 Summary: cross-compilation is not entered when build_alias
and host_alias are the same
   Group: Autoconf
   Submitter: None
   Submitted: Wed 01 Mar 2023 02:18:17 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: d.l...@abatec.at
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux


___

Follow-up Comments:


---
Date: Wed 01 Mar 2023 02:18:17 PM UTC By: Anonymous
This might be the desired use case, but when cross compiling with systems like
buildroot one might have the same architecture on --build and --host.

Example: Compile on Apple silicon (aarch64-unknown-linux-gnu) for a Cortex A75
based system (aarch64-unknown-linux-gnu). Cross compiling isn't automatically
detected.
And there seems to be no way to force it if we know that we are cross
compiling.

See:
http://autobuild.buildroot.net/results/6d4/6d4bc520c12313508d0fadee11d5b88c35a3cba9/build-end.log







___

Reply to this item at:

  <https://savannah.gnu.org/support/?110846>

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

[sr #110828] configure: error: could not determine the string function for int64_t

[anonymous]

URL:
  <https://savannah.gnu.org/support/?110828>

 Summary: configure: error: could not determine the string
function for int64_t
 Project: Autoconf
   Submitter: None
   Submitted: Sun 29 Jan 2023 02:19:02 PM UTC
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


___

Follow-up Comments:


---
Date: Sun 29 Jan 2023 02:19:02 PM UTC By: Anonymous
Using 
autoconf-2.71.tar.xz2021-01-28 17:481.2M 
downloaded from:
http://ftp.gnu.org/gnu/autoconf/

The very same message that was already reported in another context: 
https://lore.kernel.org/all/962dda1b-66bf-693e-af53-3bc6c455e...@mind.be/T/

But it continues happening.

Steps to reproduce it:
Download latest Apache, curently 2.4.55 at the moment of this report:
https://dlcdn.apache.org/httpd/httpd-2.4.55.tar.bz2
If we would prepare just using ./configure, it does work well, and everything
works smoothly up to that point.

BUT when trying to use buildconf based on autoconf to follow this official
tutorial:
http://svn.apache.org/repos/asf/httpd/mod_fcgid/trunk/README-FCGID

namely, after using autoconf, the same ./configure command fails with:
configure: error: could not determine the string function for int64_t










___

Reply to this item at:

  <https://savannah.gnu.org/support/?110828>

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

[sr #110746] GNU Autoconf 2.71: F77 name-mangling fails when compiling with mpicxx

[anonymous]

URL:
  <https://savannah.gnu.org/support/?110746>

 Summary: GNU Autoconf 2.71: F77 name-mangling fails when
compiling with mpicxx
 Project: Autoconf
   Submitter: None
   Submitted: Fri 21 Oct 2022 10:26:42 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: bra...@ins.uni-bonn.de
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux


___

Follow-up Comments:


---
Date: Fri 21 Oct 2022 10:26:42 PM UTC By: Anonymous
Hello,

I tried to compile a software library with the compiler set to mpicxx (gcc,
Ubuntu 11.2.0-19ubuntu1)) and GNU Autoconf 2.71 and encountered F77
name-mangling errors during configuration with the following output to the
console.

o---
| Checking MPI and related programs
o---
checking whether we are using MPI... yes
checking whether we are using MPI I/O... yes
checking whether we are using MPI_Init_thread... yes
checking for mpirun... mpirun
configure: F77 set to gfortran
configure:  FC set to gfortran
configure:  CC set to mpicxx
configure: CXX set to mpicxx
checking whether the Fortran 77 compiler works... yes
checking for Fortran 77 compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU Fortran 77... yes
checking whether gfortran accepts -g... yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to get verbose linking output from gfortran... -v
checking for Fortran 77 libraries of gfortran... 
-L/usr/lib/gcc/x86_64-linux-gnu/11
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../.. -lgfortran -lm -lquadmath
checking whether make supports the include directive... yes (GNU style)
checking for gcc... mpicxx
checking whether the compiler supports GNU C... yes
checking whether mpicxx accepts -g... yes
checking for mpicxx option to enable C11 features... unsupported
checking for mpicxx option to enable C99 features... unsupported
checking for mpicxx option to enable C89 features... unsupported
checking whether mpicxx understands -c and -o together... yes
checking dependency style of mpicxx... gcc3
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... unknown

When looking at the config.log I identified the following sequence to probably
be the cause of the problem

configure:7972: checking for Fortran name-mangling scheme
configure:7986: gfortran -c -g -O2  conftest.f >&5
configure:7986: $? = 0
configure:8033: mpicxx -o conftest -O2 -Wall   conftest.c cfortran_test.o
-lgfortran  -L/usr/lib/gcc/x86_64-linux-gnu/11
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../.. -lgfortran -lm -lquadmath >&5
/usr/bin/ld: /tmp/ccT0CQ1j.ltrans0.ltrans.o: in function `main':
:(.text.startup+0x9): undefined reference to `foobar()'
collect2: error: ld returned 1 exit status
configure:8033: $? = 1
configure: failed program was:
| /* confdefs.h */
| ...
/* end confdefs.h.  */
|
| /* Override any GCC internal prototype to avoid an error.
|Use char because int might match the return type of a GCC
|builtin and then its argument prototype would still apply.  */
| char foobar ();
| #ifdef F77_DUMMY_MAIN
|
| #  ifdef __cplusplus
|  extern "C"
| #  endif
|int F77_DUMMY_MAIN() { return 1; }
|
| #endif
| #ifdef FC_DUMMY_MAIN
| #ifndef FC_DUMMY_MAIN_EQ_F77
| #  ifdef __cplusplus
|  extern "C"
| #  endifconfigure:8033: mpicxx -o conftest -O2 -Wall   
|int FC_DUMMY_MAIN() { return 1; }
| #endif
| #endif
| int
| main (void)
| {
| return foobar ();
|   ;
|   return 0;
| }

Similar results where obtained when testing for foobar_(), FOOBAR () and
FOOBAR_().
I suppose this it due to 
   char foobar ();
being defined before any occurrence of 
   #ifdef __cpluspluc
extern "C"
   #endif
For comparison I tried compiling the library with autoconf 2.69 installed and
everything worked fine. In this case the config.log displayed an additional
   #ifdef

[sr #110687] AC_C_BIGENDIAN fails when cross-compiling with -std=c11 and -flto

[anonymous]

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

> Can we see the config.log for -std=c11 only, please?

Should be attached. Invocation was:

autoheader && autoconf && rm -Rf config.status autom4te.cache/ && ./configure
--host=aarch64-linux-gnu CFLAGS="-std=c11"
checking for aarch64-linux-gnu-gcc... aarch64-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether aarch64-linux-gnu-gcc accepts -g... yes
checking for aarch64-linux-gnu-gcc option to enable C11 features... none
needed
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
configure: creating ./config.status
config.status: creating issue618config.h
config.status: issue618config.h is unchanged

(file #53474)

___

Additional Item Attachment:

File name: config.log Size:13 KB




___

Reply to this item at:

  

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

[sr #110687] AC_C_BIGENDIAN fails when cross-compiling with -std=c11 and -flto

[anonymous]

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

> It appears to me that this is an issue with cross compilation and strict
conformance mode (-std=c11), not with -flto.  Could you please report what
happens, using the same cross-compilation toolchain, if you run the same
configure command but using CFLAGS="-std=c11" LDFLAGS="" ?

In that case (only -std=c11) everything works as expected. 

checking for unistd.h... yes
checking whether byte ordering is bigendian... no
configure: creating ./config.status
config.status: creating issue618config.h


The issue only occurs when using -flto.

> It would also be helpful to know which C library is in use in the target
environment, and its version number.

The system is Ubuntu 22.04. glibc 2.35. The cross-compiler is
aarch64-linux-gnu-g++ (Ubuntu 11.2.0-17ubuntu1) 11.2.0.


___

Reply to this item at:

  

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

[sr #110687] AC_C_BIGENDIAN fails when cross-compiling with -std=c11 and -flto

[anonymous]

URL:
  <https://savannah.gnu.org/support/?110687>

 Summary: AC_C_BIGENDIAN fails when cross-compiling with
-std=c11 and -flto
 Project: Autoconf
   Submitter: None
   Submitted: Wed 27 Jul 2022 01:27:11 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: fanqu...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux


___

Follow-up Comments:


---
Date: Wed 27 Jul 2022 01:27:11 PM UTC By: Anonymous
Using the following configure.ac:

AC_INIT([issue618], [1.0], [foo@bar.invalid])
AC_CONFIG_HEADERS([issue618config.h])
AC_C_BIGENDIAN
AC_OUTPUT

and the following command:

autoheader && autoconf && rm -Rf config.status autom4te.cache/ && ./configure
--host=aarch64-linux-gnu CFLAGS="-std=c11 -flto" LDFLAGS="-flto"

configure fails with:

checking whether byte ordering is bigendian... unknown
configure: error: unknown endianness
 presetting ac_cv_c_bigendian=no (or yes) will help

config.log is attached.
See also: https://github.com/libexpat/libexpat/issues/618/.






___
File Attachments:


---
Date: Wed 27 Jul 2022 01:27:11 PM UTC  Name: config.log  Size: 13KiB   By:
None

<http://savannah.gnu.org/support/download.php?file_id=53473>

___

Reply to this item at:

  <https://savannah.gnu.org/support/?110687>

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

[sr #110599] configure doesn't actually check to see if make is installed

[anonymous]

URL:
  

 Summary: configure doesn't actually check to see if make is
installed
 Project: Autoconf
Submitted by: None
Submitted on: Wed 26 Jan 2022 04:02:27 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: bi...@mit.edu
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

Of all the things configure checks for by default, it doesn't actually check
that a suitable version of 'make' is installed on the host system. As such, if
you install the autotools but fail to install make, the configure script can
be generated, but it failed rather ungracefully at the end when running
depfiles commands.

Example:

...
checking for initscr in -lncurses... yes
checking for getopt... yes
checking for getopt_long... yes
checking for nodelay... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: error: in `/root/Documents/curses-speedtest':
config.status: error: Something went wrong bootstrapping makefile fragments
for automatic dependency tracking.  Try re-running configure with the
'--disable-dependency-tracking' option to at least be able to build
the package (albeit without support for automatic dependency tracking).
See `config.log' for more details





___

Reply to this item at:

  

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

[sr #110549] File expected to be at /usr/bin/file, isn't on ChromeOS

[anonymous]

URL:
  

 Summary: File expected to be at /usr/bin/file, isn't on
ChromeOS
 Project: Autoconf
Submitted by: None
Submitted on: Sat 16 Oct 2021 06:59:02 PM UTC
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:

I'm a developer for Chromebrew , a
package manager for ChromeOS.

We've had a problem with most all configure scripts: `file` is expected at
`/usr/bin/file`, but ChromeOS doesn't ship with `file`, so we have to provide
it at `/usr/local/bin/file`. `./configure` scripts generated with `autoconf`
are unaware of this and, instead of looking for the location of `file`, raise
an error:

./configure: line 6712: /usr/bin/file: No such file or directory

This particular error is an example from the latest version of `libsigsegv`

As I've never reported a bug of this type, I don't know what other information
would be helpful (logs, etc.), so please don't hesitate to let me know.




___

Reply to this item at:

  

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

[sr #110480] Generated configure script has errors

[anonymous]

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

Thanks for your reply!

I did search unsuccessfully through the configure.ac file for references to
the problematic fragment but if you feel that the source is in there
somewhere, I will have a closer look.


___

Reply to this item at:

  

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

[sr #110480] Generated configure script has errors

[anonymous]

URL:
  

 Summary: Generated configure script has errors
 Project: Autoconf
Submitted by: None
Submitted on: Mon 03 May 2021 04:00:09 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: skelb...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Mac OS

___

Details:

A user of the SANE project has an issue with a generated configure script.

A reference to the original conversation is here:

https://gitlab.com/sane-project/backends/-/issues/468

They are running autoconf 2.71. Attached at the above bug report can be found
their generated configure script.

The issue seems to be related to the generation of this segment in a couple of
places which has invalid syntax:


...
for as_dir in $PATH
do
  IFS=$as_save_IFS
  case $as_dir in #(((
''
 as_dir=./ ;;
*/) ;;
*) as_dir=$as_dir/ ;;
  esac
for ac_exec_ext in '' $ac_executable_extensions; do
  if as_fn_executable_p "$as_dir$ac_word$ac_exec_ext"; then
ac_cv_prog_CC="${ac_tool_prefix}gcc"
printf "%s\n" "$as_me:${as_lineno-$LINENO}: found
$as_dir$ac_word$ac_exec_ext" >&5
break 2
  fi
done
...
IFS=$as_save_IFS


In other areas this segment has valid syntax:

...
for as_dir in $PATH
do
  IFS=$as_save_IFS
  case $as_dir in #(((
'') as_dir=./ ;;
*/) ;;
*) as_dir=$as_dir/ ;;
  esac
for ac_exec_ext in '' $ac_executable_extensions; do
  if as_fn_executable_p "$as_dir$ac_word$ac_exec_ext"; then
ac_cv_prog_CC="${ac_tool_prefix}cc"
printf "%s\n" "$as_me:${as_lineno-$LINENO}: found
$as_dir$ac_word$ac_exec_ext" >&5
break 2
  fi
done
...


Any hints as to how we can track this down would be appreciated.




___

Reply to this item at:

  

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

[sr #110448] AC_CONFIG_AUX_DIRS fails with Windows paths

[anonymous]

URL:
  

 Summary: AC_CONFIG_AUX_DIRS fails with Windows paths
 Project: Autoconf
Submitted by: None
Submitted on: Mon 22 Feb 2021 10:23:28 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: sylv...@haskus.fr
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Microsoft Windows

___

Details:

Updating to autoconf 2.70 broke the build of GHC (Haskell compiler) on Windows
using msys2. I've tracked this to commit
35a1c64600894ecc3b06b6c4b273952db7c8fc83

This commit changed the way the auxiliary dirs are managed. They were put in a
space separated list and now they are put in a $PATH_SEPARATOR separated list.
I.e. it replaced [AC_CONFIG_AUX_DIRS("$srcdir" "$srcdir/.." "$srcdir/../..")]
with 
[${srcdir}${PATH_SEPARATOR}${srcdir}/..${PATH_SEPARATOR}${srcdir}/../..].

The issue is that on Windows we call configure with something like
"/usr/bin/sh c:\/msys64/home/Sylvain/ghc/libraries/ghc-bignum/configure ..."
and $srcdir becomes equal to
c:\/msys64/home/Sylvain/ghc/libraries/ghc-bignum/. But $PATH_SEPARATOR=":" so
we get:


configure:2437: looking for aux files: config.guess config.sub
configure:2450:  trying C/
configure:2450:  trying \/msys64/home/Sylvain/ghc/libraries/ghc-bignum/
configure:2450:  trying C/
configure:2450:  trying \/msys64/home/Sylvain/ghc/libraries/ghc-bignum/../
configure:2450:  trying C/
configure:2450:  trying \/msys64/home/Sylvain/ghc/libraries/ghc-bignum/../../
configure:2503: error: cannot find required auxiliary files: config.guess
config.sub



Shouldn't $ac_aux_dir_candidates be a space-separated list?




___

Reply to this item at:

  

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

[sr #110435] autoreconf does not recognize AM_ICONV

[anonymous]

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

[comment #1 comment #1:]
> > https://lists.gnu.org/archive/html/bug-gettext/2011-10/msg00012.html
> > When a project wants to only use AM_ICONV and none of the other gettext
autoconf macros
> 
> If your package only wants to use iconv() but no support for localized
messages, it should use the gnulib module 'iconv'. This module includes the
config.rpath file.

Could you show to me (and also to other people) a configure.ac example how to
to use it? Yes I just need to use only iconv() library and ICONV_CONST macro
in C source code which is provided by autoconf macro AM_ICONV.

> autoreconf deals with gettext for convenience. It does not know about gnulib
modules.
> 
> > projects which needs to use AM_ICONV started providing their own
"autogen.sh" script which copies required file config.rpath to current
directory and then run autoreconf.
> 
> This is not future-proof: if new files (.m4 files or else) are needed as new
dependencies of iconv.m4, this method will not know about it.

I know. But all projects started doing it due to above unfixed bug in
autoreconf/autopoint/gettext and it started to be de-facto start way how to
workaround above bug. And I'm just following this way.

___

Reply to this item at:

  

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

[sr #110435] autoreconf does not recognize AM_ICONV

[anonymous]

URL:
  

 Summary: autoreconf does not recognize AM_ICONV
 Project: Autoconf
Submitted by: None
Submitted on: Thu 28 Jan 2021 10:58:17 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: pali.ro...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

This is old bug which was reported at least 10 years ago, affects more
projects and there was no response for it yet. So I'm filling this bug report
again.

Here is one of the original reports:
https://lists.gnu.org/archive/html/bug-gettext/2011-10/msg00012.html

Problem is that if autoconf project wants to use AM_ICONV macro without any
other gettext macro support, autoreconf does not install required file
config.rpath, which leads to broken configure script.

Details with reproducer are in linked bug above.

As a temporary workaround to this issue, projects which needs to use AM_ICONV
started providing their own "autogen.sh" script which copies required file
config.rpath to current directory and then run autoreconf.




___

Reply to this item at:

  

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

[sr #110423] solaris

[anonymous]

URL:
  

 Summary: solaris
 Project: Autoconf
Submitted by: None
Submitted on: Tue 12 Jan 2021 01:01:02 PM UTC
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:






___

Reply to this item at:

  

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

[sr #110420] autoreconf: possibly undefined macro: AC_MSG_CHECKING

[anonymous]

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

Looks like installing autoconf-archive fixed the issue. I don't know why,
though. Anyway, sorry for the noise.

___

Reply to this item at:

  

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

[sr #110420] autoreconf: possibly undefined macro: AC_MSG_CHECKING

[anonymous]

URL:
  

 Summary: autoreconf: possibly undefined macro:
AC_MSG_CHECKING
 Project: Autoconf
Submitted by: None
Submitted on: Sun 10 Jan 2021 06:52:14 PM UTC
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:

autoreconf fails with current autoconf git master for libgda 5.2.10.

$ autoreconf --version
autoreconf (GNU Autoconf) 2.70.17-66fda

$ git clone https://gitlab.gnome.org/GNOME/libgda.git
$ cd libgda/
$ git co LIBGDA_5_2_10
$ autoreconf -fi

...snip...

configure.ac:79: error: possibly undefined macro: AC_MSG_CHECKING
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
configure.ac:86: error: possibly undefined macro: AC_MSG_RESULT
autoreconf: error: /usr/bin/autoconf failed with exit status: 1


configure.ac:
https://gitlab.gnome.org/GNOME/libgda/-/blob/LIBGDA_5.2/configure.ac#L79





___

Reply to this item at:

  

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

[sr #110417] Do not generate a back up file when running autoreconf

[anonymous]

URL:
  

 Summary: Do not generate a back up file when running
autoreconf
 Project: Autoconf
Submitted by: None
Submitted on: Tue 05 Jan 2021 12:35:46 PM UTC
Category: None
Priority: 5 - Normal
Severity: 1 - Wish
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: nuquaquara...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

Moving from autoconf v2.69 to v2.70, autoconf started to generate back-up
files of the configure script by appending a tilde ~. Give the opportunity to
the user to disable this behaviour, that is, do never generate a configure~.

The following is the response from Zack Weinberg to this request in the
mailing list on 04/Jan/2021: 

> It is not currently possible to disable this.  (The offending code is
> `sub update_file` in $prefix/share/autoconf/Autom4te/FileUtils.pm; if
> you look at it, you will see that the suffix used for the backup file
> can be changed with the $SIMPLE_BACKUP_SUFFIX environment variable,
> but there isn't any way to tell it not to create the backup at all.)

> Because FileUtils.pm is shared with Automake, changes require
> coordination between the two projects and take even longer than
> normal.  Would you please file an issue for this feature request,
> using https://savannah.gnu.org/support/?func=additem=autoconf
> (you may need to create an account) so we don't forget about it?






___

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 #110397] autoconf 2.70: autotest.m4 error

[anonymous]

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

Thanks for the quick response. Here are the autoconf and automake logs from
the CI node running macOS 11:
https://www.dropbox.com/s/ts1nx36buk3x7a8/logs.tar.gz?dl=1

The logs look similar on the nodes running 10.14 and 10.15, but let me know if
you'd like to have a look at them anyway.

You can also access the logs through the GitHub CI interface here:

https://github.com/Homebrew/homebrew-core/pull/66511/checks?check_run_id=1520593657

There is a way to access the raw logs and log archives for the whole CI run
through that interface if you need it.

Let me know if you need anything else.


___

Reply to this item at:

  

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

[sr #110397] autoconf 2.70: autotest.m4 error

[anonymous]

URL:
  

 Summary: autoconf 2.70: autotest.m4 error
 Project: Autoconf
Submitted by: None
Submitted on: Tue 08 Dec 2020 11:09:23 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: carlo.antonio.cabr...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Mac OS

___

Details:

Attempting to run autoconf 2.70 on the packaged autotest.m4 produces the
following error:

```
==> /usr/local/Cellar/autoconf/2.70/bin/autoconf autotest.m4
unknown channel m4trace: -1- _m4_warn(syntax, AC_INIT was never used, )
m4trace: -1- _m4_warn(syntax, AC_OUTPUT was never used, )
 at /usr/local/Cellar/autoconf/2.70/share/autoconf/Autom4te/Channels.pm line
631.
Autom4te::Channels::msg("m4trace: -1- _m4_warn(syntax, AC_INIT was never
used, )\x{a}m4tra"..., undef, undef, "partial", 0) called at
/usr/local/Cellar/autoconf/2.70/bin/autom4te line 1073
```

A similar error is generated when one attempts to build automake using the
newly built autoconf.

These errors were generated in Homebrew CI runs here:
https://github.com/Homebrew/homebrew-core/pull/66511

I can also reproduce the error quoted above on my local machine. Assistance
would be appreciated.




___

Reply to this item at:

  

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

[sr #110396] autoconf 2.70 c99 check uses ac_c_conftest_c89_program

[anonymous]

URL:
  

 Summary: autoconf 2.70 c99 check uses
ac_c_conftest_c89_program 
 Project: Autoconf
Submitted by: None
Submitted on: Tue 08 Dec 2020 09:12:34 PM UTC
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:

There is a typo in lib/autoconf/c.m4 that causes the C99 test to use the C89
test program variable instead.



___

File Attachments:


---
Date: Tue 08 Dec 2020 09:12:34 PM UTC  Name: autoconf-c99.diff  Size: 492B  
By: None
Fix C99 test typo


___

Reply to this item at:

  

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

[sr #110395] Makefile generated from Makefile.in unqoute *FLAGS variable twice while ./configure script only once

[anonymous]

URL:
  

 Summary: Makefile generated from Makefile.in unqoute *FLAGS
variable twice while ./configure script only once
 Project: Autoconf
Submitted by: None
Submitted on: Mon 07 Dec 2020 06:30:09 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: nikolai.meri...@member.fsf.org
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

For the following scenario it's impossible to provide correct CFLAGS with
attached configure.ac, Makefile.am, and main.c files.

You must use +CFLAGS='-DSTRING="string"'+ to pass +AC_COMPILE_IFELSE+ test
from configure.ac, but to provide same macro value to main.c you should use
+CFLAGS='-DSTRING=\"string\"'+.

As result we have the current situation:
> ./configure CFLAGS='-DSTRING="string"' && make # Fails on compilation
> ./configure CFLAGS='-DSTRING=\"string\"' && make # Fails on configuration



___

File Attachments:


---
Date: Mon 07 Dec 2020 06:30:09 PM UTC  Name: configure.ac  Size: 309B   By:
None


---
Date: Mon 07 Dec 2020 06:30:09 PM UTC  Name: Makefile.am  Size: 44B   By: None


---
Date: Mon 07 Dec 2020 06:30:09 PM UTC  Name: main.c  Size: 56B   By: None



___

Reply to this item at:

  

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

[sr #110393] Unconditional include of stdio.h should be avoided

[anonymous]

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

I've tested your changes. Everything works right now. Thank you. The bug
report can be closed as solved.

___

Reply to this item at:

  

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

[sr #110393] Unconditional include of stdio.h should be avoided

[anonymous]

URL:
  

 Summary: Unconditional include of stdio.h should be avoided
 Project: Autoconf
Submitted by: None
Submitted on: Sun 06 Dec 2020 11:39:26 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: kotovalexar...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

I'm building my library with cross-compiler without stdlib, so only several
headers are present (stdbool.h, stddef.h, stdarg.h, etc). Header stdio.h is
not present. However, it's used unconditionally in AC_CHECK_HEADER_STDBOOL and
AC_CHECK_HEADERS, so I receive the following output:

> checking for _Bool... no
> checking stddef.h usability... no
> checking stddef.h presence... yes
> configure: WARNING: stddef.h: present but cannot be compiled
> configure: WARNING: stddef.h: check for missing prerequisite headers?
> configure: WARNING: stddef.h: see the Autoconf documentation
> configure: WARNING: stddef.h: section "Present But Cannot Be Compiled"
> configure: WARNING: stddef.h: proceeding with the compiler's result
> configure: WARNING: ##
 ##
> configure: WARNING: ## Report this to
https://github.com/kernelmq/libkernaux/issues ##
> configure: WARNING: ##
 ##
> checking for stddef.h... no

config.log explains why checks fail:

> configure:5777: checking for _Bool
> configure:5777:
/home/kotovalexarian/repos/github/kernelmq/kernelmq/vendor/crosscompiler/bin/i686-elf-gcc
-c -ffreestanding -nostdlib -fno-builtin -fno-stack-protector  conftest.c >&5
> conftest.c:16:10: fatal error: stdio.h: No such file or directory
>  #include 
>   ^
> compilation terminated.
> configure:5777: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "libkernaux"
> | #define PACKAGE_TARNAME "libkernaux"
> | #define PACKAGE_VERSION "0.0.0"
> | #define PACKAGE_STRING "libkernaux 0.0.0"
> | #define PACKAGE_BUGREPORT "https://github.com/kernelmq/libkernaux/issues;
> | #define PACKAGE_URL "https://github.com/kernelmq/libkernaux;
> | #define ARCH_X86 1
> | #define ENABLE_CMDLINE 1
> | #define ENABLE_CONSOLE 1
> | #define ENABLE_MULTIBOOT2 1
> | #define ENABLE_PFA 1
> | #define PACKAGE "libkernaux"
> | #define VERSION "0.0.0"
> | /* end confdefs.h.  */
> | #include 
> | #ifdef HAVE_SYS_TYPES_H
> | # include 
> | #endif
> | #ifdef HAVE_SYS_STAT_H
> | # include 
> | #endif
> | #ifdef STDC_HEADERS
> | # include 
> | # include 
> | #else
> | # ifdef HAVE_STDLIB_H
> | #  include 
> | # endif
> | #endif
> | #ifdef HAVE_STRING_H
> | # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
> | #  include 
> | # endif
> | # include 
> | #endif
> | #ifdef HAVE_STRINGS_H
> | # include 
> | #endif
> | #ifdef HAVE_INTTYPES_H
> | # include 
> | #endif
> | #ifdef HAVE_STDINT_H
> | # include 
> | #endif
> | #ifdef HAVE_UNISTD_H
> | # include 
> | #endif
> | int
> | main ()
> | {
> | if (sizeof (_Bool))
> |  return 0;
> |   ;
> |   return 0;
> | }
> configure:5777: result: no



___

File Attachments:


---
Date: Sun 06 Dec 2020 11:39:26 AM UTC  Name: config.log  Size: 86KiB   By:
None



___

Reply to this item at:

  

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

[sr #110368] install-sh should be synced from automake

[anonymous]

URL:
  

 Summary: install-sh should be synced from automake
 Project: Autoconf
Submitted by: None
Submitted on: Mon 09 Nov 2020 12:13:45 PM UTC
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:

Since install-sh is now being installed as part of autoconf, we should make
sure to install the latest version rather than whichever version was used when
bootstrapping autoconf itself.

The build-aux/fetch.pl script is already supposed to fetch the latest version,
but install-sh is listed in .gitignore so any updates are discarded when
starting from a clean tree.

Indeed the automake repository contains some changes to install-sh that are
missing in the autoconf-2.64d tarball.




___

Reply to this item at:

  

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

[sr #110363] Requiring AC_REQUIRE_AUX_FILE to be in a macro contradicts Automake documentation

[anonymous]

URL:
  

 Summary: Requiring AC_REQUIRE_AUX_FILE to be in a macro
contradicts Automake documentation
 Project: Autoconf
Submitted by: None
Submitted on: Thu 05 Nov 2020 01:32:48 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: s...@collabora.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

dbus uses AC_REQUIRE_AUX_FILE to require tap-driver.sh to be present, similar
to the example given in Automake documentation:


 % cat configure.ac
 AC_INIT([GNU Try Tap], [1.0], [bug-autom...@gnu.org])
 AC_CONFIG_AUX_DIR([build-aux])
 AM_INIT_AUTOMAKE([foreign -Wall -Werror])
 AC_CONFIG_FILES([Makefile])
 AC_REQUIRE_AUX_FILE([tap-driver.sh])
 AC_OUTPUT


We've had a report (https://gitlab.freedesktop.org/dbus/dbus/-/issues/316)
that this fails with Autoconf 2.70 betas:


configure.ac:111: error: AC_REQUIRE(_AC_INIT_AUX_DIR): cannot be used outside
of an AC_DEFUN'd macro


Because this pattern is recommended by Automake, I think this needs to
continue to work in Autoconf 2.70, even if it might issue a deprecation
warning in 2.70 and stop working in a future release.




___

Reply to this item at:

  

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

[sr #110362] STRERROR_R_CHAR_P broken by 326c9a547423d25c621bc5c0ef76edbf6eda8c92

[anonymous]

URL:
  

 Summary: STRERROR_R_CHAR_P broken by
326c9a547423d25c621bc5c0ef76edbf6eda8c92
 Project: Autoconf
Submitted by: None
Submitted on: Wed 04 Nov 2020 09:08:51 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: pter...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

After
http://git.savannah.gnu.org/cgit/autoconf.git/commit/lib/autoconf/functions.m4?id=326c9a547423d25c621bc5c0ef76edbf6eda8c92
detection fails because  is no longer included.


checking whether strerror_r is declared... yes
checking whether strerror_r returns char *... no



configure:11444: x86_64-mageia-linux-gnu-gcc -c -O2 -g -pipe -Wformat
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector
--param=ssp-buffer-size=4 -fstack-protector-all
-fasynchronous-unwind-tables -I/usr/include/et -fPIC
-fno-strict-aliasing -fstack-protector-all -I/usr/include/et
conftest.c >&5
conftest.c: In function 'main':
conftest.c:77:14: warning: implicit declaration of function
'strerror_r' [-Wimplicit-function-declaration]
   77 |char x = *strerror_r (0, buf, sizeof buf);
  |  ^~
conftest.c:77:13: error: invalid type argument of unary '*' (have 'int')
   77 |char x = *strerror_r (0, buf, sizeof buf);
  | ^~~~
conftest.c:78:14: warning: initialization of 'char *' from 'int' makes
pointer from integer without a cast [-Wint-conversion]
   78 |char *p = strerror_r (0, buf, sizeof buf);
  |  ^~
configure:11444: $? = 1


The suspicious part of the commit is:


-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT],
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],





___

Reply to this item at:

  

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

[sr #110359] PATH ignored searching for g++

[anonymous]

URL:
  

 Summary: PATH ignored searching for g++
 Project: Autoconf
Submitted by: None
Submitted on: Mon 02 Nov 2020 01:24:22 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: nat...@acm.org
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

I have built and installed an uptodate g++ in a local directory, and pointed
my PATH at that set of tools.  The system g++ is too old (and no, I can;t
update it).

the autoconf 2.69c beta seems to ignore that and finds the g++ in /bin.

here's the PATH as printed in the config.log


PATH: /data/users/nathans/tools/bin/
PATH: /home/nathans/my/bin/
PATH: /data/users/nathans/tools/bin/
PATH: /usr/local/bin/
PATH: /bin/
PATH: /usr/bin/
PATH: /usr/local/sbin/
PATH: /usr/sbin/
PATH: /usr/facebook/ops/scripts/
PATH: /usr/facebook/scripts/
PATH: /usr/facebook/scripts/db/

Notice that has /data/users/nathans/tools/bin in there twice.  the second one
is from the shell's PATH var:

devvm293:368>echo $PATH
/home/nathans/my/bin:/data/users/nathans/tools/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/usr/facebook/ops/scripts:/usr/facebook/scripts:/usr/facebook/scripts/db

the first is because the configure script is explicitly putting it there (via
a --with-tools= option)


here's what it says of g++

configure:2348: checking for g++
configure:2369: found /bin/g++
configure:2380: result: g++
configure:2407: checking for C++ compiler version
configure:2416: g++ --version >&5
g++ (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5)

Here's my actual g++

devvm293:362>whence -p g++
/data/users/nathans/tools/bin/g++

devvm293:371>g++ --version
g++ (GCC) 10.1.1 20200604


I've not dug further into this.  The project containing all this is
gihub.com/urnathan/joust, I attach the configure.ac and config.m4, shout if
you need more.




___

File Attachments:


---
Date: Mon 02 Nov 2020 01:24:22 PM UTC  Name: configure.ac  Size: 1KiB   By:
None
configure scripts

---
Date: Mon 02 Nov 2020 01:24:22 PM UTC  Name: config.m4  Size: 8KiB   By: None
configure scripts

---
Date: Mon 02 Nov 2020 01:24:22 PM UTC  Name: configure  Size: 139KiB   By:
None
configure scripts


___

Reply to this item at:

  

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

[sr #110320] Test suite failures of automake 2.69c beta on Solaris

[anonymous]

URL:
  

 Summary: Test suite failures of automake 2.69c beta on
Solaris
 Project: Autoconf
Submitted by: None
Submitted on: Sun 27 Sep 2020 06:22:40 PM UTC
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:

Hi,

I have different failures on Solaris 10 on Sparc and i386:
  sparc: testsuite: 212 275 313 failed
  i386: testsuite: 275 313 failed
Please find the tests/testsuite.dir attached for each of them.



___

File Attachments:


---
Date: Sun 27 Sep 2020 06:22:40 PM UTC  Name:
autoconf-2.69c-i386-tests-testsuite.dir.tar.gz  Size: 862KiB   By: None


---
Date: Sun 27 Sep 2020 06:22:40 PM UTC  Name:
autoconf-2.69c-sparc-tests-testsuite.dir.tar.gz  Size: 878KiB   By: None



___

Reply to this item at:

  

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

[sr #110287] Two new test failures in automake-1.16.2 with autoconf-2.67b

[anonymous]

URL:
  

 Summary: Two new test failures in automake-1.16.2 with
autoconf-2.67b
 Project: Autoconf
Submitted by: None
Submitted on: Fri 31 Jul 2020 02:37:30 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: Ken Moffat 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

With autoconf-2.67b, two automake-1.16.2 tests t/autohdr4.sh and
t/autohdr-subdir-pr12495.sh ] now fail (previously, automake had no failures
and old autoconf had the proverbial shedload, now autoconf has no failures.

System is linux x86_64, a variation of linuxfromscratch.

Unsure if this belongs with autoconf or automake, so initially reporting to
autoconf as requested in the release announcement.



___

File Attachments:


---
Date: Fri 31 Jul 2020 02:37:30 AM UTC  Name: automake-1.16.2-new-failures 
Size: 2KiB   By: None
The two failures


___

Reply to this item at:

  

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

[sr #110269] AC_PROG_LEX failing

[anonymous]

URL:
  

 Summary: AC_PROG_LEX failing
 Project: Autoconf
Submitted by: None
Submitted on: Wed 15 Jul 2020 04:04:43 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: r...@burtonini.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

Both Flex and gdbm use AC_PROG_LEX and fail the same way with autoconf
2.70beta but worked with 2.69.

| checking for flex... flex
| checking for lex output file root... lex.yy
| checking for lex library... not found
| configure: error: required lex library not found

The config.log shows it trying a few options:

configure:12442: checking for lex library
configure:12457: aarch64-poky-linux-gcc  -fstack-protector-strong 
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
--sysroot=/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0/recipe-sysroot
-o conftest  -O2 -pipe -g -feliminate-unused-debug-types
-fmacro-prefix-map=/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0=/usr/src/debug/flex/2.6.4-r0

-fdebug-prefix-map=/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0=/usr/src/debug/flex/2.6.4-r0

-fdebug-prefix-map=/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0/recipe-sysroot=

-fdebug-prefix-map=/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0/recipe-sysroot-native=
  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now conftest.c 
 >&5
/usr/src/debug/flex/2.6.4-r0/build/conftest.l:17: undefined reference to
`yywrap'


configure:12457: aarch64-poky-linux-gcc  -fstack-protector-strong 
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=format-security
--sysroot=/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0/recipe-sysroot
-
o conftest  -O2 -pipe -g -feliminate-unused-debug-types
-fmacro-prefix-map=/home/ross/Yocto/build/tmp/work/armv8a-
poky-linux/flex/2.6.4-r0=/usr/src/debug/flex/2.6.4-r0 
-fdebug-prefix-map=/home/ross/Yocto/bui
ld/tmp/work/armv8a-poky-linux/flex/2.6.4-r0=/usr/src/debug/flex/2.6.4-r0  
   -fdebug-prefix-map=/
home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0/recipe-sysroot=
 -fdebug-prefix
-map=/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0/recipe-sysroot-native=
  -Wl,-O1 -Wl,--hash-s
tyle=gnu -Wl,--as-needed -Wl,-z,relro,-z,now conftest.c -lfl  >&5
/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/.
./../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/10.1.0/ld: cannot find
-lfl


configure:12457: aarch64-poky-linux-gcc  -fstack-protector-strong 
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
--sysroot=/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0/recipe-sysroot
-o conftest  -O2 -pipe -g -feliminate-unused-debug-types
-fmacro-prefix-map=/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0=/usr/src/debug/flex/2.6.4-r0

-fdebug-prefix-map=/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0=/usr/src/debug/flex/2.6.4-r0

-fdebug-prefix-map=/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0/recipe-sysroot=

-fdebug-prefix-map=/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0/recipe-sysroot-native=
  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now conftest.c
-ll  >&5
/home/ross/Yocto/build/tmp/work/armv8a-poky-linux/flex/2.6.4-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/10.1.0/ld:
cannot find -ll




___

Reply to this item at:

  

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

[sr #110210] nasm fails with autoconf master

[anonymous]

URL:
  

 Summary: nasm fails with autoconf master
 Project: Autoconf
Submitted by: None
Submitted on: Wed 18 Mar 2020 02:43:44 PM UTC
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:

With autoconf master 8a0900 (~2020-03-18), nasm 2.14.02 is failing like this:

checking for uintptr_t... yes
./configure: line 6400: syntax error near unexpected token `do'
./configure: line 6400: `do :'

Those line numbers are messed up because there isn't a do token around line
6400.

If I revert to autoconf 2.69, nasm builds successfully.




___

Reply to this item at:

  

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

[sr #109676] only one "checking whether the AC_LANG compiler works"

[anonymous]

URL:
  

 Summary: only one "checking whether the AC_LANG compiler
works"
 Project: Autoconf
Submitted by: None
Submitted on: Sat 04 May 2019 07:44:13 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: wil...@tuliptree.org
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

Consider this simple configure.ac file.
AC_INIT
AC_PROG_CC
AC_PROG_CXX

AC_LANG(C)
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
int i = 0;
])],
[AC_MSG_RESULT([yes])],
[AC_MSG_ERROR([int not supported])])
AC_LANG(C++)
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
int i = 0;
])],
[AC_MSG_RESULT([yes])],
[AC_MSG_ERROR([int not supported])])

If I run autoconf 2.69 to create a configure script, and then run it with a
broken C compiler, I get a useful error.
rohan:2097$ CC=/bin/broken ./configure
checking for gcc... /bin/broken
checking whether the C compiler works... no
configure: error: in `/home/jimw/tmp':
configure: error: C compiler cannot create executables
See `config.log' for more details
rohan:2098$ 

If I run it with a broken C++ compiler, I get a confusing error.
rohan:2098$ CXX=/bin/broken ./configure
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... no
checking whether /bin/broken accepts -g... no
yes
configure: error: int not supported
rohan:2099$ 

The problem here is that the check to verity whether a compiler works is
buried in _AC_COMPILER_EXEEXT_DEFAULT in lang.m4 which is used in c.m4 via
m4_expand_once([_AC_COMPILER_EXEEXT])[]dnl
so only the very first AC_PROG_C* call gets checked.  Most linux distros will
let you install a C compiler without installing a C++ compiler.  This has
resulted in some user confusion with the GCC configure script.  See for
instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63509
and
https://github.com/riscv/riscv-gnu-toolchain/issues/431

We could work around the problem in GCC by calling AC_PROG_CXX before
AC_PROG_CC, but it would be nice if autoconf created a configure script that
verified that both compilers work instead of just the first one.





___

Reply to this item at:

  

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

[sr #109513] Release Autoconf 2.70

[anonymous]

URL:
  

 Summary: Release Autoconf 2.70
 Project: Autoconf
Submitted by: None
Submitted on: Thu 31 May 2018 08:42:38 PM UTC
Category: None
Priority: 5 - Normal
Severity: 4 - Important
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: nicholas.cl...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

It's been 6 years and 195 commits sonce the last Autoconf release. Autoconf is
still a major part of the GNU build system, and could really use an update.

Your fans are eagerly waiting!





___

Reply to this item at:

  

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

[sr #109320] _AC_PROG_LEX_YYTEXT_DECL fails to compute LEXLIB correctly using the original AT lex if Xcode's flex is installed

[anonymous]

URL:
  

 Summary: _AC_PROG_LEX_YYTEXT_DECL fails to compute LEXLIB
correctly using the original AT lex if Xcode's flex is installed
 Project: Autoconf
Submitted by: None
Submitted on: Tue 23 May 2017 01:04:53 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: t...@ojodeagua.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Mac OS

___

Details:

Mac OS installs flex (obsolete version 2.5.35) as a part of Xcode's command
line tools, with it's library installed as /usr/lib/libl.a.

I have a copy of a more recent flex (version 2.6.1) installed in
/usr/local/bin, with its library installed as /usr/local/lib/libfl.a.

I also have a copy of the 4.3BSD version of lex installed in /usr/local/bin,
with it's library installed as /usr/local/lib/libl.a.

I have a package that I want to be able to build with either lex or flex.

If I force AC_PROG_LEX to use lex rather than flex when running configure, the
AC_LINK_IFELSE test located in _AC_PROG_LEX_YYTEXT_DECL fails for all choices
('', -lfl, -ll) but the AC_PROG_LEX macro completes with output message "none
needed" (and with LEXLIB empty).

It took me a bit of head scratching until I understood what was happening: The
loop running AC_LINK_IFELSE is not distinguishing between termination with
success ("break" out of the loop) and termination with failure (normal
completion of the loop). The AC_LINK_IFELSE fails when I force the use of lex
because it tries to use the (incorrectly named) 'flex' link library
/usr/lib/libl.a, since the default library search path is /usr/lib then
/usr/local/lib.

I can, of course, work around this defect in _AC_PROG_LEX_YYTEXT_DECL by
setting LDFLAGS="-L/usr/local/lib" on the configure command line.

However, it would have been nice if configure pointed out my error
explicitly.

I have attached a patch to the file "programs.m4"



___

File Attachments:


---
Date: Tue 23 May 2017 01:04:53 AM UTC  Name: programs.m4.patch  Size: 979B  
By: None



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[sr #108605] autoconf mis-detects arch (and other things)

[anonymous]

URL:
  http://savannah.gnu.org/support/?108605

 Summary: autoconf mis-detects arch (and other things)
 Project: Autoconf
Submitted by: None
Submitted on: Mon 30 Jun 2014 02:02:41 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: dshadoww...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

On, at least, GNU/Linux Mint 17 (and the Ubuntu and Debian versions it
descends from) the 'arch' program is located in /usr/bin and is the GNU
version, which does not accept the '-k' parameter, leaving programs configured
using autoconf claiming 'unknown' for the architecture.

1638:/bin/arch  = `(/bin/arch) 2/dev/null  || echo
unknown`
1639:/usr/bin/arch -k   = `(/usr/bin/arch -k) 2/dev/null   || echo
unknown`

Those line are from the git repository of autoconf and are from lib/m4sh.m4  -
 I have not checked, but it seems, to me, that this is broken. 

In the same file it calls the program 'uname' fine with no path, but when it
looks for the '-p' option, it is written to reference /usr/bin/uname (which
doesn't exist on Mint 17). Then, on the next line, it calls /bin/uname with
the '-X' option, which isn't a valid option for the GNU version of the program
(although it does get the path to the program correct).

(note that '-p' and '-X' do not appear in the SuS, so they are either GNU
extensions or vendor extensions, however...)


This does seem, however, to point to a use of absolute paths where not
necessary (all tools needed to configure/build something should be available
via $PATH) and it might be better if, in some cases, the absolute paths were
not used. (or something like 'locate' or 'which' were used to determine the
location/availability of the command needed)




___

Reply to this item at:

  http://savannah.gnu.org/support/?108605

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

[anonymous]

URL:
  http://savannah.gnu.org/support/?107986

 Summary: autoconf should reject or specifically warn about
obviously wrong configure.ac files
 Project: Autoconf
Submitted by: None
Submitted on: Fri 16 Mar 2012 05:23:10 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: dwhee...@dwheeler.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

The key input to autoconf is configure.ac, but obviously wrong
configure.ac files just sail through.  This is bad, especially for people just
starting to learn autoconf, because a simple typo can produce
mysterious-to-them results.  Autoconf should detect at least some obviously
wrong situations, like any other compiler, and complain specifically about
problems so they can be fixed quickly instead of debugged.

1. autoconf should fail loudly if either AC_INIT or AC_OUTPUT are missing, and
specifically say AC_INIT missing and/or AC_OUTPUT missing.

2. If AC_INIT's first parameter contains any whitespace, it should at least
warn.  A common beginner mistake is to think that whitespace is irrelevant in
m4, e.g.:
  AC_INIT( hello , 0.01 )
but the trailing whitespace is actually part of the parameter.  If there *is*
no first parameter (or it's empty), that should probably emit a warning.

3. If there are some other places where beginners are likely to make a mistake
(e.g., whitespace at the end that would probably cause a problem), autoconf
should detect it and either warn or error out.

This would make autoconf easier to work with, since problems would be
immediately and specifically identified, instead of having to debug them.

Thank you!





___

Reply to this item at:

  http://savannah.gnu.org/support/?107986

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[sr #106256] configure removed source file named a.h

[anonymous]

URL:
  http://savannah.gnu.org/support/?106256

 Summary: configure removed source file named a.h
 Project: Autoconf
Submitted by: None
Submitted on: Tuesday 02/12/2008 at 21:39 UTC
Category: None
Priority: 5 - Normal
Severity: 4 - Important
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

Showing a demo project to a class of students
I've noticed that one of my source files: a.h was
removed after running configure.

Looking at the configure script the culprit seems
to be a section that tries to remove some temporary
files:
 - The list of these files is assigned to $ac_files
 - This list includes a.*
 - Later this list is filtered out of some protected
   files and suffixes (that's why the file a.c in the
   same directory was *not* removed, while a.h was removed).
 - The originating code in autoconf looks like it comes from
   lib/autoconf/lang.m4

Having a configure script remove any source file looks like
a major show stopper to me (better to leave clutter arround
until there is a good solution than to kill anybody who
says Nee ;-)







___

Reply to this item at:

  http://savannah.gnu.org/support/?106256

___
  Message sent via/by Savannah
  http://savannah.gnu.org/