Bug#851253: bootstrap build failure: install: cannot stat 'build-deb/.libs/test-udev': No such file or directory

[Felipe Sateler]

(Adding libtool maintainers to CC).

On 13 January 2017 at 09:03, Helmut Grohne <helmut at subdivi.de> wrote:
> Source: systemd
> Version: 232-9
> User: helmutg at 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