I would like sys-fs/xfsprogs added to the musl overlay w/ two patches from the OpenBMC project to make it buildable on MIPS. The patches are attached as-is from OpenBMC. they fix the following compile-time error: mips-unknown-linux-musl-gcc -O2 -pipe -march=mips3 -mtune=mips3 -mplt -mfix-r4000 -mfix-r4400 -D_FILE_OFFSET_BITS=64 -Wno-address-of-packed-member -DNDEBUG -DVERSION=\"5.5.0\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -I../libxfs -I.. -DENABLE_GETTEXT -D_GNU_SOURCE -funsigned-char -fno-strict-aliasing -Wall -DHAVE_MNTENT -DHAVE_FSETXATTR -DENABLE_BLKID -DHAVE_GETFSMAP -DHAVE_FALLOCATE -DHAVE_FADVISE -DHAVE_MADVISE -DHAVE_MINCORE -DHAVE_SENDFILE -DHAVE_FIEMAP -DHAVE_COPY_FILE_RANGE -DHAVE_SYNC_FILE_RANGE -DHAVE_SYNCFS -DHAVE_FALLOCATE -DHAVE_PREADV -DHAVE_PWRITEV -DHAVE_READDIR -DHAVE_MREMAP -DHAVE_STATFS_FLAGS -c mmap.c mmap.c: In function _mmap_f_: mmap.c:192:12: error: _MAP_SYNC_ undeclared (first use in this function); did you mean _MS_SYNC_? 192 | flags = MAP_SYNC | MAP_SHARED_VALIDATE; | ^~~~~~~~ | MS_SYNC mmap.c:192:12: note: each undeclared identifier is reported only once for each function it appears in gmake[2]: *** [../include/buildrules:81: mmap.o] Error 1 gmake[1]: *** [include/buildrules:36: io] Error 2 gmake[1]: *** Waiting for unfinished jobs....
Created attachment 634922 [details, diff] Check for MAP_SYNC in sys/mman.h """ From: Khem Raj <raj.khem@gmail.com> Date: Thu, 23 Aug 2018 04:59:39 +0000 Subject: [PATCH] Check for MAP_SYNC in sys/mman.h Not all arches have wired MAP_SYNC e.g. mips which have conflicts with definition, so checking a generic file is going to mis-configure xfsprogs for such arches. libc now has added the relevant macros to sys/mman.h, and returns the right values for arches where its implemented and nothing for others unlike asm-generic/mman.h which only checks for kernel headers and ignored arches """
Created attachment 634924 [details, diff] Include include/xfs/linux.h after <sys/mman.h> """ From: Khem Raj <raj.khem@gmail.com> Date: Thu, 23 Aug 2018 05:33:57 +0000 Subject: [PATCH] include include/xfs/linux.h after <sys/mman.h> This helps compiling with musl which goes ahead and undefines MAP_SYNC for mips and other architectures where its not wired in kernel """
Created attachment 634926 [details, diff] Ebuild diff against xfsprogs-5.5.0.ebuild to add patches
musl team: ping Patches and ebuild diff still apply to xfsprogs-5.8.0 with no issues, so if someone gets to this at some point, please apply it at minimum to xfsprogs-5.8.0. 5.9.0 came out after I took my portage snapshot for catalyst, so I have not tested there just yet.
We're trying not to /add/ new packages to the musl overlay, as maintenance is already a burden. Thankfully many upstreams are merging patches as they're made aware, and other musl-based distros are helping out here. CC'ing base@ as they are maintainers of the package in ::gentoo whilst I do further 'homework' on kernel.org upstreaming.
Ok, so I've checked in with xfs upstream, spoken to Khem directly, and the only thing blocking merging is to check compatibility with older glibc's where MAP_SYNC wasn't provided directly, and kernel headers had to be checked. Hopefully I can look into this over the next few days (RHEL7 is a potential test target) and re-submit to XFS ML, and we'll go from there.
(In reply to Michael 'veremitz' Everitt from comment #6) > Ok, so I've checked in with xfs upstream, spoken to Khem directly, and the > only thing blocking merging is to check compatibility with older glibc's > where MAP_SYNC wasn't provided directly, and kernel headers had to be > checked. > > Hopefully I can look into this over the next few days (RHEL7 is a potential > test target) and re-submit to XFS ML, and we'll go from there. Was any progress ever made on this? I am hoping to kick-off mips catalyst runs again in the next few days, so would like to see this patch included either in our repo or upstream if at all possible.
Changing ownership to base-system due to lack of activity from musl team. Instead of adding these patches to the musl overlay, I'd like to just put them into the main repo. They're specific to the MIPS architecture, but do not affect other archs (compile test on amd64 with xfsprogs-5.12.0). Really they just change some header includes around to what they really should be, since userland code should generally not be attempting to import asm-generic directly. Upstream has been made aware of these patches, but it's an external contributor who was going to push to get them included. I'm assuming that effort stalled due to other priorities on their part.
(In reply to Joshua Kinard from comment #8) > Changing ownership to base-system due to lack of activity from musl team. > Instead of adding these patches to the musl overlay, I'd like to just put > them into the main repo. They're specific to the MIPS architecture, but do > not affect other archs (compile test on amd64 with xfsprogs-5.12.0). Really > they just change some header includes around to what they really should be, > since userland code should generally not be attempting to import asm-generic > directly. > > Upstream has been made aware of these patches, but it's an external > contributor who was going to push to get them included. I'm assuming that > effort stalled due to other priorities on their part. Go ahead. Upstream were approving in the email thread. Just ping them about including it upstream and include a link to this bug and any relevant email threads at the top of the patch please, thanks!
(In reply to Sam James from comment #9) > (In reply to Joshua Kinard from comment #8) > > Changing ownership to base-system due to lack of activity from musl team. > > Instead of adding these patches to the musl overlay, I'd like to just put > > them into the main repo. They're specific to the MIPS architecture, but do > > not affect other archs (compile test on amd64 with xfsprogs-5.12.0). Really > > they just change some header includes around to what they really should be, > > since userland code should generally not be attempting to import asm-generic > > directly. > > > > Upstream has been made aware of these patches, but it's an external > > contributor who was going to push to get them included. I'm assuming that > > effort stalled due to other priorities on their part. > > Go ahead. Upstream were approving in the email thread. Just ping them about > including it upstream and include a link to this bug and any relevant email > threads at the top of the patch please, thanks! Thanks, I will add this to my after-holiday TODO.
(In reply to Joshua Kinard from comment #10) > > Thanks, I will add this to my after-holiday TODO. ping
(In reply to Sam James from comment #11) > (In reply to Joshua Kinard from comment #10) > > > > Thanks, I will add this to my after-holiday TODO. > > ping Fell on the floor. I'll try to get to this as soon as I can, but I have to catch the build machine's root filesystem up to recent packages before I can test this as well as the other keywording bugs.
ping
Comment on attachment 634922 [details, diff] Check for MAP_SYNC in sys/mman.h Checked xfsprogs-6.2.0 sources and this patch appears to be obsolete, as xfsprogs now has #ifdef checks for the MAP_SYNC symbols, and the code structure of the affected 'include/linux.h' file in its source is significantly different.
Marking as OBSOLETE. A test compile of sys-fs/xfsprogs-6.2.0 in a musl chroot completed without any noticeable issues. The patch for the MAP_SYNC symbol issue also appears to be obsolete as well (see comment #14). The second patch looks like it would still be applicable, but I think it, too, isn't a factor anymore due to changes in xfsprogs code and the fact that v6.2.0 compiles in a musl chroot.
