Bug 1943013

Ondrej,
where are the logs of the build failure?

https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/ -> Clicking on the package_name -> clicking on build_id (ideally last) -> builder-live.log.gz

Thanks Ondrej,
this is a failure in the tests, the build seem to be fine with autoconf-2.71

Do you think autoconf could influence how the tests are run in this case?
To me looks like an unrelated failure...

Have you done a build with older autoconf for comparison?

From my POV it can be affected.

If you run a normal scratch-build, it will rebuild the package against autoconf-2.69 which is currently the default. There you can see if the tests are failing.

I already did that, and it passes there.
Unfortunately the logs do not make me understand what breaks here. It could be that the newly built modules are not place in the correct directory or something as the test complains that no mechanism was found.
Although that is odd given the previuous three test, which use mechanisms too pass fine, so it will take some time for me to figure out, as I'll probably have to rebuild a rawhide system and manually build there at this point...

I think I found the issue, with 2.71 I get this error in configure that doesn't show up in current rawhide:

checking for SPNEGO support in GSSAPI libraries... ./configure: line 18777: ac_fn_c_try_run: command not found
no

Is that a function that has been removed in 2.71 ??

I do not know cyrus-sasl package. But maybe adding "autoreconf -fiv" to spec file to generate new configure should be useful. If it helps or you will another solution, feel free to share it here: https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test

The spec already runs the autogen.sh script which contains:

autoreconf --verbose --force --install -Wno-portability || exit 1

This is the configure.ac snippet that should generate the part fo configure that is failing:

  AC_MSG_CHECKING([for SPNEGO support in GSSAPI libraries])
  AC_TRY_RUN([
#ifdef HAVE_GSSAPI_H
#include <gssapi.h>
#else
#include <gssapi/gssapi.h>
#endif

int main(void)
{
    gss_OID_desc spnego_oid = { 6, (void *) "\x2b\x06\x01\x05\x05\x02" };
    gss_OID_set mech_set;
    OM_uint32 min_stat;
    int have_spnego = 0;
                                                                               
    if (gss_indicate_mechs(&min_stat, &mech_set) == GSS_S_COMPLETE) {
        gss_test_oid_set_member(&min_stat, &spnego_oid, mech_set, &have_spnego);
        gss_release_oid_set(&min_stat, &mech_set);
    }

    return (!have_spnego);  // 0 = success, 1 = failure
}
],      
        [ AC_DEFINE(HAVE_GSS_SPNEGO,,[Define if your GSSAPI implementation supports SPNEGO])
        AC_MSG_RESULT(yes) ],
        AC_MSG_RESULT(no))



Is there anything in here that would not be supported with the new autoconf ?


Note that I see other similar failures with
  ac_fn_c_try_run: command not found

So it seem not specific to this snippet...

Onderj,
after looking more carefully at this, it seem to me this may be a bug in autoconf-2.71

The function ac_fn_c_try_run () is defined, but after attempted use.

If I read the code correctly the function is defined just before the first use of AC_TRY_RUN in configure.ac, but include files imported before that point already sued AC_TRY_RUN.
Sounds to me autoconf fails to realize that an include file is using this function during expansion and therefore fails to pull its declaration forward, early enough to be there when the expanded include snipped is invoked in the final configure.

WDYT?

I did an experiment.
I added this snippet to configure.ac before m4 macros are imported (right after AC_INIT):

AC_TRY_RUN([
int main(void)
{
   return 0;
}
])

and this fixed the declaration ordering problem and configure completed without errors.

So this convinces me there is an autoconf bug here.

During our yesterday experiments on #fedora-devel, even moving
just the `AC_CHECK_SIZEOF(long)` up is enough to work-around this.

<praiskup> CMU_HAVE_OPENSSL brings CMU_FIND_LIB_SUBDIR brings AC_CHECK_SIZEOF(long) ... that brings the use of *check_int and that brings the use of ac_fn_c_try_run ... but it doesn't bring the macro defining it

But since AC_CHECK_SIZEOF is working fine, seems like something else confuses
it and makes that macro think that `ac_fn_c_try_run` is already defined.

IMO there's something wrong with calling AC_TRY_RUN in AC_CACHE_VAL.
Poking at NEWS:

*** Many macros no longer AC_REQUIRE as many other macros as they used to.

  This can expose several classes of latent bugs.  These are the ones
  we know about:

   - Make sure to explicitly invoke all of the macros that set result
     variables used later in the configure script, or in generated
     Makefiles.

   - Autoconf macros that use AC_REQUIRE are not safe to use in shell
     control-flow constructs that appear outside of macros defined by
     AC_DEFUN.  Use AS_IF, AS_CASE, etc. instead.  (See the
     “Prerequisite Macros” section of the manual for details.)

     The set of macros that use AC_REQUIRE internally may change from
     release to release.  The only macros that are guaranteed *not* to
     use AC_REQUIRE are the macros for acting on the results of a
     test: AC_DEFINE, AC_SUBST, AC_MSG_*, AC_CACHE_CHECK, etc.

   - AC_REQUIRE cannot be applied to macros that need to be used with
     arguments.  Instead, invoke the macro normally, with its arguments.

So wrap by AC_DEFUN could help.

Simo,

thanks for the report, I will try to communicate it with upstream and see if it is a bug or just a new "feature". Have you tried to use Pavel's advice ? Does it work for you ?

Pavel, thanks for your opinion!

Ondrej

upstream issue:

https://lists.gnu.org/archive/html/bug-autoconf/2021-04/msg00001.html

I missed before that the use of AC_TRY_RUN in AC_CACHE_VAL is not quoted,
which is at least not clean (likely a bug) - and it seems like adding
quotes there helps.

Also, there's another wrong thing .. there's the use of AC_DEFINE in
the if-else commands, while it is documented that nothing should have
a side-effects (docs "7.4 Caching Results"):

    | It is common to find buggy macros using ‘AC_CACHE_VAL’ or
    | ‘AC_CACHE_CHECK’, because people are tempted to call ‘AC_DEFINE’ in the
    | COMMANDS-TO-SET-IT.  Instead, the code that _follows_ the call to
    | ‘AC_CACHE_VAL’ should call ‘AC_DEFINE’, by examining the value of the
    | cache variable.  For instance, the following macro is broken:
    | ...

Ondrej,
thanks for reporting in the mailing list.

The question is, what now?
Should we wait until we hear from upstream?
Should I add a workaround (see comment 11) until resolved?
Something else?

> Should we wait until we hear from upstream?

Since the use of AC_CACHE_VAL has non-quoted arguments, likely this is not
going to be considered an Autoconf issue.  But we'll see..

> Something else?

I proposed this to cyrus-sasl upstream:
https://github.com/cyrusimap/cyrus-sasl/pull/644

We already have a response from upstream:

https://lists.gnu.org/archive/html/bug-autoconf/2021-04/msg00003.html

and it should be a quoting problem. Simo, can you please test it ?

Sorry Ondrej,
I am not well versed enough in autoconf to understand what needs to be quoted.
Can you please give me an example for one of the instances I should change ?

(In reply to Simo Sorce from comment #19)
> Sorry Ondrej,
> I am not well versed enough in autoconf to understand what needs to be
> quoted.
> Can you please give me an example for one of the instances I should change ?

Please just use Pavel's patch proposed above (https://github.com/cyrusimap/cyrus-sasl/pull/644)

It should fix the problem with autoconf-2.71 and should be also buildable with current autoconf-2.69

Fixed in cyrus-sasl-2.1.27-10.fc35