Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 549116 - sys-fs/xfsdump - patch for building in a musl environment
Summary: sys-fs/xfsdump - patch for building in a musl environment
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo musl team
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks: musl-porting
  Show dependency tree
 
Reported: 2015-05-10 22:40 UTC by Joshua Kinard
Modified: 2020-02-14 13:56 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
musl fixes for sys-fs/xfsdump (xfsdump-3.1.4-musl-fixes.patch,1023 bytes, patch)
2015-05-10 22:40 UTC, Joshua Kinard
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Kinard gentoo-dev 2015-05-10 22:40:29 UTC
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...
Comment 1 Anthony Basile gentoo-dev 2015-05-11 14:07:39 UTC
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.
Comment 2 Felix Janda 2015-05-11 17:55:42 UTC
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.
Comment 3 Anthony Basile gentoo-dev 2015-05-13 11:53:52 UTC
(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.
Comment 4 Anthony Basile gentoo-dev 2015-05-13 14:46:42 UTC
*** Bug 549100 has been marked as a duplicate of this bug. ***
Comment 5 Anthony Basile gentoo-dev 2015-05-14 11:06:18 UTC
(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.
Comment 6 Felix Janda 2015-05-14 16:19:42 UTC
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.
Comment 7 SpanKY gentoo-dev 2015-05-21 04:07:59 UTC
(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.
Comment 8 Felix Janda 2016-01-12 22:38:01 UTC
Some patches sent upstream: http://oss.sgi.com/pipermail/xfs/2016-January/046184.html
Comment 9 tt_1 2017-09-04 08:07:57 UTC
There is a revbump to 3.1.7 by upstream, has the patchset been merged to it?
Comment 10 Thomas Deutschmann gentoo-dev Security 2020-02-14 13:56:03 UTC
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.