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
