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 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. Reverting systemd packaging commit 943053a2c2fd8b153545eb410101e0e3616d4de9 makes the issue go away. Can we revert it in Debian or find some other solution? Helmut
Am 13.01.2017 um 13:03 schrieb Helmut Grohne: We don't have a decent explanation what's going on so I'm wary of applying a workaround where nobody knows why it's needed. This smells like a bug in libtool.
Normally I would agree, but we are very near the freeze, so the time required to properly investigate the issue might well be longer than what is available to get to stretch, and thus stretch would release without being able to cross-build a core component to nios2 (and possibly other architectures). AFAIK, the fact that the real binary is in .libs/$program is an internal implementation detail of libtool and not a guaranteed interface, so it may well be possible (although unlikely) that different architectures differ in behavior. Given that the workaround in question lived for a relatively long time in unstable and caused no issues, I think the case for reverting is sound. This of course assumes that it is relevant to reach stretch with the cross-buildable component. If it is not, then I think investigating the root cause will be more fruitful. Indeed.
Control: tags -1 - moreinfo Adding moreinfo without asking a question doesn't make any sense. I agree with all of this, but I also ran out of things to try. The most valuable bit of information I have is that your patch broke it. Unless you have any other things in mind, the best thing we can do is (temporarily) revert. Still I am very much interested in finding the real cause. Given that you suspect libtool, I went ahead and looked at the linker invocation of test-udev for all architectures (in bootstrap builds). With two exceptions, all of them were storing the executable at .libs/test-udev. The two exceptions are nios2 and sparc. (I may have missed some architectures due to temporary failures.) Does this ring any bells? Anything else I can try? Helmut
Am 13.01.2017 um 19:28 schrieb Helmut Grohne: created. I thought this was obvious but I'm happy to spell it out.
(Adding libtool maintainers to CC). 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. 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? https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=943053a2c2fd8b153545eb410101e0e3616d4de9 for reference.
Control: reassign libtool Control: retitle -1 libtool misdetects nios2 as os2 Control: tags -1 = Control: affects -1 + src:systemd Identifying sparc here was just wrong. I looked through the logs and caught it wrongly. It really is just nios2. Looking closer at the log, it turns out that libtool is adding a -Wl,-rpath -Wl,$buildpath for nios2 and it shouldn't be doing that. While the reasons are not entirely clear, the cause was correctly guessed by Marek Vasut: Confusion with os2. The following patch made the problem go away: sed -i -e 's/\*os2\*/*-os2*/' /usr/share/libtool/build-aux/ltmain.sh All of the lines matched are case expressions and the change causes them to no longer match nios2. I'm not proposing it as is for inclusion into libtool, but merely showing it to demonstrate the cause and leave it up to Marek to produce a mergeable version. Helmut
I submitted a fix for that to GNU libtool almost two years ago ... https://lists.gnu.org/archive/html/bug-libtool/2015-09/msg00014.html
After the switch to meson, systemd now longer uses libtool, thus it is no longer affected by this issue.