>=musl-1.1.15-r2 problems

[edannenberg]

>=musl-1.1.15-r2 problems

[edannenberg]

Thanks for reporting, fix should be in master by the weekend.

[edannenberg]

Hmm, I was not able to reproduce this, could you try again from a fresh state? If the issue still persists, what's your stage3 date?

[soredake]

Tried compiling all from a fresh state (after ./build.sh update), now musl is failing

 * Emerging cross-musl ...

 * musl failed :(
 * 
 * If you file a bug, please attach the following logfiles:
 * /var/log/portage/cross-x86_64-pc-linux-musl-info.log
 * /var/log/portage/cross-x86_64-pc-linux-musl-musl.log.xz
 * /var/tmp/portage/cross-x86_64-pc-linux-musl/musl*/temp/musl-config.logs.tar.xz
failed to run image gentoobb/bob:20161013

[edannenberg]

Odd, build ran fine yesterday. Try checking the logs for some clues:

docker ps -a
docker cp <build-container-id>:/var/log/portage/cross-x86_64-pc-linux-musl-info.log ~/musl.log

[soredake]

https://transfer.sh/bQaMZ/musl.log
https://transfer.sh/S9u3t/musl.log.xz

/usr/libexec/gcc/x86_64-pc-linux-musl/ld: cannot find Scrt1.o: No such file or directory
/usr/libexec/gcc/x86_64-pc-linux-musl/ld: cannot find crti.o: No such file or directory
/usr/libexec/gcc/x86_64-pc-linux-musl/ld: cannot find -lc
/usr/libexec/gcc/x86_64-pc-linux-musl/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status

[edannenberg]

A case of bad timing, couple hours after I did the rebuild last thursday musl-1.1.15-r2 came out, which broke the build. Masked that version for now. Did a complete rebuild with stage 3 20161020 today, looks good.

[soredake]

After this gentoo/gentoo@78404f8, we definitely need to do something,

[edannenberg]

Yep, I should have reported this upstream earlier. :(

https://bugs.gentoo.org/show_bug.cgi?id=605270

As a workaround you could restore the old 1.1.15 ebuild manually for now I guess.

[jbergstroem]

How about sidestepping this by not cross-compiling and using a native musl stage3 as base instead? Will shake things up a bit, but its at least an alternative.

[edannenberg]

I fear this will be a bit more of a shake up. :p But it has been quite a while since I last tried that, things might be a lot smoother now. As a very quick workaround I massaged a couple of lines in Buildconfig.sh and Dockerfile.template of busybox image to use default build container instead of musl. Nothing for production as the good old dns resolution bug in static glibc busybox is still alive, but enough for tinkering.

Bug got confirmed on Gentoo's bugtracker and seems to get some interest, hopefully resolved soon.

For the future it would be nice if different Gentoo stage3 could be supported at the same time, i.e. have a standard stage3 and musl stage3 coexist, would remove the need for crosscompiling musl stuff while still leaving easy outs if musl is not an option.

[edannenberg]

@soredake I somewhat located the issue with PACKAGES.md generation. Only seems to happen when a new file is created, which apparently has the wrong permissions for the host user to add the final header. I fixed the issue in feat/multistage3 branch, generated rootfs.tar files now also get proper host UID/GID ownership.

Still can't reproduce the rm /usr/lib64/misc/ssh-keysign bit.