Static build problems

[Jacob Welsh]

I'm attempting to build the latest Dovecot, version 2.3.19.1, on Gales 
Linux, a distribution based on musl libc with all static linking.

After working around some expected troubles to generate configure, such as 
the libtool and iconv.m4 dependencies, the build appeared to complete 
successfully. But on closer inspection, the plugins were installed as a 
bunch of .a and .la files rather than getting linked into any of the 
binaries, as would be necessary to actually use them.

I determined that the probe for dynamic module support (DOVECOT_MODULES 
defined in 'm4/modules.m4') had returned a false positive: in the static 
configuration musl includes a stub dlopen() that always returns failure at 
runtime, so a compile-and-link-only test is not predictive. Libtool itself 
is affected in the same way, but it comes with the --disable-shared option 
which usually makes things works fine.

Short of a proper solution (perhaps removing modules.m4 and going instead 
by what libtool already determined, since you've decided to depend on it 
anyway), I stubbed out modules.m4 to simply return the correct result for 
this platform, thus:

AC_DEFUN([DOVECOT_MODULES], [
   have_modules=no
   AC_SUBST(MODULE_LIBS)
   AC_SUBST(DLLIB)
])

Now the build is failing due to the absence of a function that's defined 
only when HAVE_MODULES is true:

libtool: link: gcc -I../../src/lib -I../../src/lib-test -I../../src/lib-ssl-iostream -DDCRYPT_MODULE_DIR=\"/gales/pkg/dovecot-0.0-2.3.19.1/lib/dovecot\" -DDCRYPT_SRC_DIR=\"../../src/lib-dcrypt\" -std=gnu99 -g -O1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -Wl,--whole-archive -Wl,../lib-ssl-iostream/.libs/libssl_iostream.a -Wl,--no-whole-archive -o test-stream test_stream-dcrypt.o test_stream-istream-decrypt.o test_stream-ostream-encrypt.o test_stream-test-stream.o  ../lib-ssl-iostream/.libs/libssl_iostream.a ../lib-test/.libs/libtest.a ../lib/.libs/liblib.a
test_crypto-dcrypt.o: In function `dcrypt_initialize':
/home/user/gales-linux/gports/dovecot/build/dovecot-2.3.19.1/src/lib-dcrypt/dcrypt.c:34: undefined reference to `module_dir_try_load_missing'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:664: test-crypto] Error 1

I noticed commit d21897832a443d139d56b1fb1c86d8f76e5f77f3 from 2009, 
"Fixed compiling without module support", and clearly it's supposed to 
work since the #ifdefs are there, but I begin to suspect that nobody's 
actually tested this branch of the configuration tree recently.

Further, looking through the automakefiles I'm not finding how the plugin 
libraries are supposed to work at all in this case and I begin to fear 
that they simply... aren't.

Say it ain't so?

Jacob