(Adding libtool maintainers to CC). On 13 January 2017 at 09:03, Helmut Grohne <hel...@subdivi.de> wrote: > Source: systemd > Version: 232-9 > User: helm...@debian.org > Usertags: rebootstrap > > Since systemd 232-9 some architectures no longer bootstrap. An example > is nios2: > > https://jenkins.debian.net/job/rebootstrap_nios2_gcc6/56/consoleText: > | # ship test-udev, so that we have it for autopkgtests > | install -D build-deb/.libs/test-udev > debian/libudev-dev/usr/lib/nios2-linux-gnu/udev/test-udev > | install: cannot stat 'build-deb/.libs/test-udev': No such file or directory > | debian/rules:247: recipe for target 'override_dh_install' failed > | make[1]: Leaving directory '/tmp/buildd/systemd_1/systemd-232' > | make[1]: *** [override_dh_install] Error 1 > | debian/rules:366: recipe for target 'binary-arch' failed > | make: *** [binary-arch] Error 2 > | dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit > status 2
For libtool maintainers, what systemd is doing here is trying to copy test-udev (part of upstream's testsuite) into the package dir, to be able to run that on user systems in case udev breaks. > > The configuration is: > * DEB_BUILD_ARCH=amd64 > * DEB_HOST_ARCH=nios2 > * DEB_BUILD_OPTIONS=nocheck noddebs parallel=1 > * DEB_BUILD_PROFILES=nocheck noudeb stage1 > > In the full log, you can see that test-udev actually is being compiled. > > Simple native builds for single profiles stage1 or nocheck do not > exhibit the failure mode. test-udev links dynamically against libsystemd-shared, which is a utility library that contains many helper functions. On most architectures, this results in ./test-udev being a wrapper script that sets up the environment and runs the real executable from .libs/test-udev. However, it appears that on nios2 and sparc (cross-built from amd64), this is not true, and the real binary is stored in ./test-udev. So the question would be, why would libtool not follow the convention of placing the binary objects in .libs? Dear libtool maintainers, do you have any idea? > > Reverting systemd packaging commit > 943053a2c2fd8b153545eb410101e0e3616d4de9 makes the issue go away. https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=943053a2c2fd8b153545eb410101e0e3616d4de9 for reference. -- Saludos, Felipe Sateler
