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
