Am 02.01.2015 um 23:00 schrieb Helmut Grohne:
> On Fri, Jan 02, 2015 at 09:24:14PM +0100, Sven Joachim wrote:
>> Am 02.01.2015 um 08:51 schrieb Helmut Grohne:
>> > [1] Technically, this means that the g++-multilib Build-Dependency is
>> > not satisfied. However, this dependency needs translation[2] in
>> > order to be useful for cross compilation. So not having gcc-multilib
>> > installed is morally valid. Just fixing Build-Depends is not yet
>> > feasible as gcc-for-host and friends are still in experimental.
>>
>> You still need libc(32|64)c-dev though, and the pesky /usr/include/asm
>> symlink shipped currently in gcc-multilib is also required. Without it,
>> I get this error in a native amd64 build:
>
> I confirm this observation and error in a cross build setting.
> Unfortunately, there currently is no part of the cross toolchain takes
> care of that /usr/include/asm link. I therefore treated
> cross-satisfiability of Build-Depends as a separate issue here. Using
> the correct compiler can (in principle) be applied right now, but
> suitable cross Build-Depends are currently unavailable in the archive. I
> intend to submit a patch for the Build-Depends when suitable packages
> become available.
>
> My reasoning here was that the patch is an incremental step to making
> ncurses fully cross-buildable. Even if it does not go the full road, it
> improves things without regressing other aspects (such as compatibility
> with older releases). So with this patch, those people who can
> reasonably interpret Build-Depends can actually cross build ncurses for
> multilib enabled architectures. This should soon appear on jenkins.d.n
> for sparc.
Okay, I have merged your patch into ncurses master now.
>> Maybe we should also set CC and CXX in the build-{32,64,wide-32}
>> targets, otherwise those targets will misbuild if somebody uses a custom
>> compiler (e.g. "debian/rules CC=clang build").
>
> I have no good answer to this question. As pointed out at
> https://wiki.debian.org/ReleaseGoals/honorCCandCXX, the goals of making
> packages cross-buildable and buildable with clang currently are in
> conflict somewhat. I currently err on the side that someone who passes
> CC to debian/rules should know what she is doing and that we should not
> prevent people from shooting themselves in the foot.
Well, building broken packages is still not nice, and I think I came up
with a reasonable way to avoid that. Here is what I did on top of your
patch:
>From a4db609cb22f0c4968170a8dc79b967ebcb9f8d8 Mon Sep 17 00:00:00 2001
From: Sven Joachim <svenj...@gmx.de>
Date: Sat, 3 Jan 2015 10:57:25 +0100
Subject: [PATCH] Ensure the right compiler in multilib builds
If the user specified a custom compiler, e.g. via
"dpkg-buildpackage CC=clang", this compiler would be used for the
multilib packages, missing the required -m32/-m64 flag and resulting
in broken packages.
Users who want to use their custom compiler also for the multilib
packages can do so by setting HOST_CC and HOST_CXX.
---
debian/rules | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/debian/rules b/debian/rules
index a707c13..a52135b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -294,11 +294,11 @@ build-static: $(objdir-static)/config.status
touch $@
build-32: $(objdir-32)/config.status
- cd $(objdir-32) && $(MAKE)
+ cd $(objdir-32) && $(MAKE) CC="$(HOST_CC) -m32" CXX="$(HOST_CXX) -m32"
touch $@
build-64: $(objdir-64)/config.status
- cd $(objdir-64) && $(MAKE)
+ cd $(objdir-64) && $(MAKE) CC="$(HOST_CC) -m64" CXX="$(HOST_CXX) -m64"
touch $@
build-debug: $(objdir-debug)/config.status
@@ -317,7 +317,7 @@ build-wide-static: $(wobjdir-static)/config.status
touch $@
build-wide-32: $(wobjdir-32)/config.status
- cd $(wobjdir-32) && $(MAKE)
+ cd $(wobjdir-32) && $(MAKE) CC="$(HOST_CC) -m32" CXX="$(HOST_CXX) -m32"
touch $@
build-wide-debug: $(wobjdir-debug)/config.status
--
2.1.4
Cheers,
Sven
