Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build fails with autoconf master #5126

Closed
rossburton opened this issue Mar 19, 2020 · 6 comments
Closed

Build fails with autoconf master #5126

rossburton opened this issue Mar 19, 2020 · 6 comments
Labels

Comments

@rossburton
Copy link
Contributor

@rossburton rossburton commented Mar 19, 2020

When cross-compiling curl 7.69.0 with autoconf master, the build fails:

| checking for inline... inline
| checking if cpp -P is needed... yes
| checking if cpp -P works... yes
| checking if compiler is DEC/Compaq/HP C... no
| checking if compiler is HP-UX C... no
| checking if compiler is IBM C... no
| checking if compiler is Intel C... no
| checking if compiler is clang... no
| checking if compiler is GNU C... yes
| checking if compiler is LCC... no
| checking if compiler is SGI MIPSpro C... no
| checking if compiler is SGI MIPS C... no
| checking if compiler is SunPro C... no
| checking if compiler is Tiny C... no
| checking if compiler is Watcom C... no
| configure: error: in `/scratch/poky/work/corei7-64-poky-linux/curl/7.69.0-r0/build':
| configure: error: cannot run test program while cross compiling

The build works fine with autoconf 2.69. This is OpenEmbedded, cross-compiling using gcc to a Linux platform.

@bagder bagder added the build label Mar 19, 2020
@bagder
Copy link
Member

@bagder bagder commented Mar 19, 2020

Isn't that then rather a sign that autoconf master is broken?

@rossburton
Copy link
Contributor Author

@rossburton rossburton commented Mar 19, 2020

Not definitely: flex broke too but it was abusing how m4 works, so arguably this is something in curl that shouldn't have worked.

Filed as a headsup, I'll do some more digging shortly to see if its anything obvious.

@bagder
Copy link
Member

@bagder bagder commented Mar 19, 2020

Can you figure out which function it runs into that error in?

@rossburton
Copy link
Contributor Author

@rossburton rossburton commented Mar 20, 2020

I filed https://savannah.gnu.org/support/?110213 to get support from the autoconf side.

Pasting the digging I've done so far:

It fails like this:

checking if compiler is DEC/Compaq/HP C... no 
checking if compiler is HP-UX C... no 
checking if compiler is IBM C... no 
checking if compiler is Intel C... no 
checking if compiler is clang... no 
checking if compiler is GNU C... yes 
checking if compiler is LCC... no 
checking if compiler is SGI MIPSpro C... no 
checking if compiler is SGI MIPS C... no 
checking if compiler is SunPro C... no 
checking if compiler is Tiny C... no 
checking if compiler is Watcom C... no 
configure: error: in `/scratch/poky/work/corei7-64-poky-linux/curl/7.69.0-r0/build': 
configure: error: cannot run test program while cross compiling 

Yes, I'm cross-compiling, but the invocation of AC_RUN_IFELSE is guarded with a $cross_compiling check.

Adding some echos, CURL_CHECK_COMPILER[1] succeeds but it never actually calls into the body of CURL_SET_COMPILER_BASIC_OPTS[2]. The generated code looks like this:

if test "$cross_compiling" = yes 
then : 
  { { printf "%s\n" "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5 
printf "%s\n" "$as_me: error: in \`$ac_pwd':" >&2;} 
as_fn_error $? "cannot run test program while cross compiling 
See \`config.log' for more details" "$LINENO" 5; } 
else 
  if ac_fn_c_try_run "$LINENO" 
then : 

fi 
rm -f core .core core.conftest. gmon.out bb.out conftest$ac_exeext \ 
  conftest.$ac_objext conftest.beam 
fi 

      # 
  if test "$compiler_id" != "unknown"; then 
... 

Which is the beginning of CURL_SET_COMPILER_BASIC_OPTS [3]. That eventually calls CURL_COMPILER_WORKS_IFELSE which has a AC_RUN_IFELSE wrapper without the cross-compiling fallback, but it is guarded with a $cross_compiling test[4].

Does autoconf now detect calls to AC_RUN_IFELSE without an if-cross-compiling option and abort ahead of time? If so, this breaks people who guard AC_RUN_IFELSE themselves, correct?

[1] https://github.com/curl/curl/blob/master/configure.ac#L258
[2] https://github.com/curl/curl/blob/master/m4/curl-compilers.m4#L571
[3] https://github.com/curl/curl/blob/master/m4/curl-compilers.m4#L575
[4] https://github.com/curl/curl/blob/master/m4/curl-compilers.m4#L536

@rossburton
Copy link
Contributor Author

@rossburton rossburton commented Mar 20, 2020

Solved! From that bug report:

I suspect (without testing) the problem is the presense of
AC_REQUIRE([AC_RUN_IFELSE]) inside of CURL_RUN_IFELSE.

(Line 7292 of curl-functions.m4)

This use of AC_REQUIRE makes no sense at all. With it there, if it
determines that there has been no prior expansion of AC_RUN_IFELSE in
the configure script, autoconf will output such an expansion at some
mostly-unspecified prior location with all arguments empty.

Such an expansion will cause the error you are seeing because the
action-if-cross-compiling argument is empty.

There are other weird uses if AC_REQUIRE in this file. I suspect the
author(s) of this script have a serious misunderstanding about what
this macro does.

I imagine that it just happened to work by luck with old autoconf
because older versions of macros you are using happened to expand
AC_RUN_IFELSE themselves and this just happened to prevent any major
problems later in the configure script.

I can confirm that removing that AC_REQUIRE solves the problem. I suggest reviewing all of the m4 files for other inappropriate use of that macro.

@bagder
Copy link
Member

@bagder bagder commented Mar 20, 2020

I suggest reviewing all of the m4 files for other inappropriate use of that macro.

Sure, but...

  1. I don't think we have anyone particular around in the project with the knowledge to do that, which is the reason why we're at this point to begin with.
  2. This apparently works with all the released versions of autoconf since decades.
@jay jay closed this in f25f602 Mar 21, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Jun 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants
You can’t perform that action at this time.