Precedence: list
MIME-Version: 1.0
In-Reply-To: <155a8e57d76.f37920c130996.6728092923369604578@flatglobe.org>
References: <155a8e57d76.f37920c130996.6728092923369604578@flatglobe.org>
Date: Sat, 2 Jul 2016 22:41:20 -0700
Message-ID: <CAK4o1Ww77SRVoTP8kMcaHSHWhPwn+4oZ+F9SYF6vJ1xMk386qw@mail.gmail.com>
Subject: Re: [alpine-devel] Porting Alpine scripts
From: Justin Cormack <justin@specialbusservice.com>
To: "Tuan M. Hoang" <tmhoang@flatglobe.org>
Cc: Alpine Devel List <alpine-devel@lists.alpinelinux.org>
Content-Type: multipart/alternative; boundary=001a114beb247313eb0536b4ab3a

--001a114beb247313eb0536b4ab3a
Content-Type: text/plain; charset=UTF-8

I was not aware of a Musl s390x port, is there one?

Justin
On 1 Jul 2016 4:57 p.m., "Tuan M. Hoang" <tmhoang@flatglobe.org> wrote:

> Hi,
>
> I am trying to create a Docker image of Alpine targeting s390x
> architecture.
>
> Natanael suggested me Timo's previous work at :
> http://dev.alpinelinux.org/~tteras/bootstrap/ to bootstrap Alpine on new
> arch.
>
> I have 2 questions related to this, hope you could shed some light.
>
> Q1:
> Running createcross-toolchain.sh, at step 5, building gcc pass 2 :
> (experimenting with targeting x86)
>
>     $ ABUILD_CONF=$ABUILD_CREATECROSS_CONF BOOTSTRAP=nolibc
> CTARGET_LIBC=musl abuild -r || return 1
> (this makes sure --disable-shared is passed to configure script)
>
> Then at step 6, it introduces a conflict between host's gcc and newly
> installed/built gcc-pass2-$CTARGET
>
> ERROR: unsatisfiable constraints:
>     gcc-5.3.0-r0:
>         conflicts:
> gcc-pass2-i486-alpine-linux-musl-5.2.0-r0[so:libcc1.so.0=0.0.0]
>         satisfies: g++-5.3.0-r0[gcc=5.3.0-r0] build-base-0.4-r1[gcc]
>     gcc-pass2-i486-alpine-linux-musl-5.2.0-r0:
>         conflicts: gcc-5.3.0-r0[so:libcc1.so.0=0.0.0]
>         satisfies: world[gcc-pass2-i486-alpine-linux-musl]
>
> How could I solve this? Should I build gcc-pass-2 with different prefix
> than /usr/ to avoid conflict dynamic libs? If I do so, will it be any
> different than a manually/traditionally built cross-toolchain ? (mentioned
> below)
>
>
> Q2:
> I have built a cross toolchains targeting s390x (gcc, musl, binutils,
> busybox, apk-tools), based on Gregor Richards's musl-cross with some
> patches.
> If I specifies this cross toolchains in the crossbuild-alpine-bootstrap.sh
> , rather than doing
>     ${SUDO_APK} --repository $REPODEST_HOST/main add gcc-$CTARGET
> g++-$CTARGET gcc-gnat-$CTARGET || return 1
>
> then will there be any differences ? I have not try this (havent have
> cross-built gnat yet) and just want to know what you think about it.
>
> Thank you,
> Tuan
>
>
>
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>
>

--001a114beb247313eb0536b4ab3a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I was not aware of a Musl s390x port, is there one?</p>
<p dir=3D"ltr">Justin<br>
</p>
<div class=3D"gmail_quote">On 1 Jul 2016 4:57 p.m., &quot;Tuan M. Hoang&quo=
t; &lt;<a href=3D"mailto:tmhoang@flatglobe.org">tmhoang@flatglobe.org</a>&g=
t; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I am trying to create a Docker image of Alpine targeting s390x architecture=
.<br>
<br>
Natanael suggested me Timo&#39;s previous work at : <a href=3D"http://dev.a=
lpinelinux.org/~tteras/bootstrap/" rel=3D"noreferrer" target=3D"_blank">htt=
p://dev.alpinelinux.org/~tteras/bootstrap/</a> to bootstrap Alpine on new a=
rch.<br>
<br>
I have 2 questions related to this, hope you could shed some light.<br>
<br>
Q1:<br>
Running createcross-toolchain.sh, at step 5, building gcc pass 2 : (experim=
enting with targeting x86)<br>
<br>
=C2=A0 =C2=A0 $ ABUILD_CONF=3D$ABUILD_CREATECROSS_CONF BOOTSTRAP=3Dnolibc C=
TARGET_LIBC=3Dmusl abuild -r || return 1<br>
(this makes sure --disable-shared is passed to configure script)<br>
<br>
Then at step 6, it introduces a conflict between host&#39;s gcc and newly i=
nstalled/built gcc-pass2-$CTARGET<br>
<br>
ERROR: unsatisfiable constraints:<br>
=C2=A0 =C2=A0 gcc-5.3.0-r0:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 conflicts: gcc-pass2-i486-alpine-linux-musl-5.2=
.0-r0[so:libcc1.so.0=3D0.0.0]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 satisfies: g++-5.3.0-r0[gcc=3D5.3.0-r0] build-b=
ase-0.4-r1[gcc]<br>
=C2=A0 =C2=A0 gcc-pass2-i486-alpine-linux-musl-5.2.0-r0:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 conflicts: gcc-5.3.0-r0[so:libcc1.so.0=3D0.0.0]=
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 satisfies: world[gcc-pass2-i486-alpine-linux-mu=
sl]<br>
<br>
How could I solve this? Should I build gcc-pass-2 with different prefix tha=
n /usr/ to avoid conflict dynamic libs? If I do so, will it be any differen=
t than a manually/traditionally built cross-toolchain ? (mentioned below)<b=
r>
<br>
<br>
Q2:<br>
I have built a cross toolchains targeting s390x (gcc, musl, binutils, busyb=
ox, apk-tools), based on Gregor Richards&#39;s musl-cross with some patches=
.<br>
If I specifies this cross toolchains in the crossbuild-alpine-bootstrap.sh =
, rather than doing<br>
=C2=A0 =C2=A0 ${SUDO_APK} --repository $REPODEST_HOST/main add gcc-$CTARGET=
 g++-$CTARGET gcc-gnat-$CTARGET || return 1<br>
<br>
then will there be any differences ? I have not try this (havent have cross=
-built gnat yet) and just want to know what you think about it.<br>
<br>
Thank you,<br>
Tuan<br>
<br>
<br>
<br>
---<br>
Unsubscribe:=C2=A0 <a href=3D"mailto:alpine-devel%2Bunsubscribe@lists.alpin=
elinux.org">alpine-devel+unsubscribe@lists.alpinelinux.org</a><br>
Help:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:alpine-devel%2Bhel=
p@lists.alpinelinux.org">alpine-devel+help@lists.alpinelinux.org</a><br>
---<br>
<br>
</blockquote></div>

--001a114beb247313eb0536b4ab3a--


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---