Summary: | >=net-dns/bind-9.11.2_p1 - /usr/lib/libdb-5.3.so: error adding symbols: File in wrong format | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Leonid Kopylov <leonchik1976> |
Component: | Current packages | Assignee: | Christian Ruppert (idl0r) <idl0r> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | 0xe2.0x9a.0x9b, jstein, Tanktalus, zlogene |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=646340 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
Patch for absolute -L/usr/lib path in dlz LDAP configure code Add dependencies and configure patches to ebuild Patch autotool macro to help find 64-bit OpenSSL library Patch for bind-9.14.4.ebuild applying above patches |
Description
Leonid Kopylov
2018-02-02 05:28:35 UTC
Created attachment 517528 [details]
build.log
I got a similar error with net-dns/bind-9.12.1. It seems that libtool want to link amd64 binaries with /usr/lib/libdb-5.3.so, but not /usr/lib64/lib-5.3.so. Probably configure scripts of net-dns/bind would be incorrect but not sure. I currently have bind always linking to libdb-5.3.so, leading to
!!! existing preserved libs:
>>> package: sys-libs/db-5.3.28-r3
* - /usr/lib64/libdb-5.3.so
* used by /usr/sbin/named (net-dns/bind-9.12.2_p1)
but no @revdep-rebuild ever fixes this.
named seems to link against libdb-5.3.so but there is no such dependency specified in (R)DEPEND $ objdump -x /usr/sbin/named /usr/sbin/named: file format elf64-x86-64 /usr/sbin/named architecture: i386:x86-64, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x00000000000221f0 Program Header: PHDR off 0x0000000000000040 vaddr 0x0000000000000040 paddr 0x0000000000000040 align 2**3 filesz 0x0000000000000268 memsz 0x0000000000000268 flags r-- INTERP off 0x00000000000002a8 vaddr 0x00000000000002a8 paddr 0x00000000000002a8 align 2**0 filesz 0x000000000000001c memsz 0x000000000000001c flags r-- LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12 filesz 0x0000000000011a20 memsz 0x0000000000011a20 flags r-- LOAD off 0x0000000000012000 vaddr 0x0000000000012000 paddr 0x0000000000012000 align 2**12 filesz 0x000000000004a18d memsz 0x000000000004a18d flags r-x LOAD off 0x000000000005d000 vaddr 0x000000000005d000 paddr 0x000000000005d000 align 2**12 filesz 0x0000000000015f50 memsz 0x0000000000015f50 flags r-- LOAD off 0x0000000000073ad0 vaddr 0x0000000000074ad0 paddr 0x0000000000074ad0 align 2**12 filesz 0x000000000000b600 memsz 0x0000000000011d50 flags rw- DYNAMIC off 0x0000000000073b70 vaddr 0x0000000000074b70 paddr 0x0000000000074b70 align 2**3 filesz 0x00000000000002c0 memsz 0x00000000000002c0 flags rw- NOTE off 0x00000000000002c4 vaddr 0x00000000000002c4 paddr 0x00000000000002c4 align 2**2 filesz 0x0000000000000020 memsz 0x0000000000000020 flags r-- EH_FRAME off 0x000000000006cd08 vaddr 0x000000000006cd08 paddr 0x000000000006cd08 align 2**2 filesz 0x0000000000000a6c memsz 0x0000000000000a6c flags r-- STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**4 filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw- RELRO off 0x0000000000073ad0 vaddr 0x0000000000074ad0 paddr 0x0000000000074ad0 align 2**0 filesz 0x0000000000000530 memsz 0x0000000000000530 flags r-- Dynamic Section: NEEDED libns.so.1203 NEEDED libdns.so.1205 NEEDED libbind9.so.1200 NEEDED libisccfg.so.1200 NEEDED libisccc.so.1200 NEEDED libisc.so.1200 NEEDED libcrypto.so.1.0.0 NEEDED libdb-5.3.so NEEDED libldap-2.4.so.2 NEEDED libcap.so.2 NEEDED libpthread.so.0 NEEDED libxml2.so.2 NEEDED libz.so.1 NEEDED libdl.so.2 NEEDED libc.so.6 INIT 0x0000000000012000 FINI 0x000000000005c184 INIT_ARRAY 0x0000000000074ad0 INIT_ARRAYSZ 0x0000000000000008 FINI_ARRAY 0x0000000000074ad8 FINI_ARRAYSZ 0x0000000000000008 GNU_HASH 0x00000000000002e8 STRTAB 0x0000000000005ce0 SYMTAB 0x00000000000003b8 STRSZ 0x00000000000046ed SYMENT 0x0000000000000018 DEBUG 0x0000000000000000 PLTGOT 0x0000000000075000 PLTRELSZ 0x0000000000005358 PLTREL 0x0000000000000007 JMPREL 0x000000000000c6c8 RELA 0x000000000000ac40 RELASZ 0x0000000000001a88 RELAENT 0x0000000000000018 FLAGS_1 0x0000000008000000 VERNEED 0x000000000000ab40 VERNEEDNUM 0x0000000000000005 VERSYM 0x000000000000a3ce RELACOUNT 0x00000000000000e3 These are the versions of db that I have currently installed (4.8.30-r2 and 6.0.35-r1) $ eix -e db [I] sys-libs/db Available versions: (1) 1.85-r3 (3) 3.2.9_p2 (4.2) 4.2.52_p5-r1 (4.3) 4.3.29_p1-r1 (4.4) (~)4.4.20_p4-r1 (4.5) 4.5.20_p2-r1 (4.6) 4.6.21_p4 (4.7) 4.7.25_p4 (4.8) 4.8.30-r2{tbz2} (5.1) (~)5.1.29-r1 (5.3) 5.3.28-r2 (~)5.3.28-r3 (6.0) (~)6.0.35 (~)6.0.35-r1{tbz2} (6.1) [M](~)6.1.29 [M](~)6.1.29-r1 (6.2) [M](~)6.2.23 [M](~)6.2.23-r1 [M](~)6.2.32 [M](~)6.2.32-r1 {cxx doc examples java rpc tcl test ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32" ELIBC="FreeBSD"} Installed versions: 4.8.30-r2(4.8){tbz2}(20:38:49 29/07/18)(cxx -doc -examples -java -tcl -test ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="32 64 -x32" ELIBC="-FreeBSD") 6.0.35-r1(6.0){tbz2}(20:34:52 29/07/18)(cxx -doc -examples -java -tcl -test ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="32 64 -x32" ELIBC="-FreeBSD") Homepage: http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/overview/index.html Description: Oracle Berkeley DB I am having a similar problem (wrong file type for libdb-5.3.so). I can work around it by emerging with the following USE flags (it fails if the ldap USE flag set): berkdb caps dlz doc ipv6 python ssl threads xml zlib -dnsrps -dnstap -fixed-rrset -geoip -gost -gssapi -json -ldap -libressl -lmdb -mysql -odbc -postgres -rpz -seccomp -selinux -static-libs -urandom I was able to develop a patch that fixes the LDAP problem for me. It is a bit of a hack because I am not very familiar with autoconf, and it appears that bind is pretty out-of-date with that, too. I will try to add my patch shortly. Here is how the problem occurs on my system: Package with relevant USE flags: net-dns/bind-9.12.3_p4 +berkdb +dlz +ldap I recently switched to profile 17.1, so SYMLINK_LIB is now set to 'no'. For me, the bug is triggered by having 32-bit libraries in /usr/lib/, and 64-bit libraries in /usr/lib64/ (plus the combination of relevant USE flags mentioned above). If the dlz and ldap USE flags are enabled, then the bind configure script will search for the LDAP libraries in the directories specified at contrib/dlz/contrib.dlz.in:374. /usr is in the list, and it appends /lib to that, not /lib64. It adds the -L/usr/lib to the library list. The libtool script has code that searches for libtool libraries using a search path that includes any paths specified with -L. If it finds a -l flag pointing at a libtool library, it replaces the -l flag with an absolute path to the library. When parsing the -ldb flag (resulting from the +berkdb USE flag), it finds /usr/lib/libdb-5.3.la. Using that, it replaces -ldb with /usr/lib/libdb-5.3.so. This is the 32-bit library; the 64-bit library is /usr/lib64/libdb-5.3.so. Having -L/usr/lib in the search path is what produces the ``skipping incompatible /usr/lib/*.so when searching for -l*''-type warnings seen in Leonid Kopylov's build log, but it is the one libtool-ized library, libdb, that has the full path specified as a result and so that is the one that triggers the wrong-format error. On my system, compiling with USE=-ldap works, but USE=ldap fails. Scanning through contrib/dlz/contrib.dlz.in, it looks like various other USE flags (postgres, mysql, and odbc) have other tests that will not add -L/usr/lib under normal circumstances and so, I think, will not trigger the problem. Created attachment 580148 [details, diff]
Patch for absolute -L/usr/lib path in dlz LDAP configure code
As described above, when compiling with 32-bit libraries in /usr/lib/ and 64-bit libraries in /usr/lib64/ and USE='+berkdb +dlz +ldap', the configure script searches a hardcoded /usr/lib/ for an LDAP library, finds it, and adds -L/usr/lib to the linker flags. This causes libtool to find /usr/lib/libdb-5.3.la and end up replacing -ldb with /usr/lib/libdb-5.3.so in the linker command, which is a 32-bit library. If the build is 64-bit, this fails.
This patch attempts to fix the issue by adding some extra code to the configure tests trying to find the LDAP library, using some of the searches for other libraries (specifically, libdb) as a template. The library search is similar, but it first just tries -lldap to see if that works (the configure script should already be passed --with-libs=/usr/lib64, so that path should be searched). If that works, then the linker will simply be passed -lldap without any -L flags that could mislead the libtool script.
I can confirm similar behavior. I just upgraded profile from 17.0 to 17.1 and after this BIND won't compile with the same issues, trying to link to the wrong library. Similar problem here, but the complaining library is libcrypto instead of libdb. See https://forums.gentoo.org/viewtopic-t-1100294.html for my details. Created attachment 585962 [details, diff] Add dependencies and configure patches to ebuild I agree with Kobboi (comment #4). The configure scripts link to libdb when --with-dlz-bdb is enabled, which happens with the berkdb USE flag is specified. I think the following atom should be added to the DEPEND variable in the ebuild: berkdb? ( sys-libs/db ) I am attaching the patch for the ebuild that I am currently using, in case it helps somebody (it references the configure patch I added earlier). Created attachment 586404 [details, diff]
Patch autotool macro to help find 64-bit OpenSSL library
net-dns/bind-9.14.4 appears to have some extra macros with hardcoded paths. These can trigger the same bug where they specify -L/usr/lib on the linker line, causing the libtool script to search that path for libtool files. If linking with libdb, which may have such a libtool file, the libtool script replaces -ldb with the path to libdb in /usr/lib. If that is a 32-bit library on a 64-bit build, this causes linking to fail. The -L/usr/lib also causes warnings about skipping 32-bit libraries for other libraries.
I am attaching a patch that helps circumvent that by copying a block that uses pkg-config to find the library where it can, bypassing the hardcoded paths and the addition of a -L flag. I am not familiar enough with autotools to know what a more permanent fix would look like, but it seems unlikely that simply modifying the hardcoded search path is the way to go.
Created attachment 586406 [details, diff]
Patch for bind-9.14.4.ebuild applying above patches
The two fixes developed for net-dns/bind-9.12.3 appear to still be applicable to net-dns/bind-9.14.4. This patch modifies the net-dns/bind-9.14.4 ebuild script to include sys-libs/db in the DEPEND variable when emerging with USE=berkdb, and applies the dlz configure script patches to work around the hardcoded paths that tend to point at 32-bit libraries on SYMLINK_LIB=no multilib systems.
This patch also applies a second patch for an autotool macro that was not present in net-dns/bind-9.12.3, also attempting to bypass hardcoded paths that sometimes point to 32-bit libraries in a 64-bit build.
Finally, the patch removes specifying a particular OpenSSL root path to the configure script. This is to prevent it from conflicting with the second patch that uses pkg-config to find the library, but I am worried I am reverting some change that was introduced to fix some other bug. If this breaks something for somebody, I would appreciate hearing about it.
*** Bug 691680 has been marked as a duplicate of this bug. *** Yaking into account number of hardcoded libdirs I guess something like `export LDFLAGS="${LDFLAGS} -L${EPREFIX}/usr/$(get_libsir)"` must work, if something does not happen automagically. (In reply to Mikle Kolyada from comment #14) > Yaking into account number of hardcoded libdirs I guess something like > > `export LDFLAGS="${LDFLAGS} -L${EPREFIX}/usr/$(get_libsir)"` must work, if > something does not happen automagically. Commited. Lets see if this is enough. (In reply to Mikle Kolyada from comment #15) > (In reply to Mikle Kolyada from comment #14) > > Yaking into account number of hardcoded libdirs I guess something like > > > > `export LDFLAGS="${LDFLAGS} -L${EPREFIX}/usr/$(get_libsir)"` must work, if > > something does not happen automagically. > > Commited. Lets see if this is enough. Sorry for the delay. I have been unavailable for a while. This appears to work for me. My bind-9.14.4 has my patch included, which works. I tried installing bind-9.14.5 (which does not have my patch, but is currently marked unstable) as-is, and that succeeded. I tried removing the LDFLAGS line mentioned above from bind-9.14.5.ebuild, and the compile failed with the usual error (``error adding symbols: File in wrong format.''). This suggests that that one line does fix the problem. I compared logs, and the LDFLAGS line also gets rid of the ``skipping incompatible ...'' warnings. I was skeptical that this would work since a script is manually inserting the wrong path to the libdb library, but it does so by searching the -L directories. The configure script and its hardcoded paths is still adding the incorrect -L/usr/lib, but with the LDFLAGS line in the ebuild, the command has the correct -L/usr/lib64 BEFORE the incorrect -L/usr/lib, so the script sets the correct libdb path. Despite the incorrect -L on the command line, I think this LDFLAGS fix is cleaner and more generally applicable than my patch. Thanks. |