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
On 08/10/2022 01:51 EEST Jacob Welsh dovecot-ml@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 tomodule_dir_try_load_missing' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:664: test-crypto] Error 1I 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
On Sun, 9 Oct 2022, Aki Tuomi wrote:
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.
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.
Alright, then is there any desire to fix it?
Jacob
On 09/10/2022 21:35 EEST Jacob Welsh dovecot-ml@welshcomputing.com wrote:
On Sun, 9 Oct 2022, Aki Tuomi wrote:
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.
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.
Alright, then is there any desire to fix it?
Jacob
If you or someone else in community comes up with a fix we can consider merging it at some point.
Aki
participants (2)
-
Aki Tuomi
-
Jacob Welsh