Re: lib/Makefile.am:145: GL_GENERATE_STDDEF_H does not appear in AM_CONDITIONAL

Kevin R. Bulgrien wrote: > Not knowing how to resolve this last error, I found: > > http://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00467.html > http://lists.gnu.org/archive/html/bug-automake/2011-05/msg00023.html > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8718 > > Here I see

lib/Makefile.am:145: GL_GENERATE_STDDEF_H does not appear in AM_CONDITIONAL

Being in a situation where it is necessary to port some Linux software to a very old UNIX (OpenServer 5.0.7), and recognizing this platform is sadly dated and not supported, some advice is sought regarding a challenge with trying to use gnulib to add some missing things. As the vendor supplied

[PATCH] crypto/af_alg: fix --help

* m4/af_alg.m4: Avoid spurious newline in --help output. --- ChangeLog| 5 + m4/af_alg.m4 | 6 +++--- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index 24fd4da80..dd479f783 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2018-05-16 Paul

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

Paul Eggert wrote: > If you can't assume 'sed', you can compile and run > a simple program that does the "@" replacement. Yes, given that the uses of 'sed' in gnulib are nearly all of the form sed -e 's/@VAR1@/VALUE1/g' ... -e 's/@VARn@/VALUEn/g' FILE you could write a program 'atsubst' such

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

> From: Paul Smith > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org > Date: Wed, 16 May 2018 12:53:22 -0400 > > On Wed, 2018-05-16 at 19:33 +0300, Eli Zaretskii wrote: > > > these values. Or else I have to create per-system instances of > > > each of these files, of which I already

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

Eli Zaretskii wrote: > Here's an (100% untested) idea: > ... > This idea assumes that glob.in.h and fnmatch.in.h will not change > significantly with time. Whenever they do change, we will need to > update the templates; hopefully the changes will be minor and we will > be able to do that

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

Eli Zaretskii wrote: > > This is the downside of the many features gnulib has: > > - C++ support, > > - support for many platforms, > > - using the function name 'rpl_foo' if and only if 'foo' would collide > > with system-provided 'foo'. > > The downside is that wrong guesses for the

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

On Wed, 2018-05-16 at 19:33 +0300, Eli Zaretskii wrote: > > these values. Or else I have to create per-system instances of > > each of these files, of which I already have 5 just for alloca and > > getloadavg and if I do take on glob/fnmatch that number will > > balloon. > > For the record: what

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

> From: Paul Smith > Cc: bug-gnulib@gnu.org > Date: Tue, 15 May 2018 18:31:05 -0400 > > Here's what I find extremely difficult to manage regarding gnulib's > current design: > > - Heavy reliance on .in files that need to be transformed. > > On systems that aren't POSIX and

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

Hi Paul, > > You really want to reduce the number of redundant Makefiles you have > > to maintain to 1, as soon as possible. > > The only makefiles the GNU make distribution will support will be > standard make makefiles. The model is: > > If you have a configure-capable system, use autotools

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

> From: Bruno Haible > Cc: Eli Zaretskii , Paul Eggert > Date: Wed, 16 May 2018 12:03:44 +0200 > > I think you are barking up the wrong tree. I'm not sure. Make is not like any other GNU package, because it is one of the basic tools required

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

On 05/16/2018 05:43 AM, Paul Smith wrote: The only makefiles the GNU make distribution will support will be standard make makefiles. The model is: If you have a configure-capable system, use autotools to compile GNU make. If you don't have a configure-capable system, use the provided

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

On Wed, 2018-05-16 at 11:29 +0200, Bruno Haible wrote: > This approach with "build_w32.bat" is outdated. The modern approach is > to use the Autoconf and Automake generated configure and Makefile.in > files without modifications. > More in detail: About ca. 10 years ago, Automake started to

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

PS: I wrote > The task of making the > POSIX build tools work on a non-POSIX system is much smaller and very > achievable, especially given enough time (like for VMS). The VMS people apparently actually achieved this task; the binaries of these tools are for download at

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

Paul Smith wrote: > Here's what I find extremely difficult to manage regarding gnulib's > current design: > > - Heavy reliance on .in files that need to be transformed. > > On systems that aren't POSIX and don't have ready access to sed or > similar tools, this is very annoying to deal with. >

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

Paul Smith wrote in : > first, GNU make provides a > bootstrapping script that will let you compile make on systems which > don't already have make... that means that I need to be able to build > all these extra files without the

Re: Testing gnulib on riscv64 - replacement modules (update)

Hi Rich, > $ (cd gllib; ls -1 $(${GNULIB_CHECKOUT}/posix-modules | sed -e 's|-posix$||' > | sort -u | grep -v 'nonblocking' | sed -e 's|$|.o|') 2>/dev/null ) > fclose.o > fcntl.o > fflush.o > fseek.o > fseeko.o > ioctl.o > math.o > mbrlen.o > mbrtowc.o > nanosleep.o > strerror_r.o > sys_socket.o

Testing gnulib on riscv64 - replacement modules (update)

Back in March I was trying to test gnulib on RISC-V using qemu: https://lists.gnu.org/archive/html/bug-gnulib/2018-03/threads.html#00022 We now have real hardware so I am trying to do the tests again, I still get stuck on the "replacement modules" step in the instructions. "Verify that