GNU bug report logs - #51144
GNU grep 3.7 fails to build on FreeBSD

Previous Next

Package: grep;

Reported by: Alexey Dokuchaev <danfe <at> nsu.ru>

Date: Tue, 12 Oct 2021 03:13:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51144 in the body.
You can then email your comments to 51144 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Tue, 12 Oct 2021 03:13:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alexey Dokuchaev <danfe <at> nsu.ru>:
New bug report received and forwarded. Copy sent to bug-grep <at> gnu.org. (Tue, 12 Oct 2021 03:13:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alexey Dokuchaev <danfe <at> nsu.ru>
To: bug-grep <at> gnu.org
Subject: GNU grep 3.7 fails to build on FreeBSD
Date: Tue, 12 Oct 2021 09:53:00 +0700
Hi there,

Version 3.7 does not build under FreeBSD, with the first problem of
STACK_DIRECTION macro being wrongly defined:

  ...
  ./stackvma.h:31:21: error: invalid token at start of a preprocessor expression
  #if STACK_DIRECTION < 0
                      ^

If I diff the generated grep-3.{6,7}/config.h files, I see this:

  @@ -1483,19 +1666,20 @@
      'size_t'. */
   /* #undef SIZE_T_SUFFIX */
   
  -/* If using the C implementation of alloca, define if you know the
  -   direction of stack growth for your system; otherwise it will be
  -   automatically deduced at runtime.
  -     STACK_DIRECTION > 0 => grows toward higher addresses
  -     STACK_DIRECTION < 0 => grows toward lower addresses
  -     STACK_DIRECTION = 0 => direction of growth unknown */
  -/* #undef STACK_DIRECTION */
  +/* Define on Solaris 11 and its derivates. */
  +/* #undef SOLARIS11 */
   
  +/* Define as the direction of stack growth for your system.  STACK_DIRECTION >
  +   0 => grows toward higher addresses STACK_DIRECTION < 0 => grows toward
  +   lower addresses STACK_DIRECTION = 0 => spaghetti stack. */
  +#define STACK_DIRECTION 
  +
   /* Define to 1 if the `S_IS*' macros in <sys/stat.h> do not work properly. */
   /* #undef STAT_MACROS_BROKEN */

So before it was /* #undef STACK_DIRECTION */, now it's #define
STACK_DIRECTION<space>.  If I undefine it after ./configure manually, the
build still fails further down the road:

  ...
  sigsegv.c:979:29: error: no member named 'is_near_this' in 'struct vma_struct'
                      : vma.is_near_this (addr, &vma))
                        ~~~ ^

I believe the same bug affects diffutils 3.8 on FreeBSD:

    https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257631

./danfe




Information forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Tue, 12 Oct 2021 19:52:01 GMT) Full text and rfc822 format available.

Message #8 received at 51144 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alexey Dokuchaev <danfe <at> nsu.ru>
Cc: 51144 <at> debbugs.gnu.org
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Tue, 12 Oct 2021 12:50:55 -0700
On 10/11/21 19:53, Alexey Dokuchaev via Bug reports for GNU grep wrote:

>    +#define STACK_DIRECTION

I don't observe this problem when I build GNU grep 3.7 on FreeBSD 
13.0-RELEASE amd64.

I suppose the problem is platform-dependent. Could you please send 
details about your platform? Also, what did 'configure' say when it 
attempted to configure stack direction, and what got put into 
config.log? On my platform, config.log says:

configure:35646: checking for stack direction
configure:35741: result: grows down

and config.h says:

#define STACK_DIRECTION -1

which is correct for amd64.




Information forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Wed, 13 Oct 2021 04:16:01 GMT) Full text and rfc822 format available.

Message #11 received at 51144 <at> debbugs.gnu.org (full text, mbox):

From: Alexey Dokuchaev <danfe <at> nsu.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 51144 <at> debbugs.gnu.org
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Wed, 13 Oct 2021 11:02:58 +0700
On Tue, Oct 12, 2021 at 12:50:55PM -0700, Paul Eggert wrote:
> On 10/11/21 19:53, Alexey Dokuchaev via Bug reports for GNU grep wrote:
> 
> >   +#define STACK_DIRECTION
> 
> I don't observe this problem when I build GNU grep 3.7 on FreeBSD
> 13.0-RELEASE amd64.

That's probably because you just tar xf grep-3.7.tar.xz && cd grep-3.7
&& ./configure && make.  This works.  But not when configured from the
FreeBSD ports framework, and here's why.

The clue is these lines:

Vanilla ./configure (untainted):

  configure:4945: checking build system type
  configure:4960: result: x86_64-portbld-freebsd13.0
  configure:4980: checking host system type
  configure:4994: result: x86_64-portbld-freebsd13.0

