Re: Static build problems
> On 09/10/2022 21:35 EEST Jacob Welsh 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
Re: Static build problems
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
Re: Static build problems
> On 08/10/2022 01:51 EEST Jacob Welsh 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
Static build problems
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
