I've got a reasonably-working musl-based O32/MIPSIII chroot (big-endian) working on musl-1.1.24. Upon updating to musl-1.2.0, all sorts of things just flat-out broke. First, sys-libs/libcap during the 'install' phase: make[1]: Leaving directory '/var/tmp/portage/sys-libs/libcap-2.32/work/libcap-2.32-abi_mips_o32.o32/kdebug' * ERROR: sys-libs/libcap-2.32::gentoo failed (install phase): * unable to read SONAME from libcap.so * * Call stack: * ebuild.sh, line 125: Called src_install * environment, line 2163: Called multilib-minimal_src_install * environment, line 1415: Called multilib_foreach_abi 'multilib-minimal_abi_src_install' * environment, line 1622: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' * environment, line 1302: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' * environment, line 1300: Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_install' * environment, line 415: Called multilib-minimal_abi_src_install * environment, line 1405: Called multilib_src_install * environment, line 1850: Called gen_usr_ldscript '-a' 'cap' * environment, line 945: Called die * The specific snippet of code: * [[ -z ${tlib} ]] && die "unable to read SONAME from ${lib}"; Then, for app-misc/pax-utils, scanelf SIGSEGVs and drops core files (if core is enabled): >>> Install app-misc/pax-utils-1.2.5 into /var/tmp/portage/app-misc/pax-utils-1.2.5/image make -j3 USE_CAP=no USE_DEBUG=no USE_PYTHON=no USE_SECCOMP=yes DESTDIR=/var/tmp/portage/app-misc/pax-utils-1.2.5/image PKGDOCDIR=$(DOCDIR)/pax-utils-1.2.5 install mkdir -p /var/tmp/portage/app-misc/pax-utils-1.2.5/image/usr/bin/ /var/tmp/portage/app-misc/pax-utils-1.2.5/image/usr/share/man/man1/ /var/tmp/portage/app-misc/pax-utils-1.2.5/image/usr/share/doc/pax-utils-1.2.5/ for sh in lddtree symtree ; do install -m755 $sh.sh /var/tmp/portage/app-misc/pax-utils-1.2.5/image/usr/bin/$sh || exit $? ; done install -m755 scanelf dumpelf pspax scanmacho /var/tmp/portage/app-misc/pax-utils-1.2.5/image/usr/bin/ install -m644 README.md BUGS TODO /var/tmp/portage/app-misc/pax-utils-1.2.5/image/usr/share/doc/pax-utils-1.2.5/ install -m644 man/scanelf.1 man/dumpelf.1 man/pspax.1 man/scanmacho.1 /var/tmp/portage/app-misc/pax-utils-1.2.5/image/usr/share/man/man1/ >>> Completed installing app-misc/pax-utils-1.2.5 into /var/tmp/portage/app-misc/pax-utils-1.2.5/image * Final size of build directory: 4739 KiB (4.6 MiB) * Final size of installed tree: 11 KiB /usr/lib/portage/python3.7/estrip: line 38: 16891 Bad system call (core dumped) scanelf -yqRBF '#k%F' -k '.symtab' "${find_paths[@]}" The core file adds a unique twist, as emerge thinks it is part of the package and installs it to /. Then the next package to merge will also SIGSEGV on scanelf, drop /core, which emerge then detects as a file collision and bails out during the qmerge phase. Fix is to drop back to musl-1.1.24, but that was fun, as scanelf effectively screen-vomited when scanning the compiled objects in musl-1.1.24's install phase: >>> Completed installing sys-libs/musl-1.1.24 into /var/tmp/portage/sys-libs/musl-1.1.24/image/ * Final size of build directory: 39134 KiB (38.2 MiB) * Final size of installed tree: 3251 KiB ( 3.1 MiB) * QA Notice: Found an absolute symlink in a library directory: * /lib/ld-musl-mips.so.1 -> /usr/lib/libc.so * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. /usr/lib/portage/python3.7/estrip: line 391: 977 Bad system call (core dumped) scanelf -yqRBF '#k%F' -k '.symtab' "$@" strip: mips-unknown-linux-musl-strip --strip-unneeded -N __gentoo_check_ldflags__ -R .comment -R .GCC.command.line -R .note.gnu.gold-version /usr/lib/librt.a /usr/lib/libm.a /usr/lib/libc.a /usr/lib/libcrypt.a /usr/lib/libpthread.a /usr/lib/libutil.a /usr/lib/libresolv.a /usr/lib/libxnet.a /usr/lib/libdl.a chmod: cannot access ''$'\177''ELF'$'\001\002\001\004\b\001''44 '$'\017\004\002\024\005\344': Invalid argument chmod: cannot access ''$'\177''ELF'$'\001\002\001\004\b\001''44 '$'\017\004\002\024\005\344': Invalid argument chmod: cannot access ''$'\003''A'$'\v\020''p'$'\026''Ba`p5'$'\002''_0'$'\025\003''Bap'$'\021''@'$'\017\220\022''H'$'\023\b''p'$'\001\001''p'$'\005\002''p'$'\006''@p': Invalid argument chmod: cannot access ''$'\003''p'$'\021''Xp'$'\022\037''p'$'\023''X'$'\024\021\027''@'$'\017\330': Invalid argument chmod: cannot access ''$'\003''p'$'\021''Xp'$'\022\037''p'$'\023''X'$'\024\021\027''@'$'\017\330': Invalid argument chmod: cannot access ''$'\003''A'$'\v\020''p'$'\026''Ba`p5'$'\002''_0'$'\025\003''Bap'$'\021''@'$'\017\220\022''H'$'\023\b''p'$'\001\001''p'$'\005\002''p'$'\006''@p': Invalid argument chmod: cannot access '\002\002\022\002\t\022\002\021\022\001''D'$'\022\001''<'$'\022\002'' '$'\022\001''$"'$'\002'\'''$'\022\002''5'$'\022\001': No such file or directory chmod: cannot access '\036\033''G'$'\003\v\t\016''!'\'''$'\025''*'$'\026''62'$'\r''@)'$'\001''n'$'\022\001''u'$'\022\001''='$'\022\001''|B_'$'\364': Invalid argument chmod: cannot access '\002\002\022\002\t\022\002\021\022\001''D'$'\022\001''<'$'\022\002'' '$'\022\001''$"'$'\002'\'''$'\022\002''5'$'\022\001': No such file or directory chmod: cannot access '\036\033''G'$'\003\v\t\016''!'\'''$'\025''*'$'\026''62'$'\r''@)'$'\001''n'$'\022\001''u'$'\022\001''='$'\022\001''|B_'$'\364': Invalid argument chmod: cannot access ''$'\003\032''Ba'$'\240\004\021\032\002''F'$'\022\002''MB_'$'\370\004\021\023\002''S'$'\022\002''X'$'\022\001\002\022''/Ba`'$'\021\026\002''`'$'\022''W'$'\022\373\022\002''g'$'\022\002''n'$'\022\337': Invalid argument chmod: cannot access ''$'\003\032''Ba'$'\240\004\021\032\002''F'$'\022\002''MB_'$'\370\004\021\023\002''S'$'\022\002''X'$'\022\001\002\022''/Ba`'$'\021\026\002''`'$'\022''W'$'\022\373\022\002''g'$'\022\002''n'$'\022\337': Invalid argument chmod: cannot access ''$'\022\234''"'$'\313': Invalid argument chmod: cannot access ''$'\022\234''"'$'\313': Invalid argument chmod: cannot access '\177''B`('$'\v\177''B`,'$'\f\177''B`0'$'\016\177''B`4'$'\017\177''B`8'$'\020\177''B`<'$'\021\177''B`@'$'\022\177''B`D'$'\023\177''B`H'$'\024\177''B`L'$'\025\177''B`P'$'\026\177''B`T'$'\031\177''B`X'$'\032\177''B`\'$'\033\177''B``'$'\034\177''B`d'$'\035\177''B`h'$'\036\177''B`l '$'\177''B`p!'$'\177''B`t"'$'\177''B`x#'$'\177''B`|$'$'\177''B`'$'\200''%'$'\177''B`'$'\204'\'''$'\177''B`'$'\210''('$'\177''B`'$'\214''+'$'\177''B`'$'\220''-'$'\177''B`'$'\224''.'$'\177''B`'$'\230''/'$'\177''B`'$'\234''1'$'\177''B`'$'\240''2'$'\177''B`'$'\244''3'$'\177''B`'$'\250''4'$'\177''B`'$'\254''5'$'\177''B`'$'\260''7'$'\177''B`'$'\264''8'$'\177''B`'$'\270''9'$'\177''B`'$'\274'':'$'\177''B`'$'\300'';'$'\177''B`'$'\304': Invalid argument chmod: cannot access '\177''B`('$'\v\177''B`,'$'\f\177''B`0'$'\016\177''B`4'$'\017\177''B`8'$'\020\177''B`<'$'\021\177''B`@'$'\022\177''B`D'$'\023\177''B`H'$'\024\177''B`L'$'\025\177''B`P'$'\026\177''B`T'$'\031\177''B`X'$'\032\177''B`\'$'\033\177''B``'$'\034\177''B`d'$'\035\177''B`h'$'\036\177''B`l '$'\177''B`p!'$'\177''B`t"'$'\177''B`x#'$'\177''B`|$'$'\177''B`'$'\200''%'$'\177''B`'$'\204'\'''$'\177''B`'$'\210''('$'\177''B`'$'\214''+'$'\177''B`'$'\220''-'$'\177''B`'$'\224''.'$'\177''B`'$'\230''/'$'\177''B`'$'\234''1'$'\177''B`'$'\240''2'$'\177''B`'$'\244''3'$'\177''B`'$'\250''4'$'\177''B`'$'\254''5'$'\177''B`'$'\260''7'$'\177''B`'$'\264''8'$'\177''B`'$'\270''9'$'\177''B`'$'\274'':'$'\177''B`'$'\300'';'$'\177''B`'$'\304': Invalid argument [snip] In short, I think sys-libs/musl-1.2.0 needs to be temporarily p.masked until issues with it are resolved, as it will break a working install.
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!
