autogen failed on centos7(AC_PROG_CC cannot be called after AM_PROG_CC_C_O) #890

[rc@cos108]~/secp256k1-24d1656c328c932cd533f6f4bf80b345b6591f0d$sh autogen.sh configure.ac:407: error: AC_PROG_CC cannot be called after AM_PROG_CC_C_O build-aux/m4/ax_prog_cc_for_build.m4:38: AX_PROG_CC_FOR_BUILD is expanded from... configure.ac:407: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: error: echo failed with exit status: 1 autoreconf: aclocal failed with exit status: 1

Ugh, I think what's happening here is that old versions of AM_PROG_CC_C_O really redefine AC_PROG_CC to print that error message (which is not really elegant). I don't have an authoritative source for now but grep this page for AC_PROG_CC cannot be called https://android.googlesource.com/platform/external/libevent/+/e867981d427db5e0b860d67485838e1f9e8c37da%5E!/

This is then relevant as our "CC_FOR_BUILD" macros later rely on AC_PROG_CC...

Now noone has noticed this so far since AM_PROG_CC_C_O is a noop in newer version (since Automake 1.14 released in 2013 but CentOS 7 is really on Automake 1.13... https://centos.pkgs.org/7/centos-x86_64/automake-1.13.4-3.el7.noarch.rpm.html)

So I believe these are our options:

• Remove the call to AM_PROG_CC_C_O. It can believe that people use Automake 1.13 but I don't think people will use compilers for which this check is relevant?! (How old are these compilers? Maybe @gmaxwell has some idea?)
• Add a workaround that makes a backup of AC_PROG_CC restores it after the call to AM_PROG_CC_C_O. I believe this works but it's a lot of hassle for that old compilers.
• Simply require Automake 1.14 . I don't think we should do this if this means the package won't compile on CentOS7. @theuni Feel free to jump in if you have better ideas. @HachikoT Can you include the output of autoconf --version and automake --version to be sure? It would also be nice if you can confirm that removing the AM_PROG_CC_C_O line in autoconf.ac makes the issue disappear.

Nothing is coming to mind of a potential vendor compiler that doesn't support setting the object output name (I think the issue is less old and more weird-- like some embedded target compiler, .. maybe both old and weird).

I think the issue you'll face is that I don't think older versions of automake will allow per target flags unless AM_PROG_CC_C_O is called. ... but maybe the need for per target flags is narrowly avoided by tests.c #including secp256k1.c instead of linking to it?

I think all AM_PROG_CC_C_O did was make the build fail if uses per-target flags an the compiler doesn't support it.

https://bugs.freedesktop.org/show_bug.cgi?id=11302 confirms what you're saying about per-target flags. The bad thing is that this happens even on 1.13.4 according to https://github.com/scanmem/scanmem/issues/289 . So if I understand correctly, this should mean that our build will fail on 1.13 with or without AM_PROG_CC_C_O (or at least warn and not be able to use per-target flags). -.-

So I guess the second bullet point is probably the way to go...

(By the way, https://bug-automake.gnu.narkive.com/MRexZL9f/missing-warning-about-absence-of-am-prog-cc-c-o also mentions that 2.9 fails but 2.10 does not fail anymore when using option subdir-objects, which we do.)

Just to add another datapoint. I ran into this when installing a python package (coincurve) that relies on this. It's an Amazon EC2 Linux instance with automake 1.13.4. The PR changes work if I build secp256k1 on its own, but stills fails when I attempt install coincurve via pip. I think coincurve builds its own version of secp256k1, but when I specify using the system library, it fails because it's expecting a certain header which it can't find.

but when I specify using the system library, it fails because it's expecting a certain header which it can't find.

This one? https://github.com/ofek/coincurve/blob/4277a06200627849548512c00c9325c3e4ddd190/setup_support.py#L71

Maybe try enabling --enable-module-ecdh when installing it system wide.

And thanks for reporting here. So you said the build worked with 1.13.4 with this PR. Can you also confirm that the build does not work without this PR? Then we at least know that this PR is solving a real issue.

I can confirm the build did not work without the PR. As for the coincurve issue, it was a different header file. Sorry I can't provide more information, I've moved onto another task and don't have the environment set up anymore.