Static build problems

[Aki Tuomi]

> On 08/10/2022 01:51 EEST Jacob Welsh <dovecot-ml at welshcomputing.com> wrote:
> 
>  
> 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

We don't test all static builds, since we don't use or ship Dovecot in that manner. So, it is very likely it will not work.

Aki