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

[Alexey Dokuchaev]

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.

In rare cases, like this one we're dealing with, this difference could
become a problem.  I can't remember when was the last time I've been
bitten by this. :-)

> >   conftest.c:13:1: error: second parameter of 'main' (argument array)
> >     must be of type 'char **'
> >     main (int argc, char *argv)
> >     ^
> >     1 error generated.
> >   configure:35726: $? = 1
> >   configure:35741: result: unknown
> 
> Thanks for reporting that. That's due to a quoting typo in Gnulib's
> m4/stack-direction.m4. I fixed it by installing the attached patch into
> Gnulib. Grep will get this fix the next time it merges from Gnulib. In
> the meantime you should be able work around the problem by changing that
> 'char *argv' to 'char *argv[]' in 'configure'.

Right, that's what I did as I've mentioned above.

> >>and config.h says:
> >>
> >>#define STACK_DIRECTION -1
> 
> This is after you modified 'configure', right?

Right.  So, in retrospect, there were two problems: "amd64" was not in
the list of known architectures, so it could not use known value for
stack direction, and had to fallback to run the program which did not
build because of unescaped brackets.  Fixing either of them allows it
to deduce correct #define STACK_DIRECTION -1.

Now that you've fixed the second problem, would you also consider
adding "amd64" as a synonym to "x86_64" in that switch/case check?

> Otherwise "result: unknown" should result in STACK_DIRECTION being 0,
> which gnulib/lib/stackvma.h does not support (perhaps it should?).

Are you sure "result: unknown" should result in 0, not empty value as
in my first email?

./danfe