> On 08/10/2022 01:51 EEST Jacob Welsh <dovecot...@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