Re: Bug#978893: ripperx: ftbfs with autoconf 2.70
On Thu, 31 Dec 2020 at 14:28:53 +0000, Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> autoconf 2.70, but succeeds to build with autoconf 2.69.
...
> The full build log can be found at:
> http://qa-logs.debian.net/2020/09/26.ac270/ripperx_2.8.0-2_unstable_ac270.log
> The last lines of the build log are at the end of this report.
I don't think those lines indicate the actual error, which looks like a C++
compiler problem (perhaps because the new Autoconf version passes options
that make the compiler more strict?):
> In file included from /usr/include/c++/10/ext/string_conversions.h:41,
> from /usr/include/c++/10/bits/basic_string.h:6535,
> from /usr/include/c++/10/string:55,
> from /usr/include/c++/10/stdexcept:39,
> from err_dialog_handler.h:6,
> from common.h:21,
> from calc_stat.h:3,
> from calc_stat.c:1:
> /usr/include/c++/10/cstdlib:151:11: error: ‘malloc’ has not been declared in ‘::’
> 151 | using ::malloc;
> | ^~~~~~
> In file included from /usr/include/c++/10/stdlib.h:36,
> from cddbp.c:6:
> /usr/include/c++/10/cstdlib:151:11: error: ‘malloc’ has not been declared in ‘::’
> 151 | using ::malloc;
> | ^~~~~~
> In file included from cddbp.c:6:
> /usr/include/c++/10/stdlib.h:65:12: error: ‘malloc’ has not been declared in ‘std’
> 65 | using std::malloc;
> | ^~~~~~
> In file included from /usr/include/c++/10/stdlib.h:36,
> from cddb.c:6:
> /usr/include/c++/10/cstdlib:151:11: error: ‘malloc’ has not been declared in ‘::’
> 151 | using ::malloc;
> | ^~~~~~
> In file included from cddb.c:6:
> /usr/include/c++/10/stdlib.h:65:12: error: ‘malloc’ has not been declared in ‘std’
> 65 | using std::malloc;
> | ^~~~~~
I tried to reproduce this in sbuild and got a different error:
> checking for strndup... (cached) yes
> checking for strstr... (cached) yes
> checking for openpty... no
> checking for openpty in -lutil... no
> configure: error: Missing required function: openpty
> tail -v -n \+0 config.log
> ==> config.log <==
...
> configure:5959: checking for openpty
> configure:5959: g++ -o conftest -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c >&5
...
> /usr/bin/ld: /tmp/ccVfJfLG.o: in function `main':
> ./conftest.c:65: undefined reference to `openpty'
> collect2: error: ld returned 1 exit status
| #ifdef __cplusplus
| extern "C"
| #endif
| char openpty ();
| /* The GNU C library defines this for functions which it implements
| to always fail with ENOSYS. Some functions are actually named
| something starting with __ and the normal name is an alias. */
| #if defined __stub_openpty || defined __stub___openpty
| choke me
| #endif
|
| int
| main (void)
| {
| return openpty ();
| ;
| return 0;
| }
...
> configure:5964: checking for openpty in -lutil
> configure:5987: g++ -o conftest -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c -lutil >&5
> /usr/bin/ld: /tmp/ccvWpbnJ.o: in function `main':
> ./conftest.c:46: undefined reference to `openpty()'
...
| /* 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 openpty ();
| int
| main (void)
| {
| return openpty ();
| ;
| return 0;
| }
This new error might be an Autoconf bug: the second check (with -lutil)
looks like it's missing an extern "C" on the prototype. If so,
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=b27bc3e230bb12fdd9a813e38e82bc4c3e22b4cc
might help.
smcv
Reply to: