https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: mail-filter/opendkim-2.10.3-r18 fails to compile. Discovered on: amd64 (internal ref: tinderbox) NOTE: This machine uses a gold linker (ld.gold). If you think that this issue is strictly related to ld.gold please block bug 269315.
Created attachment 668585 [details] build.log build log and emerge --info
Possible context of error(s): /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold: error: cannot open /usr/lib/libdb.so: No such file or directory opendkim-opendkim-db.o:opendkim-db.c:function dkimf_db_open: error: undefined reference to 'db_create' opendkim-opendkim-db.o:opendkim-db.c:function dkimf_db_open: error: undefined reference to 'db_strerror' opendkim-opendkim-db.o:opendkim-db.c:function dkimf_db_strerror: error: undefined reference to 'db_strerror' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold: error: cannot open /usr/lib/libdb.so: No such file or directory
Looks like the linker cannot find libdb.so although USE=berkdb was specified and the ebuild contains the dependency berkdb? ( >=sys-libs/db-3.2:* ) On my machine (profile: amd64/17.1/no-multilib) the necessary library is provided by sys-libs/db-5.3.28-r4: # equery belongs /usr/lib64/libdb-5.3.so * Searching for /usr/lib64/libdb-5.3.so ... sys-libs/db-5.3.28-r4 (/usr/lib64/libdb-5.3.so)
can you try with gold? That's the big difference here, as stated in comment 0
Isn't that a problem with the linker path? > libtool: link: x86_64-pc-linux-gnu-gcc -pthread -O2 -pipe -march=native -frecord-gcc-switches -fno-diagnostics-color -pthread -Wl,-O1 -Wl,--defsym=__gentoo_check_ldflags__=0 -fuse-ld=gold -o .libs/opendkim opendkim-opendkim.o opendkim-opendkim-ar.o opendkim-opendkim-arf.o opendkim-opendkim-crypto.o opendkim-opendkim-db.o opendkim-opendkim-dns.o opendkim-opendkim-lua.o opendkim-config.o opendkim-flowrate.o opendkim-reputation.o opendkim-stats.o opendkim-test.o opendkim-util.o -L/usr/lib -L/usr/local/BerkeleyDB/lib -Wl,--as-needed ../libopendkim/.libs/libopendkim.so -lmilter -lssl -lcrypto -ldb ../libvbr/.libs/libvbr.so -lresolv -lbsd -pthread -L/usr/lib, which will fail on 64-bit and gold, a classic :P It should be look from where does -L/usr/lib come from. This could be also from another included lib.
Created attachment 668771 [details] Successful build (Gentoo VM with ld.gold)
I still cannot reproduce the build error. Builds with both ld.bfd and ld.gold succeed on my test VM.
Reported upstream at $URL. Junk -L<foo> flags can get added throughout configure.ac, since the tests all assume that *something* has to be appended to the library search path, and that's generally not the case.
Thank you, Michael. Based on your work, I suggest to close this issue as RESOLVED/UPSTREAM.
I'll eventually add the patch to our pile of existing patches in Gentoo, if for no other reason than to convince upstream (and myself) that it works. I've just been reluctant to rock the boat lately because my time to fix things is limited if I break them.
I understand. I hope you won't mind me assigning this issue to you, then.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8e5aca07ddfbd0e6578698a24390b006897e941a commit 8e5aca07ddfbd0e6578698a24390b006897e941a Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2020-12-09 13:37:45 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2020-12-09 15:01:46 +0000 mail-filter/opendkim: new revision to fix lib/lib64 mixup. Includes a patch that I've sent upstream to prevent ./configure from "detecting" /usr/lib as the correct library path when -lfoo works regardless of whether or not you're looking in /usr/lib. Closes: https://bugs.gentoo.org/751286 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> .../opendkim-2.10.3-fix-libmilter-search.patch | 223 +++++++++++++++++++++ ....10.3-r18.ebuild => opendkim-2.10.3-r19.ebuild} | 2 + 2 files changed, 225 insertions(+)
