Mail archive
alpine-devel

Re: [alpine-devel] Porting Alpine scripts

From: Timo Teras <timo.teras_at_iki.fi>
Date: Fri, 22 Jul 2016 08:45:14 +0300

On Fri, 22 Jul 2016 06:14:42 +0700
"Tuan M. Hoang" <tmhoang_at_flatglobe.org> wrote:

> ---- On Mon, 18 Jul 2016 12:40:38 +0700 Timo Teras
> <timo.teras_at_iki.fi> wrote ----
>
> > Usually it is configured in /etc/abuild.conf, and that's what my
> > scripts expect. E.g. my abuild-crossbuild-armv7.conf has:
> > # inherit CBUILD, and other basic defines
> > source /etc/abuild.conf
> >
> > It expects CBUILD=<system triplet> to be in /etc/abuild.conf.
> >
> > This is also used by abuild to deduce if cross building or not,
> > and probably caused the problem #1 too.
> >
>
> Problem 1 : (to keeptrack easier)
> This is the content of my /etc/abuild.conf :
> http://pastebin.com/Pq6vYpvD So strange that there is no trace of
> CBUILD variable, even CARCH, CTARGET_ARCH.

My scripts expect that you add CBUILD there. Though it's trivial to get
it from $(gcc -dumpmachine), I think that should be added to abuild.
I'll probably do that soon. I think most of the environment variables
set the cross .conf files should in fact be set in abuild already. I'll
look in to doing that as well.

Though, we are currently looking into improving the build system a bit
more to support cross-building better, including supporting it directly
from abuild command line and building things automatically in chroot.
This needs a bit of design, but is on the way.

> I keep getting CARCH=unknown error. Then I made some modification as
> in :
> https://github.com/tmh1999/alpine-bootstrap-s390x/commit/2aadde7982a9ba679bd01734705321d9dde76d97
>
> AFAIK, CARCH is the build machine architecture (x86_64) and you get
> it by running $ abuild -A. But in my modification, it is armv7.

abuild will deduce CARCH from CHOST. You need to add s390x support to
abuild. See commit:
http://git.alpinelinux.org/cgit/abuild/commit/?id=580dd46c588ef71bc852d2b9a5bb4426a2c47665
 
> Question 1 :
> Until now, I also have successfully built a cross-compiler targeting
> s390x architecture, with above modification to the script and few
> more modification in aports/main/gcc/APKBUILD and
> aports/main/musl/APKBUILD files ( I use the experimental s390x port
> of musl ). I know this is not your problem but I would like to ask
> you since you are more experienced in this problem than me :)
>
> This is the modification I made to aports/main/gcc/APKBUILD file :
>
> --- a/main/gcc/APKBUILD
> +++ b/main/gcc/APKBUILD
> _at_@ -392,7 +427,9 @@ libatomic() {
> mkdir -p "$subpkgdir"/usr/lib
> mv "$pkgdir"/usr/lib/libatomic.so.* "$subpkgdir"/usr/lib/ ||
> \ cp -a "$pkgdir"/usr/$CTARGET/lib/libatomic.so.*
> "$subpkgdir"/usr/lib/ || \
> + cp -a "$pkgdir"/usr/$CTARGET/lib64/libatomic.so.*
> "$subpkgdir"/usr/lib/ || \ return 1
> }
>
> libcxx() {
> _at_@ -403,7 +440,9 @@ libcxx() {
> mkdir -p "$subpkgdir"/usr/lib
> mv "$pkgdir"/usr/lib/libstdc++.so.* "$subpkgdir"/usr/lib/ ||
> \ cp -a "$pkgdir"/usr/$CTARGET/lib/libstdc++.so.*
> "$subpkgdir"/usr/lib/ || \
> + cp -a "$pkgdir"/usr/$CTARGET/lib64/libstdc++.so.*
> "$subpkgdir"/usr/lib/ || \ return 1
> }
>
> gpp() {
> _at_@ -452,7 +491,9 @@ libgcc() {
> mkdir -p "$subpkgdir"/usr/lib
> mv "$pkgdir"/usr/lib/libgcc_s.so.* "$subpkgdir"/usr/lib/ || \
> cp -a "$pkgdir"/usr/$CTARGET/lib/libgcc_s.so.*
> "$subpkgdir"/usr/lib/ || \
> + cp -a "$pkgdir"/usr/$CTARGET/lib64/libgcc_s.so.*
> "$subpkgdir"/usr/lib/ || \ return 1
> }
>
> From what I understand, when we --disable-multilib when configuring
> gcc, lib/ and lib64/ wouldn't be existed at the same time. But in my
> case they are all there and the *.so files are in lib64/ directory.
> This workaround helps the creatcross-toolchain.sh but when running
> crossbuild-toolchain.sh I faced a lot of failures from this lib/,
> lib64/ thing and the 'unknown' described above. What do you think ?

The lib64 is gcc default, and on x86_64 and aarch64 it's similar. We
patch the lib location for these architectures, see:
http://git.alpinelinux.org/cgit/aports/tree/main/gcc/gcc-pure64.patch

You probably need to add similar change for gcc/config/s390/t-linux64.

> Question 2:
>
> So when you started porting armv7 and aarch, which files in the
> aports tree you had to make changes ? Theoretically I can check in
> the git log but that would be a lot, I think :(

Not too many. You probably need (aarch64 commit referred):

- abuild to recognize the triplet (the commit refferred earlier)
  http://git.alpinelinux.org/cgit/abuild/commit/?id=580dd46c588ef71bc852d2b9a5bb4426a2c47665
  
- apk-tools to use the same arch name
  http://git.alpinelinux.org/cgit/apk-tools/commit/?id=06ae5fdfdccd0c8e6d5501d93666bd915d2604d1

- gcc to be configured correct for the arch
  http://git.alpinelinux.org/cgit/aports/commit/main/gcc?id=db1d2c069e66b3bf9962d76b0b48bfdcfc8d0384
  (the ada change is generic, you'll need the _arch_configure +
   gcc-pure64.patch update)

And update APKBUILDs for the packages that are arch aware; for
minimal bootstrap it includes:

- linux-headers
  http://git.alpinelinux.org/cgit/aports/commit/?id=f483f49692b97950b680d987fe31f8ddb9277842

- openssl
  http://git.alpinelinux.org/cgit/aports/commit/?id=896f06e3b0b07200957d0389e2156d0ee4e099cb

- linux-vanilla (or the kernel you need, including creating kernel configuration)
  http://git.alpinelinux.org/cgit/aports/commit/?id=baa04a75170112f9713dd5ad72a5732f9bfaeaac

Some packages might also need other kind of patching, e.g. if configure
does not recognize the new triplet.

Cheers,
Timo


---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Fri Jul 22 2016 - 08:45:14 UTC