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(-)