From within the FreeBSD ports framework:

  configure:4945: checking build system type
  configure:4960: result: amd64-portbld-freebsd13.0
  configure:4980: checking host system type
  configure:4994: result: amd64-portbld-freebsd13.0

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, but ``case "$host_cpu" in''
block has only "i?86 | x86_64 | \" on line 35668 in the configure
script.

> Also, what did 'configure' say when it attempted to configure stack
> direction, and what got put into config.log?
> 
> configure:35646: checking for stack direction
> configure:35741: result: grows down

  configure:35646: checking for stack direction
  configure:35723: cc -o conftest -O2 -pipe [..snip..] conftest.c >&5
  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

> and config.h says:
> 
> #define STACK_DIRECTION -1
> 
> which is correct for amd64.

If I add "amd64" to that list -> "i?86 | x86_64 | amd64 | \" or
fix the main() argument *argv -> **argv, it behaves correctly as
well.

./danfe




Information forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Wed, 13 Oct 2021 18:48:01 GMT) Full text and rfc822 format available.

Message #14 received at 51144 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alexey Dokuchaev <danfe <at> nsu.ru>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, 51144 <at> debbugs.gnu.org
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Wed, 13 Oct 2021 11:47:34 -0700
[Message part 1 (text/plain, inline)]
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.


>    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'.


>> and config.h says:
>>
>> #define STACK_DIRECTION -1

This is after you modified 'configure', right? Otherwise "result: 
unknown" should result in STACK_DIRECTION being 0, which 
gnulib/lib/stackvma.h does not support (perhaps it should?).
[0001-sigsegv-fix-quoting-problem.patch (text/x-patch, attachment)]

Information forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Thu, 14 Oct 2021 14:04:01 GMT) Full text and rfc822 format available.

Message #17 received at 51144 <at> debbugs.gnu.org (full text, mbox):

From: Alexey Dokuchaev <danfe <at> nsu.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, 51144 <at> debbugs.gnu.org
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Thu, 14 Oct 2021 21:02:54 +0700
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




Information forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Thu, 14 Oct 2021 17:36:01 GMT) Full text and rfc822 format available.

Message #20 received at 51144 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alexey Dokuchaev <danfe <at> nsu.ru>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, 51144 <at> debbugs.gnu.org,
 Bruno Haible <bruno <at> clisp.org>
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Thu, 14 Oct 2021 10:34:55 -0700
On 10/14/21 7:02 AM, Alexey Dokuchaev wrote:

> 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?


> 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.


> would you also consider
> adding "amd64" as a synonym to "x86_64" in that switch/case check?

Yes I suppose we could do that. Bruno, what do you think? You wrote most 
of those "x86_64"s.


>> 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?

Not at this point, no.




Information forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Fri, 15 Oct 2021 07:34:01 GMT) Full text and rfc822 format available.

Message #23 received at 51144 <at> debbugs.gnu.org (full text, mbox):

From: Alexey Dokuchaev <danfe <at> nsu.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, tijl <at> FreeBSD.org, 51144 <at> debbugs.gnu.org,
 Bruno Haible <bruno <at> clisp.org>
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Fri, 15 Oct 2021 14:32:54 +0700
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.

./danfe

> > 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.




Information forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Sat, 16 Oct 2021 16:54:01 GMT) Full text and rfc822 format available.

Message #26 received at 51144 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Tijl Coosemans <tijl <at> FreeBSD.org>,
 Alexey Dokuchaev <danfe <at> nsu.ru>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, 51144 <at> debbugs.gnu.org,
 Bruno Haible <bruno <at> clisp.org>
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Sat, 16 Oct 2021 09:53:11 -0700
On 10/16/21 9:40 AM, Tijl Coosemans wrote:
> Where
> necessary we simply pass --build=x64_64-portbld-freebsd$(version).  An
> example is gcc.

Could you pass --build=x64_64-portbld-freebsd$(version) to every 
'configure' invocation, not just gcc's and a few others?

If I understand you correctly, doing that would have avoided this 
particular problem, and it would avoid other potential problems with 
gnulib/m4's float_h.m4, host-cpu-c-abi.m4, lib-prefix.m4, multiarch.m4, 
printf.m4, as well as in GNU projects other than Gnulib (I haven't tried 
to catalog them).




Information forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Sat, 16 Oct 2021 17:07:02 GMT) Full text and rfc822 format available.

Message #29 received at 51144 <at> debbugs.gnu.org (full text, mbox):

From: Tijl Coosemans <tijl <at> FreeBSD.org>
To: Alexey Dokuchaev <danfe <at> nsu.ru>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>,
 51144 <at> debbugs.gnu.org, Bruno Haible <bruno <at> clisp.org>
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 <at> 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.




