bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD


From: Tijl Coosemans
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Sat, 16 Oct 2021 18:40:17 +0200

On Fri, 15 Oct 2021 14:32:54 +0700 Alexey Dokuchaev <danfe@nsu.ru> wrote:
> On Thu, Oct 14, 2021 at 10:34:55AM -0700, Paul Eggert wrote:
> > On 10/14/21 7:02 AM, Alexey Dokuchaev wrote:  
> > > On Wed, Oct 13, 2021 at 11:47:34AM -0700, Paul Eggert wrote:  
> > > > On 10/12/21 9:02 PM, Alexey Dokuchaev wrote:  
> > > > > Ports framework does several things which affect GNU configure
> > > > > scripts, particularly, it replaces build-aux/config.guess file
> > > > > with our own, where host/build tuples are derived from.
> > > > > 
> > > > > x86_64 is spelled as amd64 in FreeBSD  
> > > > 
> > > > Ouch. When porting, does this mean you need to look for places where
> > > > GNU source code says "x86_64" and replace many of these places with
> > > > "amd64" before building? That sounds error-prone.  
> > > 
> > > No, of course not, typically we don't replace anything.  All we do is
> > > use our pre-built templates for config.{guess,site,sub} and pass the
> > > --build=amd64-portbld-freebsd$(version) argument to configure scripts
> > > if they are generated by GNU autotools.  
> > 
> > Surely this doesn't work if there's a configure.ac or m4/*.m4 file that
> > does something like this:
> > 
> >   if "$host_os" = x86_64; then
> >     ...
> >   fi
> > 
> > and I see examples of this in gnulib/m4's float_h.m4, host-cpu-c-abi.m4,
> > lib-prefix.m4, multiarch.m4, printf.m4, stack-direction.m4. In general
> > don't you need to also edit these files and re-run Autoconf?  
> 
> In general, we don't edit those files, and typically we only run autoconf
> when there's no pre-generated configure script, or there's something so
> very wrong about it, or generated Makefiles, that patching isn't feasible
> and we have to rebootstrap the whole thing.
> 
> About why this x86_64 vs amd64 thing does not cause massive fallout for
> us, I better ask our Autotools expert.  Tijl, can you shed some light
> here?  I've added back omitted context to the quoted parts of this email,
> I hope Paul wouldn't mind.

It is error prone, but it's rare for configure scripts to test the
architecture so no one has bothered to fix this properly.  Where
necessary we simply pass --build=x64_64-portbld-freebsd$(version).  An
example is gcc.

> > > I can't remember when was the last time I've been bitten by this. :-)  
> > 
> > Often Gnulib code will guess the right value anyway. Not always, though.
> > You ran into a case where Gnulib didn't guess and aborted. Some other
> > times, the guess may differ from what it would be if you did a plain
> > 'configure; make' from a tarball. You might want to test for that, given
> > the above list of potential problem files.
> > 
> > There may well be similar problems in configure.ac or *.m4 files
> > maintained in GNU projects other than Gnulib. Autoconf itself has
> > "x86_64" hardwired into AC_C_BIGENDIAN; I don't know whether this
> > affects FreeBSD compilers.  

This one seems to be used when testing Apple C compilers, so it doesn't
affect us.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]