X-Original-To: alpine-devel@lists.alpinelinux.org
Delivered-To: alpine-devel@mail.alpinelinux.org
Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by mail.alpinelinux.org (Postfix) with ESMTPS id 646A9DC0108
	for <alpine-devel@lists.alpinelinux.org>; Wed, 30 Oct 2013 09:14:18 +0000 (UTC)
Received: by mail-ee0-f42.google.com with SMTP id b45so610519eek.1
        for <alpine-devel@lists.alpinelinux.org>; Wed, 30 Oct 2013 02:14:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=sender:date:from:to:cc:subject:message-id:in-reply-to:references
         :mime-version:content-type:content-transfer-encoding;
        bh=A6Huvh3FQmMoAKtgRPlrPqmLNDwLY80t+TeuWUo5bZI=;
        b=gDmNQsMLMQZqt2MuVxz9EpVHzSK9BjhRQPd9um6f/yT6KVLVrj5y6f6a6Md5+j0NBE
         KhM9GdEQ7DlMJ36KGEUqOlH/dk1Uxhzz0A9dxjvwWoFuq+mRfwym5tmDW6ZqS4IWRiYU
         t3YNPcprDYSADhwlHsoNZXrGM8JVHXORKOoFigRy80421HqNQMwKJnk3lzi6GjwAEU9G
         s5OFdm7sxDMmDxXZaSlnEg6GZuQIiLsh5iU9QsMrhmOrq8o/EWPRamWk+tYT877ZJXWt
         q7hrtD1+Jvr3jUpp5pYgGJ+63ZYlo4rxbjroOSkBetHTMDL968dnfOyuVtIbI07zkpxM
         RY/w==
X-Received: by 10.14.216.136 with SMTP id g8mr1243748eep.61.1383124456909;
        Wed, 30 Oct 2013 02:14:16 -0700 (PDT)
Received: from vostro ([2001:1bc8:101:f402:21c:23ff:fefc:bf0b])
        by mx.google.com with ESMTPSA id m54sm81051396eex.2.2013.10.30.02.14.16
        for <multiple recipients>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 30 Oct 2013 02:14:16 -0700 (PDT)
Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Date: Wed, 30 Oct 2013 11:14:16 +0200
From: Timo Teras <timo.teras@iki.fi>
To: "Leslie P. Polzer | PORT ZERO" <polzer@port-zero.com>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: Cross-building (was: Re: [alpine-devel] musl and ARM in 2.7
 (and an introduction))
Message-ID: <20131030111416.3a993b49@vostro>
In-Reply-To: <526A6478.3080007@port-zero.com>
References: <5260F6C9.9000505@port-zero.com>
	<20131018131615.5286bb75@vostro>
	<526A6478.3080007@port-zero.com>
X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.20; i486-alpine-linux-uclibc)
X-Mailinglist: alpine-devel
Precedence: list
List-Id: Alpine Development <alpine-devel.lists.alpinelinux.org>
List-Unsubscribe: 
	<mailto:alpine-devel+unsubscribe@lists.alpinelinux.org?subject=unsubscribe>
List-Post: <mailto:alpine-devel@lists.alpinelinux.org>
List-Help: <mailto:alpine-devel+help@lists.alpinelinux.org?subject=help>
List-Subscribe: 
	<mailto:alpine-devel+subscribe@lists.alpinelinux.org?subject=subscribe>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 25 Oct 2013 14:30:48 +0200
"Leslie P. Polzer | PORT ZERO" <polzer@port-zero.com> wrote:

> On 10/18/2013 12:16 PM, Timo Teras wrote:
> 
> >> Also, is there an established way already of building Alpine based
> >> on musl and/or cross-compiling for ARM? It doesn't seem to be a big
> >> deal, but I'd like to know the efforts that have already been put
> >> into this so I'm not duplicating any work.
> > 
> > We've patched aports so that a minimal bootstrap system can be cross
> > compiled. All changes are in git already. And some minor notes +
> > links to the scripts I used to bootstrap musl builders are at my
> > wiki wall: http://wiki.alpinelinux.org/wiki/User:Fabled
> 
> That helped! I had to clear out some roadblocks, after which I now
> have a successful and reproducible bootstrap crossbuild of
> i486-alpine-linux-musl (without KERNEL_PKG and DEBUG_PKG so far; I
> simply haven't tried).

Very good!

> The problems I encountered, working with your scripts on current edge:
> 
> In createcross-toolchain.sh:
> 
> * I instructed abuild to clean up the musl build before installing
>   headers. This is necessary to prevent the patches from being applied
>   multiple times by the "prepare" step if you call the script more
>   than once.

Ah, right. I think this can be affected in abuild.conf - but it's good
to have it explicit.

> In abuild-crossbuild-x86.conf:
> 
> * CBUILD is no longer being set in /etc/abuild.conf (this was changed
>   pretty recently). This prevented gmp from being built correctly
>   (I think it just used the host setting for the build).
>   More packages might be affected by this.

Yes, I noticed this too.

> In crossbuild-alpine-bootstrap.sh:
> 
> * Set up the proper pkgconfig environment for the cross root.
>   Without this the relevant .pc files cannot be found. The first
>   package that broke in the ordered crossbuild because of this
>   was apk-tools.

And this too - I added this to x86_64.conf's earlier.

> * Added installation of all packages after they have been built.
>   This is a necessary step since later packages require files from
>   earlier ones. Also attempt to install $PKG-dev. Some packages need
>   special casing here since their -dev packages have a different
>   name. Maybe this should be fixed in the packages themselves.
>   The packages affected are gmp5 (gmp-dev) and mpfr3 (mpfr-dev).

Hmm - this worked for me without this. Though, I did have to fix some
makedepends in the aports. This was done not long ago.

> * Non-essential: also added per-package logging to cut down on the
> output.

Ok.

> I'm attaching a rough diff against your x86 conf files and the two
> scripts. Please let me know how you want to proceed with integrating
> these changes.

I need think what to do with the scripts. Might be an idea to bundle
them in abuild git tree. Even if they are not shipped in abuild.
Ultimately I would abuild to have "--target" and "--host" flags that
can be used to trigger the cross build so no additional "kludge" config
files would be needed.

> I wonder how we can test packages for their sanity properly after
> we have built them. The usual way is running the testsuite (make
> check) after compilation. Obviously this won't work when
> cross-compiling to a different machine architecture. Any ideas?

I don't think we plan to support cross-compiling all of aports. So this
would not be a goal for us.

I believe scratchbox etc. use statically built qemu-user, or some
binfmt_misc magic to launch the files on remote target. In either case
both will be "kludgy" and probably not doing 100% testing.

- Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---