--enable-async-push --disable-plugins build failure for multi.c

[cpwgem]

Given the following configure:

./configure --enable-async-push --disable-plugins

multi.c will fail to compile with the following error:

gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include  -I../../include -I../../src/compat        -g -O2 -std=c99 -MT multi.o -MD -MP -MF .deps/multi.Tpo -c -o multi.o multi.c
multi.c: In function ‘multi_process_post’:
multi.c:2215:19: error: ‘struct key_state’ has no member named ‘auth_control_file’
       if (ks && ks->auth_control_file && ks->auth_deferred && !was_authenticated)
                   ^
multi.c:2218:70: error: ‘struct key_state’ has no member named ‘auth_control_file’
    long watch_descriptor = inotify_add_watch(m->top.c2.inotify_fd, ks->auth_control_file, IN_CLOSE_WRITE | IN_ONESHOT);

struct key_state is defined in ssl_common.h, and the missing member auth_control_file is defined as follows:

#ifdef PLUGIN_DEF_AUTH
  unsigned int auth_control_status;
  time_t acf_last_mod;
  char *auth_control_file;
#endif

This PLUGIN_DEF_AUTH expects --enable-plugins however the code in question:

#if defined(ENABLE_ASYNC_PUSH) && defined(ENABLE_DEF_AUTH)
      if (ks && ks->auth_control_file && ks->auth_deferred && !was_authenticated)
        {
          /* watch acf file */
          long watch_descriptor = inotify_add_watch(m->top.c2.inotify_fd, ks->auth_control_file, IN_CLOSE_WRITE | IN_ONESHOT);

Checks for ENABLE_DEF_AUTH without attempting to check for plugins being enabled/disable causing this compile to fail. It seems that replacing defined(ENABLE_DEF_AUTH) with defined(PLUGIN_DEF_AUTH) would avoid this.

[Gert Döring]

While I'd reclassify this as "minor", it's still an oversight regarding #ifdef combinations so we should try to fix this for 2.4.0...

[stipa]

That combination of options does not make much sense, since async-push is useful only for deferred authentication case, which requires plugins to be enabled.

I'll make configure script fail when async-push is enabled and plugins are disabled.

[Gert Döring]

@stipa: did this ever get resolved?

[stipa]

Surprisingly, no. Will look into that.

[Gert Döring]

bump :)