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

2021-10-17 Thread Bruno Haible
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

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

2021-10-17 Thread Alexey Dokuchaev via Gnulib discussion list
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

Re: gnulib does not always detect need for iconv() hack on musl

2021-10-17 Thread Bruno Haible
> The current code in config.guess is a heuristic (that has been working > on Alpine Linux up to 3.13) It works also in Alpine Linux 3.14.2. Which distro are you using? Bruno

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

2021-10-17 Thread Bruno Haible
Alexey Dokuchaev wrote in and : > > >Ports framework does several things which affect GNU configure > > >scripts, particularly, it replaces build-aux/config.guess file > >

Re: gnulib does not always detect need for iconv() hack on musl

2021-10-17 Thread Bruno Haible
Sergei Trofimovich wrote: > Aha, 'config.guess' clearly detects wrong libc here: > > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu Yes, for a musl system, that's wrong. The problem may come from your environment. Which of the

Re: gnulib does not always detect need for iconv() hack on musl

2021-10-17 Thread Sergei Trofimovich
On Sun, Oct 17, 2021 at 07:18:51PM +0200, Bruno Haible wrote: > Hello Sergei, > > Sergei Trofimovich wrote: > > The following fails bison-3.8.2 tests: > > $ ./configure && make && make check > > The following succeeds: > > $ ./configure --host=x86_64-unknown-linux-musl && make && make

Re: double _close()?

2021-10-17 Thread Bruno Haible
Hi Gisle, > > Thus, skipping the fclose_nothrow call introduces a memory leak. > > Right. But I'd rather have leaks than a lot of exceptions. > > So a 'diff -r dir1 dir2' is using mostly read() and > close(). Changing to: > MSVC_INVALID_PARAMETER_HANDLING == HAIRY_LIBRARY_HANDLING > > and

Re: gnulib does not always detect need for iconv() hack on musl

2021-10-17 Thread Bruno Haible
Hello Sergei, Sergei Trofimovich wrote: > The following fails bison-3.8.2 tests: > $ ./configure && make && make check > The following succeeds: > $ ./configure --host=x86_64-unknown-linux-musl && make && make check > > The failure happens due to unexpected '*' output in report logs

gnulib does not always detect need for iconv() hack on musl

2021-10-17 Thread Sergei Trofimovich
Hi gnulib! The problem: The following fails bison-3.8.2 tests: $ ./configure && make && make check The following succeeds: $ ./configure --host=x86_64-unknown-linux-musl && make && make check The failure happens due to unexpected '*' output in report logs instead of '%empty' on 'ASCII'

heap-buffer overflow when searching for regex @\*

2021-10-17 Thread Benno Schulenberg
Hi, When compiling the 'info' program or GNU nano with -fsanitize=address, then searching in either of the programs for the regex "@\*" (without the quotes) causes an abortion in gnulib's re_search_internal() at lib/regexec.c:764. To reproduce, configure texinfo-6.8 with CFLAGS="-g -O0