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 Gnulib

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

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

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 https://sourceforge.net/pro

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 includ

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 bootstrap

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 to build other tools. IOW, building Make could be p

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 t

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 don't have ready acc

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.

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 HAV

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 manually

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 have 5 just for a

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 th

[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 Egg

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 au

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