checking for sendmail... /usr/sbin/sendmail checking for LIBCRYPTO... yes checking for openssl/bio.h... yes checking for openssl/conf.h... yes checking for openssl/crypto.h... yes checking for openssl/err.h... yes checking for openssl/evp.h... yes checking for openssl/md5.h... yes checking for openssl/opensslv.h... yes checking for openssl/pem.h... yes checking for openssl/rsa.h... yes checking for openssl/sha.h... yes checking for openssl/ssl.h... yes checking for library containing ERR_peek_error... none required checking for x86_64-pc-linux-gnu-gcc options needed to detect all undeclared functions... none needed checking whether SHA256_DIGEST_LENGTH is declared... yes checking for milter library and includes... checking for libmilter/mfapi.h... yes checking for library containing smfi_register... no configure: error: libmilter not found I do have libmilter installed: [ebuild R ] mail-filter/libmilter-1.0.2_p3-r1:0/1.0.2_p3::gentoo USE="ipv6 -poll" Reproducible: Always
Created attachment 799005 [details] config.log
Created attachment 799007 [details] build.log
I think the same issue was closed by accident in bug 862642. Maybe an API change that OpenDKIM wasn't ready for? I'll look into it.
The smfi_register() function is still present in the latest libmilter, so the easy answer isn't right.
Downgrading from mail-filter/libmilter-1.0.2_p3-r1 to mail-filter/libmilter-1.0.2_p2 allows opendkim to be emerged successfully and opendkim works.
At work, where I was when I made my previous comment: mjo@jumba ~ $ equery f libmilter * Searching for libmilter ... * Contents of mail-filter/libmilter-1.0.2_p3-r1: /usr /usr/include /usr/include/libmilter /usr/include/libmilter/mfapi.h /usr/include/libmilter/mfdef.h /usr/lib64 /usr/lib64/libmilter.so -> libmilter.so.1.0.2 /usr/lib64/libmilter.so.1.0.2 /usr/lib64/libmilter.so.1.0.2_p3 -> libmilter.so.1.0.2 /usr/share ... And at home, where I am now: mjo@gantu ~ $ equery f libmilter * Searching for libmilter ... * Contents of mail-filter/libmilter-1.0.2_p3-r1: /usr /usr/include /usr/include/libmilter /usr/include/libmilter/mfapi.h /usr/include/libmilter/mfdef.h /usr/lib64 /usr/lib64/libmilter.so -> libmilter.so.1.0.2 /usr/lib64/libmilter.so.1.0.2_p3 -> libmilter.so.1.0.2 /usr/share ... Somehow the actual library is missing from the latter.
Ok. I've tried this twice, meaning it happens every time, right? If I install JUST the stable libmilter and then upgrade it to the ~arch libmilter, it works normally. But if I have OpenDKIM installed and built against the stable libmilter and THEN upgrade libmilter, the library libmilter.so.1.0.2 vanishes. Can you confirm before I CC the libmilter/portage folks?
Notably, Debian uses a simpler patch for building libmilter: https://sources.debian.org/patches/sendmail/8.17.1.9-1/shared_libmilter.patch/. Perhaps we should try that. I remember either me or bman rebasing the original patch and finding it painful.
(In reply to Michael Orlitzky from comment #7) > Ok. I've tried this twice, meaning it happens every time, right? > > If I install JUST the stable libmilter and then upgrade it to the ~arch > libmilter, it works normally. But if I have OpenDKIM installed and built > against the stable libmilter and THEN upgrade libmilter, the library > libmilter.so.1.0.2 vanishes. > > Can you confirm before I CC the libmilter/portage folks? I can confirm those steps: 1. Install stable libmilter (1.0.2_p2) 2. Install opendkim (2.10.3-r29) 3. Upgrade libmilter to testing (1.0.2_p3-r1) 4. Install opendkim again (same version) For step (2) I get the following QA warning: * Messages for package mail-filter/opendkim-2.10.3-r29: * QA Notice: Unresolved soname dependencies: * * /usr/sbin/opendkim: libmilter.so.1.0.2_p2 which I'm not sure is significant or not. For step (3) I see this at the end: >>> Regenerating /etc/ld.so.cache... >>> Original instance of package unmerged safely. >>> mail-filter/libmilter-1.0.2_p3-r1 merged. >>> Regenerating /etc/ld.so.cache... <<< !needed obj /usr/lib64/libmilter.so.1.0.2 <<< !needed sym /usr/lib64/libmilter.so.1.0.2_p2 Trying to install opendkim again then gets the configure error "libmilter not found"
dev-portage@ it looks like we have an example where portage removes a just-installed library, thinking it's no longer needed? Steps to reproduce in comment 7 or comment 9. If this is expected behavior somehow, what should libmilter be doing to prevent it?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f67f7c6453fdd128489ea675935302099d66c1f5 commit f67f7c6453fdd128489ea675935302099d66c1f5 Author: Thomas Bracht Laumann Jespersen <t@laumann.xyz> AuthorDate: 2022-08-11 07:26:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-08-13 19:24:13 +0000 mail-filter/libmilter: fix symlink order The extra symlink setup in src_install would produce something like: libmilter.so -> libmilter.so.1.0.2 libmilter.so.1.0.2_p2 -> libmilter.so.1.0.2 but from reading ldconfig(8) it reads as if the links should go from least specific to most specific versions, so in a chain like this: libmilter.so -> libmilter.so.1.0.2 -> libmilter.so.1.0.2_p2 Swapping the shared object and symlink fixes the referenced bugs. Closes: https://bugs.gentoo.org/863455 Closes: https://bugs.gentoo.org/863407 Closes: https://bugs.gentoo.org/862642 Closes: https://bugs.gentoo.org/863578 Closes: https://bugs.gentoo.org/863575 Closes: https://bugs.gentoo.org/863572 Closes: https://bugs.gentoo.org/863581 Closes: https://bugs.gentoo.org/864563 Signed-off-by: Thomas Bracht Laumann Jespersen <t@laumann.xyz> Closes: https://github.com/gentoo/gentoo/pull/26819 Signed-off-by: Sam James <sam@gentoo.org> mail-filter/libmilter/libmilter-1.0.2_p2-r1.ebuild | 94 ++++++++++++++ mail-filter/libmilter/libmilter-1.0.2_p3-r2.ebuild | 136 +++++++++++++++++++++ 2 files changed, 230 insertions(+)