Information forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Sat, 16 Oct 2021 21:08:01 GMT) Full text and rfc822 format available.

Message #32 received at 51144 <at> debbugs.gnu.org (full text, mbox):

From: Jeffrey Walton <noloader <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Alexey Dokuchaev <danfe <at> nsu.ru>,
 Tijl Coosemans <tijl <at> freebsd.org>,
 Gnulib bugs <bug-gnulib <at> gnu.org>, Bruno Haible <bruno <at> clisp.org>,
 51144 <at> debbugs.gnu.org
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Sat, 16 Oct 2021 17:06:56 -0400
On Sat, Oct 16, 2021 at 12:53 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>
> On 10/16/21 9:40 AM, Tijl Coosemans wrote:
> > Where
> > necessary we simply pass --build=x64_64-portbld-freebsd$(version).  An
> > example is gcc.
>
> Could you pass --build=x64_64-portbld-freebsd$(version) to every
> 'configure' invocation, not just gcc's and a few others?
>
> If I understand you correctly, doing that would have avoided this
> particular problem, and it would avoid other potential problems with
> gnulib/m4's float_h.m4, host-cpu-c-abi.m4, lib-prefix.m4, multiarch.m4,
> printf.m4, as well as in GNU projects other than Gnulib (I haven't tried
> to catalog them).

Related, that may affect Solaris, too. I believe Sun prefers the amd64 prefix.

And there's no telling what some of the other lesser known distros are doing.

Jeff




Information forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Sat, 16 Oct 2021 21:55:02 GMT) Full text and rfc822 format available.

Message #35 received at 51144 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: noloader <at> gmail.com
Cc: Alexey Dokuchaev <danfe <at> nsu.ru>,
 Tijl Coosemans <tijl <at> freebsd.org>,
 Gnulib bugs <bug-gnulib <at> gnu.org>, Bruno Haible <bruno <at> clisp.org>,
 51144 <at> debbugs.gnu.org
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Sat, 16 Oct 2021 14:54:18 -0700
On 10/16/21 2:06 PM, Jeffrey Walton wrote:
> Related, that may affect Solaris, too. I believe Sun prefers the amd64 prefix.

We should be OK there. I just did a "pkg install editor/gnu-emacs" on 
Solaris 11.4, and its (emacs-version) returns "GNU Emacs 25.2.1 
(x86_64-pc-solaris2.11, X toolkit, Xaw scroll bars)" which means it's 
using x86_64. (Though, eeeeuuuw, Xaw? Really?)


> And there's no telling what some of the other lesser known distros are doing.

Sure, but distros can put any string they want there; we can't possibly 
support them all, and it's good to promote a common standard.




Information forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Sun, 17 Oct 2021 21:21:02 GMT) Full text and rfc822 format available.

Message #38 received at 51144 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>, bug-gnulib <at> gnu.org,
 Alexey Dokuchaev <danfe <at> nsu.ru>
Cc: 51144 <at> debbugs.gnu.org
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Sun, 17 Oct 2021 23:20:12 +0200
Alexey Dokuchaev wrote in
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51144> and
<https://lists.gnu.org/archive/html/bug-gnulib/2021-10/msg00018.html>:

> > >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
...
> 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.

This is a recipe for major hassle. The output of config.{guess,sub}
is a *canonicalized* triple. See this comment in config.sub:

  # The goal of this file is to map all the various variations of a given
  # machine specification into a single specification in the form:
  #       CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
  # or in some cases, the newer four-part form:
  #       CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM

and later:

        # Here we normalize CPU types irrespective of the vendor
        amd64-*)
                cpu=x86_64
                ;;

The rationale for this canonicalization is that on the C preprocessor
level, significant synonyms exist (see [1] for the list), and this has
caused many portability issues over time. So, at the autoconf level,
the GNU project has decided to canonicalize the elements of $host.
Linux prefers x86_64, FreeBSD prefers amd64, Windows prefers x64,
and so on. The canonicalization
1) allows the GNU packages to recognize just one (x86_64) instead of
   multiple ones,
2) allows GNU packages that include arch-dependent files (e.g.
   GNU gmp, GNU lightning, GNU libffcall) to name these files consistently.
   Not asm-x86_64.c in one package and asm-amd64.c in another package.

You can architecture the FreeBSD ports collection and its build system
in the way you like. But you cannot expect dozens of GNU packages to
support a different name for a CPU than the canonical name that GNU
picked 18 years ago:

    2003-05-09  Andreas Jaeger  <aj <at> suse.de>

    	* config.sub (maybe_os): Add alias amd64 for x86_64.

