Created attachment 403020 [details, diff] musl fixes for sys-fs/xfsdump Like xfsprogs in #549100, here's a patch I cobbled together to make xfsdump compile in a musl environment. Not fully tested yet, but hey, progress...
I added this to the hardened-dev::musl overlay as xfsdump-3.1.4-r99. Its all ~arch which is good enough for mips. This patch is a perfect candidate for upstream. It builds just find on glibc and only adds defines/headers that are totally safe. See http://oss.sgi.com/projects/xfs/contribute.html Marked in progress until it has been upstreamed.
I think that RLIM64_INFINITY should be provided by musl in <sys/resource.h> (in the _LARGEFILE64_SOURCE block) since musl already has RLIM_INFINITY. Can send a patch to the musl list if you want. The <linux/limits.h> also comes up in the other bug. It is needed to get XATTR_LIST_MAX. I'm really not sure whether musl should provide this in <limits.h> or not. Yet another possibility would be for the application to copy the constant from the linux header as for example done in the u-boot bootloader. What is done with SIGCLD should give a trivial patch for upstream to apply.
(In reply to Felix Janda from comment #2) > I think that RLIM64_INFINITY should be provided by musl in > <sys/resource.h> (in the _LARGEFILE64_SOURCE block) since musl > already has RLIM_INFINITY. Can send a patch to the musl list > if you want. > RLIM_INFINITY is specified in POSIX but not RLIM64_INFINITY. So other projects, like zfs have been introducing it themselves. See for example: https://github.com/zfsonlinux/zfs/issues/2608 I'll pass it by upstream. > The <linux/limits.h> also comes up in the other bug. It is > needed to get XATTR_LIST_MAX. I'm really not sure whether > musl should provide this in <limits.h> or not. Yet another > possibility would be for the application to copy the > constant from the linux header as for example done in the > u-boot bootloader. musl should not provide XATTR_LIST_MAX. Its correctly supplied by <linux/limits.h> and so this needs to be included. > > What is done with SIGCLD should give a trivial patch for > upstream to apply.
*** Bug 549100 has been marked as a duplicate of this bug. ***
(In reply to Anthony Basile from comment #3) > (In reply to Felix Janda from comment #2) > > I think that RLIM64_INFINITY should be provided by musl in > > <sys/resource.h> (in the _LARGEFILE64_SOURCE block) since musl > > already has RLIM_INFINITY. Can send a patch to the musl list > > if you want. > > > > RLIM_INFINITY is specified in POSIX but not RLIM64_INFINITY. So other > projects, like zfs have been introducing it themselves. See for example: > > https://github.com/zfsonlinux/zfs/issues/2608 > > I'll pass it by upstream. Its in XOPEN and there's already a patch upstream but it is as yet not applied and not in 1.1.9. The rest can go upstream xfs. > > > The <linux/limits.h> also comes up in the other bug. It is > > needed to get XATTR_LIST_MAX. I'm really not sure whether > > musl should provide this in <limits.h> or not. Yet another > > possibility would be for the application to copy the > > constant from the linux header as for example done in the > > u-boot bootloader. > > musl should not provide XATTR_LIST_MAX. Its correctly supplied by > <linux/limits.h> and so this needs to be included. > > > > > What is done with SIGCLD should give a trivial patch for > > upstream to apply.
The RLIM64_INFINITY change of zfs seems a bit overdone... Really they should just export _FILE_OFFSET_BITS=64 and drop the "64" everywhere. Anyway, I asked on irc about the XATTR_* constants and the answer was "maybe". I'll interpret it as rather unlikely. Anyway my only concern was that we rather don't want upstreams to include more linux headers because they tend to collide with libc headers. In this case it seems to be safe, though, because the definitions agree with the libc ones.
(In reply to Felix Janda from comment #6) any package that utilizes FS funcs should have `append-lfs-flags` in src_configure. Gentoo wants to use LFS everywhere.
Some patches sent upstream: http://oss.sgi.com/pipermail/xfs/2016-January/046184.html
There is a revbump to 3.1.7 by upstream, has the patchset been merged to it?
I am closing this one because I was able to build latest xfsdump-3.1.9 in a musl chroot without any additional patches. Please re-open/file a new bug if there's still an issue.