FTCBFS: Cross build calls wrong-arch strip

Bug #962997 reported by Marcin Juszkiewicz
This bug affects 1 person
Affects Status Importance Assigned to Milestone
debianutils (Debian)
Fix Released
debianutils (Ubuntu)

Bug Description

Debianutils does not call the correct arch strip so cross-builds fail right at the end.

See build log at: http://people.linaro.org/~wookey/buildd/precise/sbuild-ma/debianutils_4.2.1ubuntu1-precise-ma-cross-armel-20120322-023654.34137.log

The attached patch fixes that.

Revision history for this message
Marcin Juszkiewicz (hrw) wrote :
Revision history for this message
Colin Watson (cjwatson) wrote :

Looks good to me.

Revision history for this message
Colin Watson (cjwatson) wrote :

I made a slight amendment for upload: I just set CROSS to the empty string rather than "" (which ends up as literally "" and is folded away by the shell later). Updated patch attached.

Could you please forward this patch to the Debian BTS?

Changed in debianutils (Ubuntu):
status: New → Fix Committed
Revision history for this message
Colin Watson (cjwatson) wrote :

Uploaded, although it may well be held until after the Beta 2 freeze.

Revision history for this message
Wookey (wookey) wrote :

I don't actually understand why this works. I fixed it slightly differently by explicitly setting $STRIP.

If just setting $CROSS is enough to fix this, how many other things can be fixed by setting $CROSS? What exactly is the scope of this - does it only work in binutils or does it have wider application? I tried reading the autconf manula and it didn't seem to say anything about this. How is setting $CROSS different from setting --host?

Is there any reason to prefer one of these fixes over the other? Marcin's is shorter, mine is a bit clearer?

Is cross-auto-foo best practice actually written down anywhere?

diff -ur origs/debianutils-4.2.2/debian/rules patched/debianutils-4.2.2/debian/rules
--- origs/debianutils-4.2.2/debian/rules 2012-03-24 14:52:38.000000000 +0000
+++ patched/debianutils-4.2.2/debian/rules 2012-03-27 11:46:21.000000000 +0000
@@ -12,8 +12,12 @@
 DEB_BUILD_ARCH_OS ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)
 DEB_BUILD_GNU_TYPE = $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_HOST_GNU_TYPE = $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)

 CFLAGS := $(shell dpkg-buildflags --get CFLAGS)
@@ -63,7 +67,7 @@

 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
- strip --remove-section=.comment --remove-section=.note \
+ $(STRIP) --remove-section=.comment --remove-section=.note \
                debian/tmp/bin/run-parts \
                debian/tmp/bin/tempfile \

Revision history for this message
Marcin Juszkiewicz (hrw) wrote :

I think that version with just $(STRIP) is cleaner. I based my change on diffutils one that's why $(CROSS)

Revision history for this message
Wookey (wookey) wrote :

OK, this doesn't work how I thought it did. Neither $CROSS nor $STRIP are special and don't relate to the STRIP=foo set in Makefile. autoconf got that right all by itself (presumably from --host). The issue is that debian/rules wants to be able to say 'use the STRIP defined in Makefile'. Is there a way to do that? It seems that this would be more robust than generating our own version of the same thing (as "$(DEB_HOST_GNU_TYPE)-strip") . We get some of these variables: ($(MAKE), $(RM)), but not $(STRIP) .

I've just failed to find a neat way to extract this info that isn't uglier than just generating it again ourselves. Which seems a pity.

OK it all makes sense now anyway. As you were. I'll forward the bug to Debian.

Changed in debianutils (Debian):
status: Unknown → New
Changed in debianutils (Debian):
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package debianutils - 4.2.1ubuntu2

debianutils (4.2.1ubuntu2) precise; urgency=low

  * Ensure correct strip is called when cross-building (LP: #962997)
 -- Marcin Juszkiewicz <email address hidden> Fri, 23 Mar 2012 12:21:47 +0100

Changed in debianutils (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.