[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#818873: gcc-5-cross: FTBFS when built with dpkg-buildpackage -A (No such file or directory)



Followup-For: Bug #818873

Hi,

in https://buildd.debian.org/status/fetch.php?pkg=gcc-5-cross&arch=all&ver=21&stamp=1462410260 the failing command is 

DEB_HOST_ARCH=s390x ARCH=s390x MAKEFLAGS="CC=something" dh_shlibdeps -plibgnat-5-s390x-cross \
	-l/lib/s390x-linux-gnu:/usr/lib/s390x-linux-gnu:/s390x-linux-gnu/lib:/usr/s390x-linux-gnu/lib:/«PKGBUILDDIR»/gcc/debian/tmp/usr/s390x-linux-gnu/lib:/«PKGBUILDDIR»/gcc/debian/tmp/usr/s390x-linux-gnu/lib
dpkg-shlibdeps: error: no dependency information found for /«PKGBUILDDIR»/gcc/debian/tmp/usr/s390x-linux-gnu/lib/libgcc_s.so.1 (used by debian/libgnat-5-s390x-cross/usr/s390x-linux-gnu/lib/libgnarl-5.so.1)
Hint: check if the library actually comes from a package.
dh_shlibdeps: dpkg-shlibdeps -Tdebian/libgnat-5-s390x-cross.substvars -l/lib/s390x-linux-gnu -l/usr/lib/s390x-linux-gnu -l/s390x-linux-gnu/lib -l/usr/s390x-linux-gnu/lib -l/«PKGBUILDDIR»/gcc/debian/tmp/usr/s390x-linux-gnu/lib -l/«PKGBUILDDIR»/gcc/debian/tmp/usr/s390x-linux-gnu/lib debian/libgnat-5-s390x-cross/usr/s390x-linux-gnu/lib/libgnat-5.so.1 debian/libgnat-5-s390x-cross/usr/s390x-linux-gnu/lib/libgnarl-5.so.1 returned exit code 2

That's actually in the gcc source code being built by gcc-5-cross.
This call looks correct and there is also a
/usr/s390x-linux-gnu/lib/libgcc_s.so.1 available.
But if you dig into dpkg-shlibdeps source code, you see that the -l option
works rather counterintuitive. The -l paths get prepended to the list of
(default) search paths one-by-one, so that the last -l option gets actually
searched first.

I'm not sure who should be blamed here: dpkg, debhelper or gcc.
Neither dpkg-shlibdeps nor dh_shlibdeps document anything about the order
in their manpages.
Why is /«PKGBUILDDIR»/gcc/debian/tmp/usr/s390x-linux-gnu/lib included in
the search path anyway? AIUI if some library can (only) be satisfied from
there, dpkg-shlibdeps will always fail.

I could reproduce this in a sid/amd64 for an arch-indep build. (didn't verify
what is different in a full arch+indep build since this seems to take extremely
long). Changing the search path order lets this command succeed.


Andreas


Reply to: