Summary: | sys-libs/musl-1.2.0 breaks app-misc/pax-utils, sys-libs/libcap (possibly others) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joshua Kinard <kumba> |
Component: | Current packages | Assignee: | Anthony Basile <blueness> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | embedded, mips, musl, zmedico |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | MIPS | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=721336 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 715162 | ||
Bug Blocks: | |||
Attachments: |
emerge --info for musl-1.1.24 chroot, O32/MIPSIII
Build log of sys-libs/libcap-2.32 against musl-1.2.0 Build log of app-misc/pax-utils-1.2.5 against musl-1.2.0 Install log of sys-libs/musl-1.1.24 rebuild with malfunctioning scanelf use -B instead of -q for scanelf |
Description
Joshua Kinard
2020-03-01 22:09:08 UTC
Created attachment 616740 [details]
emerge --info for musl-1.1.24 chroot, O32/MIPSIII
Created attachment 616752 [details]
Build log of sys-libs/libcap-2.32 against musl-1.2.0
Screen copy of the build attempt of sys-libs/libcap-2.32 against sys-libs/musl-1.2.0, showing the successful compile, but during the 'install' phase, it craps out with "unable to read SONAME from libcap.so". I don't know what underlying tool failed here, as I didn't dig in too deeply.
Created attachment 616754 [details]
Build log of app-misc/pax-utils-1.2.5 against musl-1.2.0
Screen copy of the app-misc/pax-utils-1.2.5 against sys-libs/musl-1.2.0. Like with libcap, build is successful, but scanelf will fail during the 'install' phase with "Bad System Call" and dump core. The failing scanelf is the original one built against musl-1.1.24, but this doesn't cause emerge to fail. Because of the core dump, emerge apparently installs ${D}/core to /core. This has a side-effect that the next package to merge (sys-apps/kmod in my case) failed to install because it also caused scanelf to dump core, and emerge detected that ${D}/core as a file collision with the ${D}/core from pax-utils' install.
Created attachment 616756 [details]
Install log of sys-libs/musl-1.1.24 rebuild with malfunctioning scanelf
Screen copy of just the 'install' phase from rebuilding sys-libs/musl-1.1.24 to get the chroot back to a working state. Note the significant quantity of garage dumped to the screen when scanelf goes to scan the rebuilt musl objects. Not sure why it behaved differently here and didn't dump core. Emerge ultimately bailed out in the end due to sandbox violations. I tried disabling sandbox, but it still fails here. But the install phase oddly succeeds, and I can then manually invoke the qmerge phase to install the working musl-1.1.24 build to root. After that, rebuilding pax-utils made things work again.
Note: not using the musl overlay here. If there are fixes already for these failures, especially pax-utils, I suggest moving them to the main portage tree as soon as possible. I'm hoping to base a catalyst run off of this chroot, and catalyst can't really handle layman-managed overlays very well (AFAIK), so fixes need to be in the main tree for this to work. What a mess. anarchy added musl-1.2.0 so I didn't have a chance to test it on any arch. I may have to mask it until we sort this out. (In reply to Anthony Basile from comment #6) > What a mess. anarchy added musl-1.2.0 so I didn't have a chance to test it > on any arch. I may have to mask it until we sort this out. As mips is only one broken we can mask in its profile, nothing is known to be broken with aarch64 nor amd64 (In reply to Joshua Kinard from comment #5) > Note: not using the musl overlay here. If there are fixes already for these > failures, especially pax-utils, I suggest moving them to the main portage > tree as soon as possible. I'm hoping to base a catalyst run off of this > chroot, and catalyst can't really handle layman-managed overlays very well > (AFAIK), so fixes need to be in the main tree for this to work. Not using the musl overlay is foolish. It is up to the package maintainer if they want to include the required patches for musl support. Many will not include patches until they are accepted upstream. (In reply to Jory A. Pratt from comment #7) > (In reply to Anthony Basile from comment #6) > > What a mess. anarchy added musl-1.2.0 so I didn't have a chance to test it > > on any arch. I may have to mask it until we sort this out. > > As mips is only one broken we can mask in its profile, nothing is known to > be broken with aarch64 nor amd64 If mips is the only one broken, then I'm not that worried. (In reply to Jory A. Pratt from comment #8) > (In reply to Joshua Kinard from comment #5) > > Note: not using the musl overlay here. If there are fixes already for these > > failures, especially pax-utils, I suggest moving them to the main portage > > tree as soon as possible. I'm hoping to base a catalyst run off of this > > chroot, and catalyst can't really handle layman-managed overlays very well > > (AFAIK), so fixes need to be in the main tree for this to work. > > Not using the musl overlay is foolish. It is up to the package maintainer if > they want to include the required patches for musl support. Many will not > include patches until they are accepted upstream. Is it possible to tell Catalyst to include the musl overlay along with the portage snapshot? When I did testing with MIPS, I determined that only PAM and gentoo-functions required anything from the musl overlay to build a basic chroot for the purpose of seeding Catalyst to build stages. That's my goal right now, is to have a basic catalyst stage3 that I can build a netboot image from, which I recently accomplished on a January portage snapshot. It looks like gentoo-functions-0.13 fixed the previous issue w/ musl and it compiles fine now. The issue w/ PAM was addressed in Bug #687234. Beyond that, for my netboot I also use the following packages: - busybox - dropbear - dvhtool - e2fsprogs - hdparm - mdadm - nano - ncurses - nfs-utils - parted - pwgen - rpcbind - rsync - sdparm - tmux - timer_entropyd - util-linux - xfsdump - xfsprogs No compile issues on all of them (after some USE flag tweaks), and most that I tested in the netboot image work fine (especially xfsprogs). Certainly beyond these packages, I'll need the overlay, but that can be done outside of Catalyst. I really would like to see a core added to the bug, or a proper backtrace of scanelf failing so we can address the issue properly. I'll put on my TODO. I didn't have coredump support enabled on my SGI machine when I made this bug. Ended up turning it on to try and figure out why my uclibc-ng chroot totally shat itself. Currently re-prepping several glibc chroots and my one musl chroot for another go at catalyst after the release of gcc-9.3.0. Created attachment 635390 [details, diff]
use -B instead of -q for scanelf
Out of curiousity please apply and test the attached patch.
(In reply to Jory A. Pratt from comment #13) > Created attachment 635390 [details, diff] [details, diff] > use -B instead of -q for scanelf > > Out of curiousity please apply and test the attached patch. I should have noted patch is for portage-2.3.99. (In reply to Jory A. Pratt from comment #13) > Created attachment 635390 [details, diff] [details, diff] > use -B instead of -q for scanelf > > Out of curiousity please apply and test the attached patch. It seems like this works so far. Updated portage, manually applied the patch (because misc-functions.sh isn't placed in a bin/ folder anywhere), and then updated to musl-1.2.0. # /usr/lib/libc.so musl libc (mips) Version 1.2.0 Dynamic Program Loader Usage: /usr/lib/libc.so [options] [--] pathname [args] Ran a few additional merges, and nothing like what I originally reported has happened thus far. (In reply to Joshua Kinard from comment #15) > (In reply to Jory A. Pratt from comment #13) > > Created attachment 635390 [details, diff] [details, diff] [details, diff] > > use -B instead of -q for scanelf > > > > Out of curiousity please apply and test the attached patch. > > It seems like this works so far. Updated portage, manually applied the > patch (because misc-functions.sh isn't placed in a bin/ folder anywhere), > and then updated to musl-1.2.0. > > # /usr/lib/libc.so > musl libc (mips) > Version 1.2.0 > Dynamic Program Loader > Usage: /usr/lib/libc.so [options] [--] pathname [args] > > Ran a few additional merges, and nothing like what I originally reported has > happened thus far. Thanks for the feedback. (In reply to Jory A. Pratt from comment #13) > Created attachment 635390 [details, diff] [details, diff] > use -B instead of -q for scanelf > > Out of curiousity please apply and test the attached patch. I've found that this patch is enough to make scanelf -q behave: diff --git a/scanelf.c b/scanelf.c index c2bda35..a931fc0 100644 --- a/scanelf.c +++ b/scanelf.c @@ -1556,4 +1556,2 @@ static int scanelf_elfobj(elfobj *elf) - if (!be_quiet || (be_quiet && FOUND_SOMETHING())) { - puts(out_buffer); - fflush(stdout); - } + puts(out_buffer); + fflush(stdout); Josh are you still seeing a problem with current testing portage? (In reply to Jory A. Pratt from comment #18) > Josh are you still seeing a problem with current testing portage? Haven't turned the build machine on in the last two weeks, but I've probably been doing merges in a musl chroot against 1.2.x without issue since June, so safe to say the issue has been fixed. A new catalyst stage1 build w/ musl-1.2.1 just completed without issue, so calling this fixed and resolving. Thanks! |