Hi Bernhard, On Fri, Nov 15, 2019 at 04:53:28PM +0100, Bernhard Übelacker wrote: > Dear Maintainer, > I tried to find out what happens and I think it is > related to the changes from #928467. > Because of these the configure script searches now > for libdb-5.3.a in directory /usr/lib/i686-linux-gnu > (in configure "$dir/lib/${host_cpu}-${host_os}"). > > Unfortunately that library lives in /usr/lib/i386-linux-gnu. > > Changing in debian/rules the --host and --build arguments > to DEB_..._MULTIARCH would make the package build in i386, > but I cannot say if that would defeat the whole purpose > of the change in #928467, therefore I hope its ok CCing > to Helmut Grohne.
Thank you for contacting me. Using DEB_*_MULTIARCH is technically wrong for autotools. Doing so will break cross building to i386 as we don't ship cross tools prefixed with DEB_HOST_MULTIARCH. What the berkelydb check does is unportable and buggy. Its source is in acinclude.m4 and the macro is called SFS_TRY_SLEEPYCAT_VERSION. It roughly goes: acinclude.m4:1201: | for vdir in "$dir/lib/db$catvers" "$dir/lib/db$majvers" \ | "$dir/lib/db" "$dir/lib" "$dir/lib64" \ | "$dir/lib/${host_cpu}-${host_os}" \ | "$dir/"`basename "$libdir"` ... test -f $vdir/libdb.la This is the wrong way to search for libraries. It's unportable. It doesn't consider the search paths used by the designated compiler. It breaks when used with sysroots (not a problem with Debian, but it breaks yocto and ptxdist). There is AC_CHECK_LIB for a reason. Using that will make the code much shorter and portable and it'll work. If upstream insists on not using AC_CHECK_LIB, you can extract the search directories from gcc: $CC --print-search-dirs | sed 's/^libraries: =//;ta;d;:a s/:/ /g' This also isn't portable, but it works with gcc and clang and you can simply add the resulting directories to the ones iterated above. While using DEB_*_MULTIARCH is technically wrong, I guess that it mostly works in practice. The only architecture where DEB_*_GNU_TYPE and DEB_*_MULTIARCH make a difference is i386 (well and kfreebsd-i386 and some other variants). You say that these build natively. I guess that few people cross build mailavenger to i386. So that's likely still better than FTBFS. #928467 was about confusing build/host, not about gnu_type/multiarch, but my patch happend to change both. Please do try AC_CHECK_LIB though as it is better on basically any axis. Helmut