As the name suggests. I tried keywording 4.5.1 and 4.6.2 with the same results. Attaching build.log next. Reproducible: Always
Created attachment 507530 [details] Failed build.log
please provide the output of emerge --info
Created attachment 507766 [details] emerge --info Sorry about that, here it is
Figured out in the meantime that it happens on amd64-musl, with gcc-6.4.0 and musl-1.18.0 - wonder if one of these is to blame for this regression? I really need a working app-misc/screen on musl for administrating a headless rpi server, so I will try to find out if it compiles with other combinations of gcc/musl. You are working in a qemu-chroot? Hence the missleading output of uname in the emerge --info?
Yes, I'm running an arm qemu chroot. I tried with gcc-5.4.0 and same results. Points more to musl related issue?
Ok, so with a toolchain of musl-1.1.18, gcc-5.4.0-r3 (patchset 1.4) and binutils-2.28.1 it compiles just fine, on armv7a-hardfloat-vanilla. Can you go back to the old binutils with gcc-5.4.0-r3, and try again to compile? I can do the same for gcc-6.4.0 with my amd64 system.
On it. My first crack will be with gcc-5.4.0-r3 with patchset 1.3. It's what I had kicking around in a binary pkg. Depending on the result, I may have to rebuild gcc with patchset 1.4, which will take some time since qemu is quite slow for gcc. I'll let you know once binutils has downgraded.
In any case, please make a backup of the rootfs you're working with. This likely is a nasty one to nail down. The combination of gcc-6.4.0 and older binutils-2.28.1 for the case of amd64 does result in the same compile error as before.
Ok, here with binutils-2.28.1 gcc-5.4.0-r3 (patchset 1.3) musl-1.1.18 It still fails to build screen for me. I'll rebuild gcc-5.4.0-r3 overnight with the latest ebuild from the musl overlay and test again (and take your advice and back-up prior). I notice also that since I built my gcc-5.4.0-r3, there were two other patches added to the ebuild as well, namely: epatch "${FILESDIR}"/${PN}-5.4.0-pr70473.patch epatch "${FILESDIR}"/${PN}-5.4.0-pr71696-CVE-2016-6131.patch
Created attachment 507856 [details] list of current updates This is the list of upgrade, without them app-misc/screen builds fine. Will try to find out by upgrading them one by one if any of them breaks the compile. for gcc-5 patchset: patchset 1.4 adds 91_all_compatibility_fix_with_perl_5.26.patch patchset 1.5 adds 92_all_asan-signal_h.patch
OK, after rebuilding gcc-5.4.0-r3 with current ::musl ebuild (patchset 1.4), I still cannot emerge screen. Did you rebuild musl after switching GCC ?
All the upgrades ran through, but I still can't confirm the breakage on my arm system. The history of emerge on my system is first gcc-4.9.4, then musl-1.1.16, then gcc-5.4.0-r3 and later on musl 1.1.18, skipping 1.1.17. Since then I haven't rebuild gcc-5.4.0-r3, but can clearly recall that I merged gcc-5 with the gcc-5.4.0-pr70473.patch from the very beginning, because I'd run out of memory on the device without this patch. Swapping not helpfull either. Not sure about the second of these patches. So will try to rebuild my gcc-5 with the aim to trigger this bug here. Also it might be possible that something in the eclass (toolchain.eclass) got changed, these sort of silent revbumps are rather popular nowadays.
I made some progress with this. It seems that this is a screen problem wrt utmp/utmpx handling. The #musl people nicely showed me that this was fixed in screen's git in 2015, but for some reason hasn't been put out in a release yet. I can successfully build screen-9999 in the affected environment. I'm not sure what to do longer-pole, since I'd like to not rely on a git checkout. I've asked in #screen and am waiting for a response.
Ok, Amadeusz was kind enough to find a way ahead for us. If I understand correctly, this patch was added on screen-v4 codebase to fix this problem, but then had to be reverted because it broke some other platforms (Cygwin, ..). https://git.savannah.gnu.org/cgit/screen.git/commit/?h=screen-v4&id=74fdc8988b55633cd05f8625390cd3f6a8102003 If I apply just this patch to screen-4.4.0 (the 4.5 and 4.6 ebuilds will also need it), it compiles and works for me on the affected system. The whole thing will be moot when screen-v5 is released, since the way utmp/utmpx was cleaned up a lot and the patch will become unnecessary then. @ tt__1 could you try the patch? I'll also attach to the bug
Created attachment 510342 [details, diff] Fix utmp/utmpx handling on musl
Bug is solved by applying 74fdc8988b55633cd05f8625390cd3f6a8102003 on top of 4.4.0, and likely all other versions. Would it be mergable into the tree? I mean, do we care about cygwin?
If not, worst case could follow what the musl overlay does for gcc and something like this? if use elibc_musl; then epatch "${FILESDIR}"/blah.patch fi
Just hit this myself actually… with a fresh AMD64 stage3 tarball generated from Catalyst this afternoon (which I can throw online if anyone is interested). The patch given in comment #15 fixes the build of screen-4.4.0 for me.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2aacf8d5e4052441f9bb791051a30146bf65793e commit 2aacf8d5e4052441f9bb791051a30146bf65793e Author: Sven Wegener <swegener@gentoo.org> AuthorDate: 2018-01-04 23:15:15 +0000 Commit: Sven Wegener <swegener@gentoo.org> CommitDate: 2018-01-04 23:18:40 +0000 app-misc/screen: Fix building on musl libc, bug #639424 Closes: https://bugs.gentoo.org/639424 Package-Manager: Portage-2.3.14, Repoman-2.3.6 app-misc/screen/files/screen-4.4.0-utmp-musl.patch | 62 ++++++++++++++++++++++ app-misc/screen/screen-4.4.0.ebuild | 3 +- 2 files changed, 64 insertions(+), 1 deletion(-)
Thanks for pushing the fix to the 4.4.0 ebuild, but can you please include it to all the other ebuilds in tree as well? 4.5 branch and 4.6 branch are also affected by the bug and it shouldn't be too much of a big deal, no backporting needed as fare as I see.
ping! screen-4.6.1 got stable and still needs this patch. same for screen-4.6.1, the live ebuild is fine though. likely to be fixed in 4.6.3, so just the two above please, thank you!
