armhf package contains x86_64 binaries

After using the steps and workaround from #1229 (closed):

The linux-postmarketos-stable-dev package gets correctly built and I get the package armhf/linux-postmarketos-stable-dev-r1.apk in my cache. But the binaries in this package are actually x86_64 instead of armhf.

You can verify this by running

$ objdump -x scripts/basic/fixdep
fixdep:     file format elf64-x86-64
fixdep
architecture: i386:x86-64, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
...

This is probably caused by #1228

Created by: ollieparanoid

Okay, turns out the last "fix" was not really a fix. In Alpine (and in our mainline kernels before that fix) have the following subpackage:

subpackages="$pkgname-dev:_dev:$CBUILD_ARCH"

Which means, the dev subpackage will get generated by executing the _dev() function in the APKBUILD. Now the interesting part is, the architecture that package will get built for is $CBUILD_ARCH, which is the host system's architecture (x86_64), even if we're compiling an armhf kernel. The target architecture is saved in $CARCH.

It seems like Alpine's linux-vanilla etc. APKBUILDS, on which our linux-postmarketos-* packages are based, don't have support for cross-compiling the dev package and will generate a x86_64 dev package when cross-compiling the kernel (that package will be in the packages/x86_64 folder then).

This means, we need to find a way to generate the kernel scripts for $ARCH instead of the host arch. That can probably be done by changing the parameters supplied to the make command. However, the kernel build process itself uses these scripts, so we might need to do it in a new folder so it does not conflict with the x86_64 scripts. I think this should be done in build() and the files should get copied/installed in dev().

NOTE: These kernel scripts are C programs that get compiled to binaries ("scripts" make me think of code that does not get compiled).

By * postmarketOS Bot on 2018-02-15T21:42:42

Ok that's very unexpected when building subpackages. Weird we haven't run into problems with this before. Can't we get pmbootstrap to build the subpackages the same way as the main package with the emulated native cross compiling so things like this just work?

By Martijn Braam on 2018-02-15T21:58:59

Created by: ollieparanoid

Well, you could remove the linux-* from pmb/config/__init__.py to force it being built with qemu + distcc, so you should get the package properly (stopgap solution to unblokc your wireguard work?). I'd be interested in if the compilation is much slower (because some parts do run in qemu then).

But still, I think the better fix would be having the dev package cross-compiled in the native chroot as well by refactoring the APKBUILDs.

By * postmarketOS Bot on 2018-02-15T22:08:02

Normal build: 440.49s Build without native cross compiling: 15837.93s

With that workaround the wireguard package also builds correctly, now I have a problem to fix in the packaging step.

By Martijn Braam on 2018-02-15T23:33:17

Created by: ollieparanoid

Thanks for measuring! Did it use ccache in the first one?

By * postmarketOS Bot on 2018-02-15T23:44:16

yep

By Martijn Braam on 2018-02-15T23:45:44

Created by: ollieparanoid

okay, then the times don't tell us much^^ but cool that you have a package now, I'll still work on properly packaging it in the APKBUILD.

By * postmarketOS Bot on 2018-02-15T23:56:20

without ccache it compiles in 2411.89s

By Martijn Braam on 2018-02-16T14:41:51