Mail archive
alpine-devel

Re: [alpine-devel] Porting Alpine scripts

From: Tuan M. Hoang <tmhoang_at_flatglobe.org>
Date: Sun, 22 Jan 2017 18:46:52 -0500

On Mon, 21 Nov 2016 10:59:25 +0200
Timo Teras <timo.teras_at_iki.fi> wrote:

> I'm still looking at the rest of the patches. Here's my review
> thoughts of them:
>
>
> - aports/linux-vanilla looks good. Though you probably just got the
> kernel config from some other linux distro? It would probably be
> good to cross-check that with other Alpine's linux-vanilla configs to
> see that it is more or less in harmony.

I have done some work on it. You can find for reference here :
http://flatglobe.org/config-vanilla.s390x

> - aports/musl looks mostly ok. We hope musl would soon make release,
> and much of the patch is not needed then as it's mostly upstreamed
> now. There's one issue that's causing some of your trouble. The
> following hunk is wrong:
>
> _at_@ -142,6 +146,7 @@ compat() {
> mips*) _ld="ld.so.1" ;;
> + s390*) _ld="ld-musl-s390x.so.1" ;;
>
> The compat package is supposed to create symlinks that mimic glibc
> provided ld and libraries. The _ld var needs to be setup to be the
> glibc ld name, not the musl one. Looking at gcc, the proper thing
> here to do is:
> - mips*) _ld="ld.so.1" ;;
> + mips* | s390*) _ld="ld.so.1" ;;
>
Thanks. This helped a lot.

> - In main/libressl you add --disable-asm? Why is this needed?
> It seemed to compile just fine without this flag. If really needed,
> this should be made conditional so that it's only applied for s390.
>

Yep this is old flag. Now it is obsolete.

Btw, fyi, 31 support of s390 architecture has been dropped, now it's
all s390x (64 bit version of s390) for all packages, except in linux
kernel, the name still remains s390.
https://github.com/dbussink/linux/commit/5a79859ae0f35d25c67a03e82bf0c80592f16a39

I am currently having two issues, hope you can take some time to see it.

1. I was running Alpine s390x in Docker with some essential
cross-compiled packages targeting s390x, in order to compile natively
the toolchains. It all boils down to missing perl package as
compile-time dependency. Perl cannot be cross-compiled, yet is needed
for native compile. When I try to compile perl natively (inside either
Docker or a chroot), I had segmentation fault on running fakeroot.

Just wonder if this is the correct way you did and segmentation fault
is only my thing.


2. I was having an error when building linux-vanilla-dev ( with above
kernel config ). When running $ make in dev() in APKBUILD, HOSTCC
compiles some scripts in "$srcdir"/linux-$_kernver/scripts directory
into host arch (x86_64) object/exec files. These files were later get
copied into "$subpkgdir"/usr/src/linux-headers-${_abi_release}
(aports/main/linux-vanilla/pkg/linux-vanilla-dev/usr/src/linux-headers-4.4.34).
Then libc.musl-x86_64.so.1 comes up in as a needed .so file in later
steps (scan_shared_objects() function). This happens for
linux-vanilla-dev package, while bootstraping both aarch64, and s390x
using aports master.

$ scanelf --nobanner --recursive --needed
aports/main/linux-vanilla/pkg/linux-vanilla-dev
ET_DYN
libc.musl-x86_64.so.1 ./usr/src/linux-headers-4.4.38/scripts/sortextable
ET_DYN
libc.musl-x86_64.so.1 ./usr/src/linux-headers-4.4.38/scripts/asn1_compiler
ET_DYN
libc.musl-x86_64.so.1 ./usr/src/linux-headers-4.4.38/scripts/dtc/dtc
ET_DYN
libc.musl-x86_64.so.1 ./usr/src/linux-headers-4.4.38/scripts/recordmcount
ET_DYN
libc.musl-x86_64.so.1 ./usr/src/linux-headers-4.4.38/scripts/genksyms/genksyms
ET_DYN
libc.musl-x86_64.so.1 ./usr/src/linux-headers-4.4.38/scripts/kconfig/conf
ET_DYN
libc.musl-x86_64.so.1 ./usr/src/linux-headers-4.4.38/scripts/mod/modpost
ET_DYN
libc.musl-x86_64.so.1 ./usr/src/linux-headers-4.4.38/scripts/mod/mk_elfconfig
ET_DYN
libc.musl-x86_64.so.1 ./usr/src/linux-headers-4.4.38/scripts/basic/bin2c
ET_DYN
libc.musl-x86_64.so.1 ./usr/src/linux-headers-4.4.38/scripts/basic/fixdep
ET_DYN
libc.musl-x86_64.so.1 ./usr/src/linux-headers-4.4.38/scripts/conmakehash
ET_DYN
libc.musl-x86_64.so.1 ./usr/src/linux-headers-4.4.38/scripts/kallsyms

Thanks,
Tuan




---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Sun Jan 22 2017 - 18:46:52 UTC