Re: [PATCH] bootstrap, gnulib-tool: fix translations rsync

On Fri, Jul 27, 2018 at 11:38:08AM +0200, Bruno Haible wrote: > Paul Eggert wrote: > > I looked at it just now; seems OK, and I installed it. Thanks. > > I added a corresponding ChangeLog entry. Thanks to you both; I'm sorted now (and rather belatedly a convert to using bootstrap rather than keep

lib/stdio-read.c == gnulib/m4/stdio_h.m4

Could this be involved in my errors? The messages from autoreconf: autoreconf: running: aclocal -I m4 -I libopts/m4 -I gnulib/m4 missing file lib/stdio-read.c configure.ac:48: error: expected source file, required through AC_LIBSOURCES, not found m4/gnulib-comp.m4:138: gl_INIT is expanded from...

Re: lib/stdio-read.c == gnulib/m4/stdio_h.m4

On Tue, Jul 31, 2018 at 9:05 AM Bruce Korb wrote: > > Could this be involved in my errors? > The messages from autoreconf: > > > autoreconf: running: aclocal -I m4 -I libopts/m4 -I gnulib/m4 > missing file lib/stdio-read.c > configure.ac:48: error: expected source file, required through > AC_LIBSO

Re: lib/stdio-read.c == gnulib/m4/stdio_h.m4

Solved. On Tue, Jul 31, 2018 at 9:42 AM Bruce Korb wrote: > OK, if I hand link the files gnulib/lib/stdio-{read,write}.c to lib/. > I get further, but that raises the question of "Why is that not done > by gnulib-tool?" > > Anyway, with that by-hand intervention, I get to this: The messages that

[PATCH]: regex: fix memory leak in multibyte character set regexes.

Hello, While investigating memory leaks in sed, I think I found one in gnulib's regex module. This happens with character sets in multibyte locales, which are allocated but not free due to incorrect "#ifdef _LIBC". Can be reproduced with: == $ echo 1 |

Re: [PATCH]: regex: fix memory leak in multibyte character set regexes.

Thanks, could you please install into Gnulib after doing the following: * Comment out the lib/regcomp.c in config/srclist.txt. * File a glibc bug report about this. We're cutting a new glibc release now and this will have to wait until after the dust has settled down. * Put the glibc bug repo

threadlib vs as-needed vs libtool

Hi, I recently encountered the problem that the patch "threadlib: Fix LIBMULTITHREAD on platforms where --as-needed is enabled" was intended to fix. But unfortunately, the fix doesn't actually work because libtool is re-ordering the linker commands. In particular "$stuff -Wl,--push-state -Wl,--no-

Re: lib/stdio-read.c == gnulib/m4/stdio_h.m4

On Tue, Jul 31, 2018 at 11:06 AM Bruce Korb wrote: > > Solved. cd $GNULIB_SRCDIR m4file=$(grep -i 'def.*gl_MACRO_NOT_FOUND' $(git ls-files | grep m4/) | sed 's/:.*//') grep $m4file $(git ls-files|grep module)