Re: [BUG] xfsprogs-4.7.0: issues cross-compiling for musl

From: Ralph Sennhauser <ralph.sennhauser@gmail.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Dave Chinner <david@fromorbit.com>, linux-xfs@vger.kernel.org
Subject: Re: [BUG] xfsprogs-4.7.0: issues cross-compiling for musl
Date: Thu, 8 Sep 2016 15:22:41 +0200	[thread overview]
Message-ID: <20160908152241.437cf8c8@gmail.com> (raw)
In-Reply-To: <ed4c5fc0-d33d-553e-bae8-ea4e269888cc@sandeen.net>

On Thu, 8 Sep 2016 07:13:40 -0500
Eric Sandeen <sandeen@sandeen.net> wrote:

> On 9/8/16 3:41 AM, Ralph Sennhauser wrote:
> > Hi Eric
> > 
> > On Wed, 7 Sep 2016 17:40:01 -0500
> > Eric Sandeen <sandeen@sandeen.net> wrote:
> >   
> >> On 9/7/16 5:27 PM, Dave Chinner wrote:  
> >>> On Wed, Sep 07, 2016 at 11:42:56AM +0200, Ralph Sennhauser
> >>> wrote:    
> >>>> To get xfsprogs to cross-compile for musl some hacks were needed.
> >>>>
> >>>> 1) d_namlen isn't available with musl    
> >>>
> >>> musl problem. It needs to define _DIRENT_HAVE_D_RECLEN and friends
> >>> to tell applications what the struct dirent it defines contains.
> >>>
> >>> (Haven't we been through this before?)    
> >>
> >> (yes: http://www.openwall.com/lists/musl/2016/01/15/9)
> >>
> >> what *does* it contain?
> >>
> >> We do already have:
> >>
> >>  #ifdef _DIRENT_HAVE_D_RECLEN
> >>  		*total += dirent->d_reclen;
> >>  #else
> >> 		*total += dirent->d_namlen + sizeof(*dirent);
> >>  #endif
> >>
> >> but you'd like:
> >>
> >>  #ifdef _DIRENT_HAVE_D_RECLEN
> >>  		*total += dirent->d_reclen;
> >>  #else
> >> -		*total += dirent->d_namlen + sizeof(*dirent);
> >> +		*total += strlen(dirent->d_name) +
> >> sizeof(*dirent); #endif
> >>
> >> but musl *does* have d_reclen:
> >>
> >> http://git.musl-libc.org/cgit/musl/tree/include/dirent.h
> >>
> >> so if it simply advertised that fact we'd be good...  
> > 
> > Why not test for d_reclen in configure instead?  
> 
> Why not advertise it in headers, as the manpage tells us to expect?
> 
> In the end Dave is the final arbiter here.  I don't really care,
> but what I would not want to see is #ifdef hell resulting from
> several different ways to check.  If it can be hidden in configure,
> it doesn't bother me.
> 

It can be hidden from the sources. If musl advertises d_reclen the code
is fixed for musl. We still might want the slow-path to be more POSIX
conformant for other libcs.

> >>
> >> Whatever happened to that request from January above?  
> 
> Nobody knows? ;)
> 

It's not in master :)

> >>>> 2) crc32selftest doesn't make sense in case of cross-compilation,
> >>>> the same can be said if building for a different host with the
> >>>> native toolchain. So maybe an --disable-crc32selftest configure
> >>>> option could be used here.  
> 
> ...
> 
> > So for 2) the plan is disable if cross-compiling, run
> > unconditionally otherwise and no way to overwrite at configure
> > time.  
> 
> Seems reasonable.  I agree that it should be automatic, not a
> config-time switch.  We know if we're cross compiling, so DTRT...
> 
> -Eric
>  

Even with a configure option default would be enabled unless
cross-compiling, that would be my take.

Of course "make test" wasn't ruled out either. Guess that is still open
as well.

Cross-compiling crc32selftest instead of compiling native is probably
more meaningful as well. So that remark earlier certainly has some
merit.

Cheers
Ralph