You can replace the config.guess script before building a package
in the FreeBSD ports collection. But when it's a GNU package you should
better make sure that this replacement script produces the same results
as the GNU config.guess does.

The same holds for the non-GNU non-FreeBSD packages that use Autoconf:
If you force non-GNU-canonical names on them, they may curse the GNU
build system, but in fact the culprit (= origin of the issue) would
still be the choices made in the FreeBSD ports build system.

Paul Eggert asked:
> > would you also consider
> > adding "amd64" as a synonym to "x86_64" in that switch/case check?
>
> Yes I suppose we could do that. Bruno, what do you think? You wrote most 
> of those "x86_64"s.

A firm "no!" from my part.

Btw, a similar problem exists for the aarch64 / arm64 CPU type.
'aarch64' is the name chosen by the GCC people, whereas 'arm64' is the
name chosen by Linux [2] and by Debian [3]. You need to obey the
canonicalization in effect at the level at which you are working;
at the $host_cpu level you should expect to see 'aarch64', never 'arm64' —
because passing --host=arm64-... is wrong.

Bruno

[1] https://sourceforge.net/p/predef/wiki/Architectures/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch?h=v5.0
[3] http://ftp.debian.org/debian/dists/Debian10.11/main/







Information forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Mon, 18 Oct 2021 02:04:02 GMT) Full text and rfc822 format available.

Message #41 received at 51144 <at> debbugs.gnu.org (full text, mbox):

From: Alexey Dokuchaev <danfe <at> nsu.ru>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 51144 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, bug-gnulib <at> gnu.org
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Mon, 18 Oct 2021 09:03:34 +0700
On Sun, Oct 17, 2021 at 11:20:12PM +0200, Bruno Haible wrote:
> Alexey Dokuchaev wrote in
> ...
> > 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.
> 
> This is a recipe for major hassle. The output of config.{guess,sub}
> is a *canonicalized* triple. See this comment in config.sub:
> 
>   # The goal of this file is to map all the various variations of a given
>   # machine specification into a single specification in the form:
>   #       CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
>   # or in some cases, the newer four-part form:
>   #       CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
> 
> and later:
> 
>         # Here we normalize CPU types irrespective of the vendor
>         amd64-*)
>                 cpu=x86_64
>                 ;;

Hmm, there's no such normalization code in our /usr/ports/Templates/config.sub
with timestamp='2018-05-24'.

> You can architecture the FreeBSD ports collection and its build system
> in the way you like. But you cannot expect dozens of GNU packages to
> support a different name for a CPU than the canonical name that GNU
> picked 18 years ago:
> 
>     2003-05-09  Andreas Jaeger  <aj <at> suse.de>
> 
>     	* config.sub (maybe_os): Add alias amd64 for x86_64.

I wonder why it's not in our template if it's from 2003.

> Paul Eggert asked:
> > > would you also consider adding "amd64" as a synonym to "x86_64" in
> > > that switch/case check?
> >
> > Yes I suppose we could do that. Bruno, what do you think? You wrote most
> > of those "x86_64"s.
> 
> A firm "no!" from my part.

Fair enough; I guess we can live with local patches to configure for our
diffutils and grep ports (for now).

./danfe




Information forwarded to bug-grep <at> gnu.org:
bug#51144; Package grep. (Mon, 18 Oct 2021 05:19:01 GMT) Full text and rfc822 format available.

Message #44 received at 51144 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Alexey Dokuchaev <danfe <at> nsu.ru>
Cc: 51144 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, bug-gnulib <at> gnu.org
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Mon, 18 Oct 2021 07:18:29 +0200
Alexey Dokuchaev wrote:
> I wonder why it's not in our template if it's from 2003.

Just guessing: Maybe because some kernel-related FreeBSD packages want
'amd64'? In other words, don't you need to distinguish original FreeBSD
packages from other packages?

Bruno







Reply sent to Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility. (Wed, 24 Nov 2021 02:47:01 GMT) Full text and rfc822 format available.

Notification sent to Alexey Dokuchaev <danfe <at> nsu.ru>:
bug acknowledged by developer. (Wed, 24 Nov 2021 02:47:01 GMT) Full text and rfc822 format available.

Message #49 received at 51144-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alexey Dokuchaev <danfe <at> nsu.ru>
Cc: Bruno Haible <bruno <at> clisp.org>,
 Tijl Coosemans <tijl <at> freebsd.org>, 51144-done <at> debbugs.gnu.org,
 noloader <at> gmail.com
Subject: Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD
Date: Tue, 23 Nov 2021 18:46:37 -0800
The issues brought up in this Grep bug report seem to be resolved one 
way or another, so I'm closing the bug report.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 22 Dec 2021 12:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 87 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.