https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: app-arch/lrzip-next-0.12.6 fails to compile. Discovered on: amd64 (internal ref: tinderbox_musl) System: MUSL-SYSTEM (https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#MUSL) Info about the issue: https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0014
Created attachment 886026 [details] build.log build log and emerge --info
This one was fun to dig into; the primary compile error is fixed by forcing -D_GNU_SOURCE to be passed when building the lzma source that's included. Unfortunately, this is just the tip of the iceberg; overall, the package is unfixable on musl right now, so I will need to mask this package on musl for the time being until I can poke lrzip-next upstream and get their take on things. Problem is two-fold; this package carries w/ it the sources for several different libraries, including libzpaq and the 7-Zip's lzma SDK. For the first case w/ libzpaq, musl support has been fundamentally broken since the last (final?) release of zpaq by upstream, v7.15, back in ~2016. All further activity from upstream appears to be dead. They do have a github, but they do not accept any contributions via it, and users are instead encouraged to submit fixes directly to the author. However, I don't know if the author is still maintaining this or not. The specific issue breaking things is musl's pthread logic will, by default, only allocate a small stacksize of around ~80KB, which is apparently not enough for the zpaq code to work with. I tried kludging in calls to pthread_attr_setstacksize(), but I'm far from a threading expert and, while I got the code to compile, it appears to break in strange new ways. So I am going to leave it be for now until I can talk to lrzip-next upstream. Refer to the first "See Also" link for more. The second issue is with code imported from 7-Zip's lzma SDK; Similar to the issue w/ zpaq's code, the 7z lzma code is also somewhat broken w/r to pthreads on musl. The lzma code tries to call pthread_attr_setaffinity_np(), which doesn't exist on musl. I tried to replace it w/ a call to pthread_setaffinity_np() and shuffling the logic around, and while that //seems// to work, I think I didn't really solve anything. So, I will bring that up w/ upstream as well.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d82649361f13d1fd8ad669042c9a6fefd368b130 commit d82649361f13d1fd8ad669042c9a6fefd368b130 Author: Joshua Kinard <kumba@gentoo.org> AuthorDate: 2024-02-27 04:23:48 +0000 Commit: Joshua Kinard <kumba@gentoo.org> CommitDate: 2024-02-27 04:28:40 +0000 profiles: Mask app-arch/lrzip-next on musl The package has compatibility issues w/ musl's pthreads implementation at the present time. Bug: https://bugs.gentoo.org/925547 Signed-off-by: Joshua Kinard <kumba@gentoo.org> profiles/features/musl/package.mask | 5 +++++ 1 file changed, 5 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=59f5724e973a008920e5b08edd1ac54713d9ddd8 commit 59f5724e973a008920e5b08edd1ac54713d9ddd8 Author: Joshua Kinard <kumba@gentoo.org> AuthorDate: 2024-02-27 03:53:45 +0000 Commit: Joshua Kinard <kumba@gentoo.org> CommitDate: 2024-02-27 04:28:24 +0000 app-arch/lrzip-next: Remove ~x86 keyword; investigated musl issues Package no longer supports 32-bit arches (sizeof(long) == 4), so will mask on all 32-bit arches. Package is also currently incompatible w/ musl's pthreads code; need to talk to upstream to see if can be fixed. Will mask on musl for now. Also added more missing deps, removed dev-perl/Pod-Parser as a bdep, and added ebuild logic to fill in the package's version w/o needing to drag dev-vcs/git in as a bdep. Bug: https://bugs.gentoo.org/925547 Closes: https://bugs.gentoo.org/925548 Signed-off-by: Joshua Kinard <kumba@gentoo.org> app-arch/lrzip-next/lrzip-next-0.12.6-r1.ebuild | 67 +++++++++++++++++++++++++ app-arch/lrzip-next/lrzip-next-0.12.6.ebuild | 50 ------------------ 2 files changed, 67 insertions(+), 50 deletions(-)
The upstream release of lrzip-next includes v24 of the lzma SDK from 7-Zip upstream, and that has somewhat resolved the pthreads issue on musl. Testing in my amd64 musl chroot, I can fully compile lrzip-next against musl-1.2.5 and run it, and most of the compression modes appear to work. However, I've encountered a segfault when using its ZPAQ compression mode, due to a NULL pointer dereference in its included libzpaq library. So I'll report that upstream, but I will commit an ebuild for 0.13.1 to the tree. Can you run your musl tinderbox against that version and see if it at least passes the pthreads checks that are run? If they do, then that will just leave the libzpaq segfault to get fixed. I'll leave this bug open for the time being.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5485da75f357ff0e9833a7c69c379e0a36b506f0 commit 5485da75f357ff0e9833a7c69c379e0a36b506f0 Author: Joshua Kinard <kumba@gentoo.org> AuthorDate: 2024-08-04 09:34:55 +0000 Commit: Joshua Kinard <kumba@gentoo.org> CommitDate: 2024-08-04 09:36:57 +0000 app-arch/lrzip-next: Update to 0.13.1 Update to v0.13.1, which includes lzma SDK 24.x from 7-Zip upstream. Partially addresses some issues found on musl, however, it will remain masked on musl for the time being until a sigsegv bug in libzpaq is fixed. Bug: https://bugs.gentoo.org/925547 Bug: https://bugs.gentoo.org/925618 Signed-off-by: Joshua Kinard <kumba@gentoo.org> app-arch/lrzip-next/Manifest | 2 +- ...ip-next-0.13.1-fix-lzma_asm_makefile-echo.patch | 20 ++++++ ...-next-0.13.1-use-acx_pthread-configure_ac.patch | 33 ++++++++++ ...t-0.12.6-r1.ebuild => lrzip-next-0.13.1.ebuild} | 30 ++++++--- app-arch/lrzip-next/lrzip-next-9999.ebuild | 77 ++++++++++++++++++++++ app-arch/lrzip-next/metadata.xml | 3 +- 6 files changed, 153 insertions(+), 12 deletions(-)
