If I compile claws-mail with `--enable-tests`, configuration fails with make[6]: *** No rule to make target '../pgpcore_la-pgp_utils.o', needed by 'pgp_utils_test'. Stop. If I specify `--disable-tests` instead it compiles fine. Tested with Claws mail git checkout from git://git.claws-mail.org/claws.git, latest commit hash 71e1e70a4 (commit date: 2021-11-06), on Artix Linux. The full `./configure` command line is: ./configure \ --prefix='/usr' \ --disable-static \ --enable-shared \ --enable-nls \ --enable-manual \ --enable-libsm \ --enable-ipv6 \ --enable-gnutls \ --enable-enchant \ --enable-crash-dialog \ --disable-generic-umpc \ --enable-compface \ --enable-pthread \ --enable-startup-notification \ --enable-dbus \ --enable-ldap \ --disable-jpilot \ --disable-networkmanager \ --enable-libetpan \ --disable-valgrind \ --disable-alternate-addressbook \ --enable-svg \ --enable-tests \ --enable-deprecated \ --enable-acpi_notifier-plugin \ --enable-address_keeper-plugin \ --enable-archive-plugin \ --enable-att_remover-plugin \ --enable-attachwarner-plugin \ --enable-bogofilter-plugin \ --enable-bsfilter-plugin \ --enable-clamd-plugin \ --enable-dillo-plugin \ --disable-fancy-plugin \ --enable-fetchinfo-plugin \ --enable-gdata-plugin \ --enable-libravatar-plugin \ --enable-litehtml_viewer-plugin \ --enable-mailmbox-plugin \ --enable-managesieve-plugin \ --enable-newmail-plugin \ --enable-notification-plugin \ --enable-pdf_viewer-plugin \ --enable-perl-plugin \ --enable-python-plugin \ --enable-pgpcore-plugin \ --enable-pgpmime-plugin \ --enable-pgpinline-plugin \ --enable-rssyl-plugin \ --enable-smime-plugin \ --enable-spamassassin-plugin \ --enable-spam_report-plugin \ --enable-tnef_parse-plugin \ --enable-vcalendar-plugin \ --enable-demo-plugin
This still applies to latest git checkoout of 3.19 branch as of today.
I attach the output of the `./configure` run and of the `make` run from today's git checkout of 3.19 branch.
Created attachment 2289 [details] Terminal output of the `./configure` run. ./configure \ --prefix=/usr \ --disable-static \ --enable-shared \ --enable-nls \ --enable-manual \ --enable-libsm \ --enable-ipv6 \ --enable-gnutls \ --enable-enchant \ --enable-crash-dialog \ --disable-generic-umpc \ --enable-compface \ --enable-pthread \ --enable-startup-notification \ --enable-dbus \ --enable-ldap \ --enable-jpilot \ --disable-networkmanager \ --enable-libetpan \ --disable-valgrind \ --disable-alternate-addressbook \ --enable-svg \ --enable-tests \ --enable-deprecated \ --enable-acpi_notifier-plugin \ --enable-address_keeper-plugin \ --enable-archive-plugin \ --enable-att_remover-plugin \ --enable-attachwarner-plugin \ --enable-bogofilter-plugin \ --enable-bsfilter-plugin \ --enable-clamd-plugin \ --enable-dillo-plugin \ --disable-fancy-plugin \ --enable-fetchinfo-plugin \ --enable-gdata-plugin \ --enable-libravatar-plugin \ --enable-litehtml_viewer-plugin \ --enable-mailmbox-plugin \ --enable-managesieve-plugin \ --enable-newmail-plugin \ --enable-notification-plugin \ --enable-pdf_viewer-plugin \ --enable-perl-plugin \ --enable-python-plugin \ --enable-pgpcore-plugin \ --enable-pgpmime-plugin \ --enable-pgpinline-plugin \ --enable-rssyl-plugin \ --enable-smime-plugin \ --enable-spamassassin-plugin \ --enable-spam_report-plugin \ --enable-tnef_parse-plugin \ --enable-vcalendar-plugin \ --enable-demo-plugin
Builds without problem here. Do you need a clean build directory? Try running `make maintainer-clean` before rebuilding. If you still have problems, re-open this and attach the `make` error msg. You have only attached the configure output, which is not very useful.
Created attachment 2290 [details] Terminal output of the `make` run.
> Do you need a clean build directory? Try running `make maintainer-clean` before rebuilding. I did a fresh git checkout.
.. and if I do not specify all the options, i.e. if I just do `./configure --prefix=/usr --enable-tests`, `make` runs fine.
Why do you use all those configure options? Most of them are not necessary: if the dependencies for the various features are present you do not need to specifically enable that feature.
> Why do you use all those configure options? To be sure to have that available, and to be thrown an error if some dependency is missing so I can add the dependency. And: For some plugins it seems I have to enable them manually. Since it is too confusing for me to know what needs to be enabled manually and what not, I jsut explicitly set what I want. Is that harmful? (I think it should not, why otherwise is the option there then?) Why is this important here? When you set all the options and have the dependencies installed, do you still get a compilation without error?
(In reply to linux.felixbecker2 from comment #9) > Is that harmful? (I think it should not, why otherwise is the option there then?) > Why is this important here? Harmful? hmmm. It makes it harder to narrow down when you are using the widest possible field. > When you set all the options and have the dependencies installed, do you still get a compilation without error? Yes.
(In reply to Paul from comment #10) After some disecting, I found out that for me the combination of `--disable-static` and `--enable-tests` triggers the compilation problem. If I leave out any of those two, compilation succeeds. After finding out, I confirmed for me by starting from a clean `git checkout` by the sequence of the following commands: ``` git clone git://git.claws-mail.org/claws.git claws-mail cd claws-mail git switch gtk2 NOCONFIGURE=1 ./autogen.sh ./configure --disable-static --enable-tests > /tmp/claws-mail.configure.log 2>&1 make > /tmp/claws-mail.make.log 2>&1 ``` I update the attached configure and make logs to the output of this latest run.
Created attachment 2293 [details] Terminal output of `./configure --disable-static --enable-tests`.
Created attachment 2294 [details] Terminal output of `make`.
I managed to reprduce the problem, with only --enable-tests. The simple, (and, at present, favoured), solution is to remove the tests.
> The simple, (and, at present, favoured), solution is to remove the tests. So it is not a build-side problem (i.e. my problem) if I explicitly use `--disable-static`? Wouldn't then the clean solution be to fix the issue instead of just removing the tests (excpet if no one is caring in keeping up with writing tests anyway), maybe leave this issue hanging around unresolved for a while until someone finds the capacity to do it?
fixed in git by removing the broken test.