Re: argp-version-etc broken on OpenIndiana
Hello again, looking at Hydra/Nixos, the autobuild system failed due to commit c08f85d made three days ago to gnulib, and it has not recovered since then. This seems to correspond to my report. Regards, Mats E Andersson [1] http://hydra.nixos.org/jobset/gnu/inetutils-master
argp-version-etc broken on OpenIndiana
Hello there! I just tried to build Inetutils with a freshly updated Gnulib source, doing so for the first time in perhaps three weeks on my regular OpenIndiana system with gcc-4.3.3. To my surprice Gnulib source wreeks havoc on the file `argp-version-etc'. A build log is attached. My guess is that `ctype_iso.h' is the point of failure, but also `version-etc.h' afronts as a strong candidate. On behalf of the GNU Inetutils Project, Mats Erik Andersson make: Entering directory `/tmp/bygg' make all-recursive make[1]: Entering directory `/tmp/bygg' Making all in lib make[2]: Entering directory `/tmp/bygg/lib' GENalloca.h GENarpa/inet.h GENdirent.h GENfcntl.h GENgetopt.h GENgetopt-cdefs.h GENglob.h GENinttypes.h GENlanginfo.h GENlimits.h GENlocale.h GENnetdb.h GENpoll.h GENpty.h GENsignal.h GENstdalign.h GENstddef.h GENstdint.h GENstdio.h GENstdlib.h GENstring.h GENstrings.h GENsys/ioctl.h GENsys/select.h GENsys/socket.h GENsys/stat.h GENsys/time.h GENsys/types.h GENsys/uio.h GENtermios.h GENtime.h GENunistd.h GENwchar.h GENwctype.h make all-recursive make[3]: Entering directory `/tmp/bygg/lib' make[4]: Entering directory `/tmp/bygg/lib' CC argp-ba.o CC argp-eexst.o CC argp-fmtstream.o CC argp-fs-xinl.o CC argp-help.o CC argp-parse.o CC argp-pin.o CC argp-pv.o CC argp-pvh.o CC argp-xinl.o CC argp-version-etc.o In file included from /tmp/iu-master/lib/argp-version-etc.c:18: /tmp/iu-master/lib/version-etc.h: In function 'version_etc': /tmp/iu-master/lib/version-etc.h:73: error: expected declaration specifiers before '_GL_ATTRIBUTE_SENTINEL' /tmp/iu-master/lib/version-etc.h:76: error: storage class specified for parameter 'emit_bug_reporting_address' In file included from /usr/include/ctype.h:36, from /tmp/iu-master/lib/argp.h:23, from /tmp/iu-master/lib/argp-version-etc.c:19: /usr/include/iso/ctype_iso.h:81: error: storage class specified for parameter 'isalnum' /usr/include/iso/ctype_iso.h:82: error: storage class specified for parameter 'isalpha' /usr/include/iso/ctype_iso.h:83: error: storage class specified for parameter 'iscntrl' /usr/include/iso/ctype_iso.h:84: error: storage class specified for parameter 'isdigit' /usr/include/iso/ctype_iso.h:85: error: storage class specified for parameter 'isgraph' /usr/include/iso/ctype_iso.h:86: error: storage class specified for parameter 'islower' /usr/include/iso/ctype_iso.h:87: error: storage class specified for parameter 'isprint' /usr/include/iso/ctype_iso.h:88: error: storage class specified for parameter 'ispunct' /usr/include/iso/ctype_iso.h:89: error: storage class specified for parameter 'isspace' /usr/include/iso/ctype_iso.h:90: error: storage class specified for parameter 'isupper' /usr/include/iso/ctype_iso.h:91: error: storage class specified for parameter 'isxdigit' /usr/include/iso/ctype_iso.h:99: error: storage class specified for parameter 'tolower' /usr/include/iso/ctype_iso.h:100: error: storage class specified for parameter 'toupper' /usr/include/iso/ctype_iso.h:106: error: storage class specified for parameter '__ctype' /usr/include/iso/ctype_iso.h:107: error: storage class specified for parameter '__ctype_mask' /usr/include/iso/ctype_iso.h:108: error: storage class specified for parameter '__trans_upper' /usr/include/iso/ctype_iso.h:109: error: storage class specified for parameter '__trans_lower' In file included from /usr/include/ctype.h:37, from /tmp/iu-master/lib/argp.h:23, from /tmp/iu-master/lib/argp-version-etc.c:19: /usr/include/iso/ctype_c99.h:59: error: storage class specified for parameter 'isblank' In file included from /tmp/iu-master/lib/argp.h:23, from /tmp/iu-master/lib/argp-version-etc.c:19: /usr/include/ctype.h:69: error: storage class specified for parameter 'isascii' /usr/include/ctype.h:70: error: storage class specified for parameter 'toascii' /usr/include/ctype.h:71: error: storage class specified for parameter '_tolower' /usr/include/ctype.h:72: error: storage class specified for parameter '_toupper' In file included from ./getopt.h:34, from /tmp/iu-master/lib/argp.h:24, from /tmp/iu-master/lib/argp-version-etc.c:19: /usr/include/getopt.h:62: error: storage class specified for parameter 'optarg' /usr/include/getopt.h:63: error: storage class specified for parameter 'opterr' /usr/include/getopt.h:64: error: storage class specified for parameter 'optind' /usr/include/getopt.h:65: error: storage class specified for parameter 'optopt' /usr/include/getopt.h:72: error: storage class specified for parameter 'getopt_long' /usr/include/getopt.h:74: error: storage class specified for parameter 'getopt_long_only' /usr
Possible testing case of snprintf.
Hello there!
This note has its origin in a report received at bug-inetutils.
The following test code for snprintf() is a simplyfied detection
I have implemented as a warning-only test in Gnu Inetutils.
My point is that Linux/glibc and kfreebsd/glibc triggers this
warning, but OpenSolaris, OpenIndiana, FreeBSD, OpenBSD, NetBSD,
and DragonflyBSD do not! Reading the replacement code for the
Gnulib module snprintf, neither would your function, should it
undergo the test. In conclusion, this is a case where the native
glibc function snprintf() behaves worse than does your replacement.
#define MESSAGE "try a fool"
#define WRONG_MESSAGE "fool"
char msg[sizeof (MESSAGE)] = "try a ";
snprintf (msg, sizeof (msg), "%s%s", msg, WRONG_MESSAGE);
if (!strcmp (msg, WRONG_MESSAGE))
printf ("Warning! snprintf got confused!\n");
Observe that `msg' is target, as well as source. POSIX mentions
nothing about such a use case, but glibc will produce "fool",
whereas all BSD unices as well as OpenSolaris descendants will
produce "try a fool". Tacitly, POSIX would probably cry out
a statement like "Undefined"!
It is my opinion that this discrepancies should at least be documented
in 'snprintf.texi', were you not to take matter so far as to include
this as some sort of test, after due elaboration.
Gnu Inetutils uses legacy code from BSD4.4, where the related use
is present and did not cause troubles, but as the recent report
submitted to us, the code does produce portability issues when
brought to glibc. It has taken a long time to discover this state
of affaires, but now it has surfaced!
On behalf of Gnu Inetutils,
Mats Erik Andersson.
Re: Messed up gl_COMPILER_PREPARE_CHECK_DECL
Dear Bruno, Lördag den 18:e january 2020, klockan 19:11, skrev Bruno Haible detta: > > The cause of the failure is that inetutils/configure.ac invokes > AC_ISC_POSIX before AC_PROG_CC. But AC_ISC_POSIX is documented to expand > into an invocation of AC_SEARCH_LIBS; therefore it requires to run the C > compiler. It therefore does not really make sense to invoke AC_ISC_POSIX > before AC_PROG_CC. You were just lucky that it worked before. The new patch in itself makes the bootrapping successful without further changes to configure.ac of Inetutils. That being said, I inserted the macro AC_PROG_EGREP as recently as January 11th. And immediately it discloses my ignorance of many details, sigh! In contrast, our AC_ISC_POSIX sits fixed since 2005, but does not interfere visibly (beyond the error log copied last time) with the advent of your most recent change. Nonetheless, I will move it to a position where other libraries are probed. Thank you for your most illuminating comments! Regards, Mats E A
Re: Messed up gl_COMPILER_PREPARE_CHECK_DECL
Sorry to pester you again. The first change after my report was successful, but now you continue to push non-portable, or rather, seemingly version-dependent code. Lördag den 18:e january 2020, klockan 14:34, skrev Bruno Haible detta: > > * m4/~~gnulib.m4: New file. > > Not sure whether this is needed, but it feels safer with this patch: The following appears with Gnulib pulled just minutes ago, when bootstrapping Inetutils on OpenIndiana. It was successful with Gnulib ba4b91abd from the 10th of January! Happy hunting wishes Mats E Andersson running: AUTOPOINT=true LIBTOOLIZE=true autoreconf --verbose --install --force -I m4 -I am -I m4 --no-recursive autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal-1.11 -I m4 -I am -I m4 --force -I am -I m4 /usr/share/aclocal/aalib.m4:12: warning: underquoted definition of AM_PATH_AALIB /usr/share/aclocal/aalib.m4:12: run info '(automake)Extending aclocal' /usr/share/aclocal/aalib.m4:12: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal configure.ac:126: error: m4_require: circular dependency of AC_LANG_COMPILER(C) ../../lib/autoconf/lang.m4:329: AC_LANG_COMPILER_REQUIRE is expanded from... ../../lib/autoconf/lang.m4:372: AC_LANG_PREPROC_REQUIRE is expanded from... ../../lib/autoconf/general.m4:2538: AC_EGREP_CPP is expanded from... ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from... ../../lib/autoconf/general.m4:2031: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2052: AC_CACHE_CHECK is expanded from... m4/00gnulib.m4:56: gl_COMPILER_CLANG is expanded from... ../../lib/autoconf/c.m4:429: AC_LANG_COMPILER(C) is expanded from... ../../lib/autoconf/lang.m4:329: AC_LANG_COMPILER_REQUIRE is expanded from... ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from... ../../lib/autoconf/general.m4:2031: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2052: AC_CACHE_CHECK is expanded from... ../../lib/autoconf/libs.m4:47: AC_SEARCH_LIBS is expanded from... ../../lib/autoconf/specific.m4:446: AC_ISC_POSIX is expanded from... configure.ac:126: the top level autom4te: /usr/sfw/bin/gm4 failed with exit status: 1 aclocal-1.11: /usr/bin/autom4te failed with exit status: 1 autoreconf: aclocal-1.11 failed with exit status: 1 ./bootstrap: autoreconf failed
Re: Messed up gl_COMPILER_PREPARE_CHECK_DECL
Bootstrapping, as well as repetition of autoreconf, with Inetutils master at HEAD fails with both of OpenIndiana: autoconf-2.69, automake-1.11.6, m4-1.4.16 Debian 8.8: autoconf-2.69, automake-1.14.1, m4-1.4.17 Gnulib: master HEAD > > error: AC_REQUIRE(gl_COMPILER_PREPARE_CHECK_DECL): > > cannot be used outside of an AC_DEFUN'd macro When changing to commit c5c965^ of Gnulib, autoreconf is successful on both systems, allowing and leading to complete builds of Inetutils. Observe that the backstep is to the commit just before the modification of m4/00gnulib.m4 which introduced gl_COMPILER_PREPARE_CHECK_DECL. Simon Josefsson produced a release candidate with an even earlier gnulib snapshot than I can use to reach the success as given above. Best regards, Mats E A
Messed up gl_COMPILER_PREPARE_CHECK_DECL
Hello there, running autoreconf on OpenIndiana and on Debian GNU/Linux 8.8, with the intent of rebuilding Inetutils, shatters with the message: error: AC_REQUIRE(gl_COMPILER_PREPARE_CHECK_DECL): cannot be used outside of an AC_DEFUN'd macro Bruno Haible created this new macro on January 4th, and Simon Josefsson was able to recreate Inetutils on January 1st, so please check the text of this new feature for any incompleteness or incompatibilities. We are working on release candidates and need valid Gnulib! Best regards, Mats Erik Andersson
FWD: Winsock initialisation is incorrect ...
Hello there,
the following message [1] has been received by the Shishi list.
It seems that Gnulib is the relevant realm for this matter, in
particular the file 'lib/sockets.h' and gl_sockets_startup() are
being touch by complaints and suggestions. I know absolutely
nothing about Winsocks and MinGW, so please evaluate the claims
made by this anonymous user. He maintains a view that the byte
order applied to the macros SOCKETS_#_# is incorrect.
Best regards,
Mats Erik Andersson, on behalf of Shishi
[1] http://lists.gnu.org/archive/html/help-shishi/2015-09/msg1.html
- Beginning of forwarded text -
To whom it may concern:
I built shishi-1.0.2 using MinGW and MSYS. All `make check' tests failed
with
libshishi: warning: Failed to initialized Windows sockets (2)
I am on Windows 8.1.
There are two problems:
1) Incorrect definition of SOCKET* constants in gl/sockets.h
Your definitions are:
#define SOCKETS_1_0 0x100don't use - does not work on Windows XP
#define SOCKETS_1_1 0x101
#define SOCKETS_2_0 0x200don't use - does not work on Windows XP
#define SOCKETS_2_1 0x201
#define SOCKETS_2_2 0x202
>From MSDN
https://msdn.microsoft.com/en-us/library/windows/desktop/ms742213%28v=vs.85%29.aspx
*wVersionRequested* [in]
The highest version of Windows Sockets specification that the caller can
use. The high-order byte specifies the minor version number; the low-order
byte specifies the major version number.
This means that if you want to request Winsock 2.1 (as you do) wRequested
version must be
0x0102, not 0x0201. In lib/init.c, where you have
rc = gl_sockets_startup (SOCKETS_2_1);
you are actually requesting version 1.2.
This leads us to the next problem, which is
2) The test for a compatible version of Winsock is incorrect.
Now let us consider gl_sockets_startup.
WSADATA data;
int err;
err = WSAStartup (version, );
if (err != 0)
return 1;
if (data.wVersion < version)
return 2;
Suppose that we were requesting Winsock 2.0
on a system that had only 1.1. Then version (the requested version) would be
0x0002 and the available version would be 0x0101. In this case
data.wVersion < version is
0x0101 < 0x0002 which is false, so you would end up accepting Winsock 1.1
even though you wanted to reject it because it less than the 2.0 that you
wanted.
You do not need to rearrange the bytes before comparing them. Remember that
WSAStartup must return the version that you requested or a lower one,
because
you already told it the highest version that you can accept. Therefore, if
the
version that is returned is different from the version that was requested,
it must be
less than the version that was requested.
To fix the problem, you must:
a) define the SOCKETS_* constants as follows:
#define SOCKETS_1_0 0x0001
#define SOCKETS_1_1 0x0101
#define SOCKETS_2_0 0x0002
#define SOCKETS_2_1 0x0102
#define SOCKETS_2_2 0x0202
b) change the definition of gl_sockets_startup to:
WSADATA data;
int err;
err = WSAStartup (version, );
if (err != 0)
return 1;
if (data.wVersion != version)
{
/* Winsock was initialised, but with an unacceptable version
so we must clean up before we return the error. */
WSACleanup();
return 2;
I made those changes and now I have 9 tests out of 15 passing. The
remaining 6 failures
may be the subject of future reports, depending on my free time. I just
compiled it because
gss-api can use it, and curl (my real goal) can use gss-api.
Regards,
Test User.
- End of forwarded text -
Re: [PATCH] gc: Fix detection of recent libgcrypt releases.
Hello again, Torsdag den 17:e september 2015, klockan 19:13, skrev Pádraig Brady detta: > On 17/09/15 17:36, Mats Erik Andersson wrote: > > Thanks for the patch. However it seems that GCRYPT_VERSION_NUMBER > has only been available since 1.6.0, so testing for versions before that is > moot. > Perhaps using AM_PATH_LIBGCRYPT like is done in the following is better? > http://lists.freedesktop.org/archives/systemd-devel/2013-May/010885.html Right! A rewritten patch is herewith suggested. It has been used to successfully build Shishi on Debian systems with libgcrypt of versions 1.4.5 and 1.6.3. A configuration reject was achieved by asking for 1.6.4! Best regards, Mats E Andersson, on behalf of Shishi >From 040a28d598363d651582d6602cbc85694025c2ed Mon Sep 17 00:00:00 2001 From: Mats Erik Andersson <g...@gisladisker.se> Date: Fri, 25 Sep 2015 14:18:24 +0200 Subject: [PATCH] gc: Fix detection of installed libgcrypt version. * m4/gc.m4: Use AM_PATH_LIBCRYPT to test for libcrypt versions at least as recent as 1.4.4. The previously used macro is not available now, since modules were removed in version 1.6.0. --- ChangeLog |7 +++ m4/gc.m4 | 22 -- 2 files changed, 19 insertions(+), 10 deletions(-) diff --git a/ChangeLog b/ChangeLog index 3768f3d..7c55198 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2015-09-25 Mats Erik Andersson <g...@gisladisker.se> + + gc: Fix detection of installed libgcrypt version. + * m4/gc.m4: Use AM_PATH_LIBCRYPT to test for libcrypt versions + at least as recent as 1.4.4. The previously used macro is not + available now, since modules were removed in version 1.6.0. + 2015-09-25 Paul Eggert <egg...@cs.ucla.edu> c-ctype: rewrite to use inline functions diff --git a/m4/gc.m4 b/m4/gc.m4 index 8f7d1d0..42ed827 100644 --- a/m4/gc.m4 +++ b/m4/gc.m4 @@ -1,4 +1,4 @@ -# gc.m4 serial 9 +# gc.m4 serial 10 dnl Copyright (C) 2005-2015 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -11,14 +11,16 @@ AC_DEFUN([gl_GC], AS_HELP_STRING([--with-libgcrypt], [use libgcrypt for low-level crypto]), libgcrypt=$withval, libgcrypt=no) if test "$libgcrypt" != no; then -AC_LIB_HAVE_LINKFLAGS([gcrypt], [gpg-error], [ -#include -/* GCRY_MODULE_ID_USER was added in 1.4.4 and gc-libgcrypt.c - will fail on startup if we don't have 1.4.4 or later, so - test for it early. */ -#if !defined GCRY_MODULE_ID_USER -error too old libgcrypt -#endif -]) +# gc-libgcrypt.c will fail on startup if we don't have +# version 1.4.4 or later, so test for it early. */ +gl_good_gcrypt=no +m4_ifdef([AM_PATH_LIBGCRYPT], + [AM_PATH_LIBGCRYPT([1.4.4], [gl_good_gcrypt=yes], + [AC_MSG_ERROR([libgcrypt is too old])])]) +if test "x$gl_good_gcrypt" != xno; then + AC_LIB_HAVE_LINKFLAGS([gcrypt], [gpg-error], [#include ]) +else + AC_MSG_ERROR([libgcrypt not found]) +fi fi ]) -- 1.7.3.2
[PATCH] gc: Fix detection of recent libgcrypt releases.
Dear all, the m4 script related to gcrypt needs an update, as release 1.6 of libgcrypt has removed the macro on which the test is based. We received a bug report to help-shishi [1] which boils down to this remedy A suitable patch is included. Best regards, on behalf of Shishi Mats Erik Andersson [1] http://lists.gnu.org/archive/html/help-shishi/2015-09/msg0.html >From 70eecce9272602f347bc0df7ce125ba8ea7c23c7 Mon Sep 17 00:00:00 2001 From: Mats Erik Andersson <g...@gisladisker.se> Date: Thu, 17 Sep 2015 13:46:51 +0200 Subject: [PATCH] gc: Fix detection of recent libgcrypt releases. * m4/gc.m4: Test libcrypt version macro and reject those earlier than 1.4.4. The macro GCRY_MODULE_ID_USER was deleted in release 1.6.0. Use a proper `#error' directive. --- ChangeLog |7 +++ m4/gc.m4 | 11 +-- 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index de20d36..866c1b4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2015-09-17 Mats Erik Andersson <g...@gisladisker.se> + + gc: Fix detection of recent libgcrypt releases. + * m4/gc.m4: Test libcrypt version macro and reject those + earlier than 1.4.4. The macro GCRY_MODULE_ID_USER was + deleted in release 1.6.0. Use a proper `#error' directive. + 2015-09-08 Assaf Gordon <assafgor...@gmail.com> ceill: detect buggy OpenBSD implementation diff --git a/m4/gc.m4 b/m4/gc.m4 index 8f7d1d0..2fe3f35 100644 --- a/m4/gc.m4 +++ b/m4/gc.m4 @@ -1,4 +1,4 @@ -# gc.m4 serial 9 +# gc.m4 serial 10 dnl Copyright (C) 2005-2015 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -13,11 +13,10 @@ AC_DEFUN([gl_GC], if test "$libgcrypt" != no; then AC_LIB_HAVE_LINKFLAGS([gcrypt], [gpg-error], [ #include -/* GCRY_MODULE_ID_USER was added in 1.4.4 and gc-libgcrypt.c - will fail on startup if we don't have 1.4.4 or later, so - test for it early. */ -#if !defined GCRY_MODULE_ID_USER -error too old libgcrypt +/* gc-libgcrypt.c will fail on startup if we don't have 1.4.4 + or later, so test for this version early on. */ +#if GCRYPT_VERSION_NUMBER < 0x010404 +# error Too old libgcrypt version. #endif ]) fi -- 1.7.3.2
Autoupdate introduces trailing whitespace.
Hello there, the two most recent autoupdates by Karl Berry introduced trailing whitespace, yet gnulib offers the checking tool 'sc_trailing_blank'. Please adhere to your own suggestion. Regards, Mats Erik Andersson, on behalf of GNU Inetutils.
[PATCH] git-version-gen: add a use-case comment
Hello there, I would like to see the the following description of a use-case included as a comment in git-version-gen. Had this recipe been followed by GNU Inetutils, then the reversal of my previous patch to git-version-gen would never have been justified. For good or bad! That lesson leads me also to this suggestion, with which help and authoritative decisions are called for: * Implement a syntax check to assert that git-version-gen is used with a sed-script in configure.ac. == git-version-gen-tag-sed-script is defined in cfg.mk. Perhaps an even stronger check could find proponents: git-version-gen is used in configure.ac == git-version-gen-tag-sed-script is defined in cfg.mk, possibly with an empty value The failure for a project to specify a non-trivial value of 'git-version-gen-tag-sed-script', where a non-empty value is used in 'configure.ac', is that the execution of make dist will receive UNKNOWN from git-version-gen and issue a warning since no match was possible, inspite of correct versioning of the checked out source tree. Best regards, Mats Erik Andersson, on behalf of GNU Inetutils From c83dddb36b1471975bcd7dd972c1916bcb66162a Mon Sep 17 00:00:00 2001 From: Mats Erik Andersson g...@gisladisker.se Date: Fri, 17 Apr 2015 17:33:58 +0200 Subject: [PATCH] git-version-gen: add a use-case comment * build-aux/git-version-gen: Add a further use-case description in the preamble, demonstrating settings with sed scripts used for tag mangling. --- build-aux/git-version-gen | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen index 8e92c0a..b4ae499 100755 --- a/build-aux/git-version-gen +++ b/build-aux/git-version-gen @@ -68,6 +68,22 @@ scriptversion=2014-12-02.19; # UTC # echo $(VERSION) $@-t mv $@-t $@ # dist-hook: # echo $(VERSION) $(distdir)/.tarball-version +# +# The use case just described presumes that tags are prefixed with +# the single character v. Projects prefering other tag naming +# conventions have the option of supplying a normalizing sed script +# to git-version-gen in configure.ac; an entry now taking the form +# +# AC_INIT([GNU project], +# m4_esyscmd([build-aux/git-version-gen .tarball-version 's/our/v/']), +# [bug-project@example]) +# +# It is important, however, for retaining the expected functionality, +# that the identical sed script also is included in cfg.mk: +# +# git-version-gen-tag-sed-script = 's/our/v/' +# +# Failure to do so could have adverse effects during 'make dist'. me=$0 -- 1.7.3.2
[PATCH] gnulib-tool: use bold font portably
Hello there, when 'gnulib-tool' is listing modules in bold type, it does so in a non-portable way. FreeBSD displays this failure, since its printf(1) is not accepting hexadecimally encoded characters. In fact, the POSIX manual page printf(1p) mentions octal encoding as the only valid mechanism. Patch follows. Best regards, Mats Erik Andersson From f1d4b29b460307d0e96b12ce4f3fce9fb86cfd9c Mon Sep 17 00:00:00 2001 From: Mats Erik Andersson g...@gisladisker.se Date: Wed, 15 Apr 2015 18:31:46 +0200 Subject: [PATCH] gnulib-tool: use bold font portably * gnulib-tool (func_show_module_list): Change hexadecimal numbers to octal in BOLD_ON and BOLD_OFF. The use of hex encoded numbers as arguments to `printf' is not portable, and is not claimed by POSIX. This is the case with FreeBSD. --- ChangeLog |8 gnulib-tool |4 ++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 95d49ec..ba811e8 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2015-04-15 Mats Erik Andersson g...@gisladisker.se (tiny change) + + gnulib-tool: use bold font portably + * gnulib-tool (func_show_module_list): Change hexadecimal + numbers to octal in BOLD_ON and BOLD_OFF. The use of hex + encoded numbers as arguments to `printf' is not portable, + and is not claimed by POSIX. This is the case with FreeBSD. + 2015-04-14 Ãngel González keis...@gmail.com tempname: avoid unused parameter warnings (trivial) diff --git a/gnulib-tool b/gnulib-tool index eb1e5a2..303df53 100755 --- a/gnulib-tool +++ b/gnulib-tool @@ -2803,8 +2803,8 @@ func_show_module_list () *) false;; esac; then # Assume xterm compatible escape sequences. -bold_on=`printf '\x1b[1m'` -bold_off=`printf '\x1b[0m'` +bold_on=`printf '\033[1m'` +bold_off=`printf '\033[0m'` else bold_on= bold_off= -- 1.7.3.2
Re: [PATCH] git-version-gen: detect untagged revisions
Tuesday den 14 April 2015 klockan 11:40 skrev Pádraig Brady detta: On 13/04/15 23:04, Mats Erik Andersson wrote: The addition of a leading 'g' to the revision hash is mostly a convenience, but the usability of the patched version applied to some cloned directory of small depth turned out more pleasant than I had expected. Pushed. This has to be undone, as it breaks 'make dist' due to the incomplete (misbehaving?) file 'top/GNUMakefile'. There is no problem with a shallow clone, but a corner case exists with annotated tags. The problem boils down to an issue of tag prefixes, namely as soon as it is not the default v, presumed by git-version-gen. GNU Inetutils prefers the tag prefix inetutils-, so we use the preparator build_aux/git-version-gen .tarball-version 's/inetutils-/v/;s/_/./g' This works correctly for the initial configuration and building, but the makefile target 'dist' will invoke 'top/GNUMakefile' and when computing '_curr-ver' in line 54, it executes $(_build-aux)/git-version-gen .tarball-version \ $(git-version-gen-tag-sed-script) where this last sed script is empty. A recursive grep even for 'sed-script' gives single hit only, so no value is assigned. Hence this renewed call to git-version-gen is not performing any prefix masking, whence the tagged version will be rejected in the test build-aux/git-version-gen: line 161 -- 164 case $v in $prefix[0-9]*) ;; *) (exit 1) ;; esac since the default 'prefix=v' is in use, where we would have needed inetutils-. Unfortunately, this is where my patch enters, because of the above exit 1 my snippet becomes active and it prepends the character 'g' and is not able to remove the prefix inetutils-, so is producing a hitherto unknown revision string and forces a new call to autoconf, where a simple tar-ball build would be expected. It hurts to admit it, but the quickest and the best solution seems to be the reversal of my well ment patch. A whole lot of corner cases must be run through, due to unexpectedly large interplay, before one could depend on the result. It is the prefix handling and the sed script that cause these obscurities. Best regards, Mats Erik Andersson, developer of Inetutils.
Re: [PATCH] git-version-gen: detect untagged revisions
Hello again, Tuesday den 14 April 2015 klockan 21:34 skrev Pádraig Brady detta: On 14/04/15 19:43, Mats Erik Andersson wrote: This has to be undone, as it breaks 'make dist' due to the incomplete (misbehaving?) file 'top/GNUMakefile'. There is no problem with a shallow clone, but a corner case exists with annotated tags. Done, Thank you! Let me add some more information for the record, shedding light on an interdependency I did not observe. Before my change, the build daemon at Hydra would execute 'make dist' and immediately issue WARNING: unable to verify 1.9.2.63-7026-dirty is the correct version With my patch, the corresponding message became INFO: running autoreconf for a new version string: \ ginetutils-1_9_2-63-g7026c69 Our most recent annotated tag is inetutils-1_9_2, so the prepended character 'g' is due to me and the rest is due to the lack of the sed script 's|inetutils-|v|; s|_|.|g'. The warning above is 'top/GNUMakefile' announcing that it accepts a claimed revision string, and in fact this decision is solely due to a very sneeky/cunning use of UNKNOWN: ### top/GNUMakefile: line 58 -- 61 ifneq ($(_curr-ver),$(VERSION)) ifeq ($(_curr-ver),UNKNOWN) $(info WARNING: unable to verify ...) else My solution tried to resolve UNKNOWN into something better, but this code snippet caught me in an unforeseen trap. Any effort to expand 'git-version-gen' must seemeing change also this part. I hope to refine my idea into something less risky, now that a mechanism behind the first failure is at hand. Time will tell! Best regards, Mats Erik Andersson
[PATCH] git-version-gen: detect untagged revisions
Hello there, I have for some time been disturbed by the fact that 'git-version-gen' relies on the presence of an annotated tag in order to pick a good revision string. The following patch is adding a mechanism to use the call 'git describe --always' as the very last resort, in the sense that it enters only if the fallback string is empty. The addition of a leading 'g' to the revision hash is mostly a convenience, but the usability of the patched version applied to some cloned directory of small depth turned out more pleasant than I had expected. Best regards, Mats Erik Andersson, on behalf of GNU Inetutils From c67172c1c9a111b8fddebf997c8a9bf7f6907516 Mon Sep 17 00:00:00 2001 From: Mats Erik Andersson g...@gisladisker.se Date: Mon, 13 Apr 2015 23:00:35 +0200 Subject: [PATCH] git-version-gen: detect untagged revisions * build-aux/git-version-gen: If fallback string is empty, but git is available, use git describe --always to extract a revision, and prefix it with g. This is much better than responding UNKNOWN and it applies to shallow clones! --- ChangeLog |8 build-aux/git-version-gen |8 ++-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 0bf9716..314c216 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2015-04-13 Mats Erik Andersson g...@gisladisker.se + + git-version-gen: detect untagged revisions + * build-aux/git-version-gen: If fallback string is empty, + but git is available, use git describe --always to extract + a revision, and prefix it with g. This is much better than + responding UNKNOWN and it applies to shallow clones! + 2015-04-09 Paul Eggert egg...@cs.ucla.edu gitlog-to-changelog: port to MS-Windows diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen index 8e92c0a..ddc0061 100755 --- a/build-aux/git-version-gen +++ b/build-aux/git-version-gen @@ -189,12 +189,16 @@ then v=`echo $v | sed 's/-/./;s/\(.*\)-g/\1-/'`; v_from_git=1 elif test x$fallback = x || git --version /dev/null 21; then -v=UNKNOWN +if v=g`git describe --always HEAD 2/dev/null`; then + v_from_git=1 +else + v=UNKNOWN +fi else v=$fallback fi -v=`echo $v |sed s/^$prefix//` +v=`echo $v | sed s/^$prefix//` # Test whether to append the -dirty suffix only if the version # string we're using came from git. I.e., skip the test if it's UNKNOWN -- 1.7.3.2
[PATCH] parse-datetime: Avoid pointer difference.
Hello there,
the module parse-datetime suffers from an annoying warning,
due to a comparison of a pointer difference to an unsigned
integer. Please mend this.
Best regards,
Mats Erik Andersson, on behalf of GNU Shishi
From c01f49c76af992fc84357e8e346c3494f90258ce Mon Sep 17 00:00:00 2001
From: Mats Erik Andersson g...@gisladisker.se
Date: Sat, 30 Aug 2014 10:31:35 +0200
Subject: [PATCH] parse-datetime: Avoid pointer difference.
* lib/parse-datetime.y (yylex): Compare pointer to end of buffer,
instead of calculating difference of pointers. This removes an
annoying warning, devoid of any use.
---
ChangeLog| 7 +++
lib/parse-datetime.y | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index a1f9602..c48ca83 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2013-08-30 Mats Erik Andersson g...@gisladisker.se (tiny change)
+
+ parse-datetime: Avoid pointer difference.
+ * lib/parse-datetime.y (yylex): Compare pointer to end of buffer,
+ instead of calculating difference of pointers. This removes an
+ annoying warning, devoid of any use.
+
2014-08-29 Paul Eggert egg...@cs.ucla.edu
qsort_r: new module, for GNU-style qsort_r
diff --git a/lib/parse-datetime.y b/lib/parse-datetime.y
index 0ba0a52..52e6a0c 100644
--- a/lib/parse-datetime.y
+++ b/lib/parse-datetime.y
@@ -1161,7 +1161,7 @@ yylex (YYSTYPE *lvalp, parser_control *pc)
do
{
- if (p - buff sizeof buff - 1)
+ if (p buff + sizeof buff - 1)
*p++ = c;
c = *++pc-input;
}
--
2.1.0.rc1
Inlining error from timespec.h.
Hello there, I am now trying to build GNU Shishi with on Debian with gcc-4.7.2 and with the previous gcc-4.4.5. This includes bootstrapping the source with manywarnings.m4, etcetera. However, gcc-4.4.5 fails due to -Wmissing-prototypes: In file included from internal.h:76, from init.c:23: ../gl/timespec.h:59: warning: no previous prototype for 'timespec_cmp' ../gl/timespec.h:69: warning: no previous prototype for 'timespec_sign' ../gl/timespec.h:84: warning: no previous prototype for 'timespectod' In file included from internal.h:77, from init.c:23: ../gl/xalloc.h:176: warning: no previous prototype for 'x2nrealloc' I have been tracking down the effect of _GL_INLINE for these, but the output is seemingly identical with both versions of cpp. As a side note, gcc-4.4.5 does not accept -Wenum-compare as a valid option for C-coded source, yet it is included in manywarnings. With almost certainty, I know that gcc-4.4.5 could build GNU Shishi a year ago, but no longer does so, unless refraining from the options -Wmissing-prototypes -Wenum-compare. Regards, on behalf of GNU Shishi, Mats Erik Andersson
[PATCH] error: conditionally empty format string.
Hello there, a foolish use of -Wformat=error with gnulib uncovered a case of empty format strings in lib/error.c. The use of clang with FreeBSD-11 uncovered this. It is seemingly the only format error from gnulib that affects Inetutils. Best regards, on behalf of GNU Inetutils Mats Erik Andersson From 03ecb1ceb85140566e64fe94a91fd85c258a43d6 Mon Sep 17 00:00:00 2001 From: Mats Erik Andersson g...@gisladisker.se Date: Fri, 25 Apr 2014 21:45:28 +0200 Subject: [PATCH] error: Conditionally empty format string. --- ChangeLog | 9 + lib/error.c | 7 +++ 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/ChangeLog b/ChangeLog index 4285635..386e1f3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2014-04-25 Mats Erik Andersson g...@gisladisker.se + + error: conditionally empty format string. + Arguments are always present, though. This is caught + by -Wformat=error. + + * lib/error.c (error_at_line): Replace ternary, inline + test for file_name != NULL by a regular if-statement. + 2014-04-18 Pádraig Brady p...@draigbrady.com gitlog-to-changelog: revert inclusion of git-log-fix file diff --git a/lib/error.c b/lib/error.c index 31109df..8bca36e 100644 --- a/lib/error.c +++ b/lib/error.c @@ -373,12 +373,11 @@ error_at_line (int status, int errnum, const char *file_name, #endif } + if (file_name != NULL) #if _LIBC - __fxprintf (NULL, file_name != NULL ? %s:%d: : , - file_name, line_number); +__fxprintf (NULL, %s:%d: , file_name, line_number); #else - fprintf (stderr, file_name != NULL ? %s:%d: : , - file_name, line_number); +fprintf (stderr, %s:%d: , file_name, line_number); #endif va_start (args, message); -- 1.9.2
[PATCH] pty: Activate the signature wrapper of forkpty.
Hello there, the signature wrapper rpl_forkpty() intended for BSD, where there are differences in const-declarations, never takes effect. Hence the native forkpty() is never used in any *BSD. The problem is that the preprocessor macro HAVE_FORKPTY is never defined. A patch follows. Best regards, Mats Erik Andersson, on behalf of GNU Inetutils. From 69bd2487bfd4903281b4b04731a1eabcd66a204a Mon Sep 17 00:00:00 2001 From: Mats Erik Andersson g...@gisladisker.se Date: Wed, 27 Nov 2013 16:08:02 +0100 Subject: [PATCH] pty: Activate the signature wrapper of forkpty. The intended preprocessor macro HAVE_FORKPTY is never defined, yet `lib/forkpty.c' depends on it. --- ChangeLog | 10 ++ m4/pty.m4 |4 +++- 2 filer ändrade, 13 tillägg(+), 1 borttagning(-) diff --git a/ChangeLog b/ChangeLog index 16443b3..612f99a 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2013-11-25 Mats Erik Andersson g...@gisladisker.se + + pty: Activate the signature wrapper of forkpty. + The intended preprocessor macro HAVE_FORKPTY is + never defined, yet `lib/forkpty.c' depends on it. + + * m4/pty.m4 (gl_FUNC_FORKPTY): At completed analysis, + apply AC_DEFINE_UNQUOTED to HAVE_FORKPTY with value + $HAVE_FORKPTY for access to wrapper in `lib/forkpty.c'. + 2013-11-18 Jim Meyering meyer...@fb.com and Paul Eggert egg...@cs.ucla.edu diff --git a/m4/pty.m4 b/m4/pty.m4 index f889831..7184d23 100644 --- a/m4/pty.m4 +++ b/m4/pty.m4 @@ -1,4 +1,4 @@ -# pty.m4 serial 12 +# pty.m4 serial 13 dnl Copyright (C) 2010-2013 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -72,6 +72,8 @@ AC_DEFUN([gl_FUNC_FORKPTY], dnl The system does not have forkpty. HAVE_FORKPTY=0 fi + AC_DEFINE_UNQUOTED([HAVE_FORKPTY], [$HAVE_FORKPTY], +[Define to 1 if the system has the 'forkpty' function.]) ]) AC_DEFUN([gl_FUNC_OPENPTY], -- 1.7.10.4
Re: [PATCH] readline: Support libedit.
onsdag den 16 oktober 2013 klockan 15:26 skrev Eric Blake detta: On 10/16/2013 02:08 PM, Ludovic Courtès wrote: Isn???t libedit supposed to be a clone of Readline just for the sake of avoiding the GPL? Why not let its maintainers fix it, if they really want it to behave like a drop-in replacement? libedit does NOT support history; as such, it is only a drop-in This cannot be be true. How come our inetutils-ftp gives history using add_history() when building on my GNU/kFreeBSD system where libedit is used? Or, do you mean some persistent history file kept in the user's home directory? Regards, Mats Erik Andersson
Re: [PATCH] readline: Support libedit.
onsdag den 16 oktober 2013 klockan 22:08 skrev Ludovic Courtès detta: Mats Erik Andersson g...@gisladisker.se skribis: I would like to see the module readline to access also libedit, should libreadline be missing on a particular system. The patch contained here successfully links against libedit on NetBSD and Debian GNU/kFreeBSD. Likewise, it still behaves correctly with libreadline on GNU/Linux, FreeBSD, DragonFlyBSD, OpenBSD, and OpenSolaris. Isn???t libedit supposed to be a clone of Readline just for the sake of avoiding the GPL? No! Debian presently offers libreadline6, libedit2, and libeditline0. The runtime packages of these are, in the same order, 158 kB, 72 kB, and 11 kB in size. It is true that libedit originates in NetBSD, but I do not see the relevance of this fact to gnulib. On the other hand, DragonFlyBSD, FreeBSD, and OpenBSD bring libreadline by default, so the argument against GPL seems void in this setting. The module readline (not authored by me) offers a crippled readline(), which is hardly more than getline() in its abilities, every time it cannot locate libreadline. I personally find it superior, could that module access the function readline() in more libraries than the heavy weight champion libreadline. My patch is in all essence only improving the m4 script to be better informed of the alternatives. I can add, that in the GNU Inetutils project, the module readline is useless precisely of the above reason. Regards, Mats Erik Andersson
[PATCH] readline: Support libedit.
Hello there, I would like to see the module readline to access also libedit, should libreadline be missing on a particular system. The patch contained here successfully links against libedit on NetBSD and Debian GNU/kFreeBSD. Likewise, it still behaves correctly with libreadline on GNU/Linux, FreeBSD, DragonFlyBSD, OpenBSD, and OpenSolaris. Best regards, Mats Erik Andersson From 21ac3c7a026b2b4be04bdbe62e0f7d1b0e1a0245 Mon Sep 17 00:00:00 2001 From: Mats Erik Andersson g...@gisladisker.se Date: Tue, 15 Oct 2013 22:02:26 +0200 Subject: [PATCH] readline: Support libedit. Allow libedit as an alternate source of readline(). Debian and NetBSD benefit from this extension. * m4/readline.m4: Make libedit into a second choice, should libreadline be missing. * modules/readline: Update conditions to accept libedit. --- ChangeLog| 18 + lib/readline.h |2 ++ m4/readline.m4 | 58 +- modules/readline |4 ++-- 4 filer ändrade, 75 tillägg(+), 7 borttagningar(-) diff --git a/ChangeLog b/ChangeLog index c70f1fe..b6a0cb7 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,21 @@ +2013-10-15 Mats Erik Andersson g...@gisladisker.se + + readline: Support libedit. + Look for readline() in libedit, if it does not exist + within libreadline. + * lib/readline.h [HAVE_EDITLINE_READLINE_H]: + Include editline/readline.h. + * m4/readline.m4 (gl_FUNC_READLINE): Check for libedit, + and headers editline/readline.h, editline/history.h. + Check for readline in libedit. + (HAVE_LIBREADLINE, HAVE_LIBEDIT): New macros, stating that + readline exists in libreadline, or in libedit. The macro + HAVE_READLINE still indicates the existence of readline(). + (LIBEDIT, LTLIBEDIT): New local variables. + * modules/readline (Depends-on): Expand condition for `getline' + to also test gl_cv_lib_edit. + (configure.ac): Add test on gl_cv_lib_edit. + 2013-10-14 Paul Eggert egg...@cs.ucla.edu acl: allow cross-compilation to Gentoo diff --git a/lib/readline.h b/lib/readline.h index af91e10..f3e0853 100644 --- a/lib/readline.h +++ b/lib/readline.h @@ -23,6 +23,8 @@ stdio.h itself. */ # include stdio.h # include readline/readline.h +#elif defined HAVE_EDITLINE_READLINE_H +# include editline/readline.h #else /* Prints a prompt PROMPT and then reads and returns a single line of text from the user. If PROMPT is NULL or the empty string, no diff --git a/m4/readline.m4 b/m4/readline.m4 index dfc48a0..b734ed1 100644 --- a/m4/readline.m4 +++ b/m4/readline.m4 @@ -1,4 +1,4 @@ -# readline.m4 serial 10 +# readline.m4 serial 11 dnl Copyright (C) 2005-2006, 2009-2013 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -17,6 +17,14 @@ AC_DEFUN([gl_FUNC_READLINE], dnl INCREADLINE accordingly. AC_LIB_LINKFLAGS_BODY([readline]) + dnl Likewise for libedit. + AC_LIB_LINKFLAGS_BODY([edit]) + + dnl The headers are needed to distinguish alternate + dnl implementations, so check for them now. + AC_CHECK_HEADERS([readline/readline.h readline/history.h \ +editline/readline.h editline/history.h]) + dnl Add $INCREADLINE to CPPFLAGS before performing the following checks, dnl because if the user has installed libreadline and not disabled its use dnl via --without-libreadline-prefix, he wants to use it. The AC_LINK_IFELSE @@ -24,7 +32,7 @@ AC_DEFUN([gl_FUNC_READLINE], am_save_CPPFLAGS=$CPPFLAGS AC_LIB_APPENDTOVAR([CPPFLAGS], [$INCREADLINE]) - AC_CACHE_CHECK([for readline], [gl_cv_lib_readline], [ + AC_CACHE_CHECK([for libreadline], [gl_cv_lib_readline], [ gl_cv_lib_readline=no am_save_LIBS=$LIBS dnl On some systems, -lreadline doesn't link without an additional @@ -53,8 +61,40 @@ AC_DEFUN([gl_FUNC_READLINE], LIBS=$am_save_LIBS ]) + dnl Check whether libedit exists and works. + dnl The readline emulation comes in two flavours: + dnl + dnl * original by NetBSD offers readline/readline.h, + dnl * while Debian's variant uses editline/readline.h. + dnl + CPPFLAGS=$am_save_CPPFLAGS + AC_LIB_APPENDTOVAR([CPPFLAGS], [$INCEDIT]) + + AC_CACHE_CHECK([for libedit], [gl_cv_lib_edit], [ +gl_cv_lib_edit=no +am_save_LIBS=$LIBS +LIBS=$am_save_LIBS $LIBEDIT +AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include stdio.h +#ifdef HAVE_READLINE_READLINE_H +# include readline/readline.h +#elif defined HAVE_EDITLINE_READLINE_H +# include editline/readline.h +#endif]], + [[readline((char*)0);]])], +[gl_cv_lib_edit=yes]) +LIBS=$am_save_LIBS + ]) + + dnl Is the function readline() located by now? + if test $gl_cv_lib_readline != no || + test $gl_cv_lib_edit != no; then +AC_DEFINE([HAVE_READLINE], [1], [Define if you have the readline function.]) + fi + + dnl Unravel dependency on implementation. Prefer libreadline + dnl over libedit. if test $gl_cv_lib_readline
[PATCH] pmccabe2html: escaping of special characters
Hello there,
it turns out that the module pmccabe2html does not escape
the charecters '', '', and '' properly, when including
C source code. The following patch is able to do that with
Gawk, Mawk, and Nawk. It even produces xmllint-clean output
for the GNU Shishi project, where the resulting file presents
876 functions in a total of 510k HTML code.
Best regards,
Mats Erik Andersson, on behalf of GNU Shishi
From d50f9be209e66832524d5b7b4addf27bf33b46c3 Mon Sep 17 00:00:00 2001
From: Mats Erik Andersson g...@gisladisker.se
Date: Wed, 25 Sep 2013 22:27:03 +0200
Subject: [PATCH] pmccabe2html: escaping of special characters
The C code characters '', '', and '' were improperly
escaped in HTML output, and their multiplicity was ignored.
---
ChangeLog | 11 +++
build-aux/pmccabe2html | 6 +++---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 211d296..770710c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2013-09-25 Mats Erik Andersson g...@gisladisker.se
+
+ pmccabe2html: escaping of special characters
+ Escape all '', '', and '' in HTML output.
+ * build-aux/pmccabe2html (html_fnc): Call gsub()
+ instead of sub() to capture all '', '', and ''.
+ Neither of '' and '' is special in a regexp,
+ so first arguments to gsub() are corrected. Also,
+ in replacement strings, ampersand must be escaped.
+ Finally, '' must be handled first, then '' and ''.
+
2013-09-24 Eric Blake ebl...@redhat.com
manywarnings: enable nicer gcc warning messages
diff --git a/build-aux/pmccabe2html b/build-aux/pmccabe2html
index 094c3e9..ffd0788 100644
--- a/build-aux/pmccabe2html
+++ b/build-aux/pmccabe2html
@@ -422,9 +422,9 @@ function html_fnc (nfun,
while ((getline codeline (fname nfun _fn.txt)) 0)
{
-sub(/\\/, lt;, codeline)
-sub(/\\/, gt;, codeline)
-sub(//, amp;, codeline)
+gsub(//, \amp;, codeline) # Must come first.
+gsub(//, \lt;, codeline)
+gsub(//, \gt;, codeline)
print codeline
}
--
1.8.4.rc3
[PATCH] pmccabe2html: Depends on gawk.
Hello again,
(sorry for the new thread.) I have put together in a
single patch the two deficiencies already reported to
this list. The patch has been tried with GNU Shishi and
three different awk implementations (excluding Gawk),
and has proven to be correct.
Best regards,
Mats Erik Andersson, on behalf of GNU Shishi.
From ec2ccbca2433d30e79bcf756d07b673835879035 Mon Sep 17 00:00:00 2001
From: Mats Erik Andersson g...@gisladisker.se
Date: Thu, 19 Sep 2013 19:47:29 +0200
Subject: [PATCH] pmccabe2html: Portability issue.
Allow awk versions other than Gawk.
Correct wrong HTML tag closures.
---
ChangeLog | 13 +
build-aux/pmccabe2html | 12
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 2cc6c94..b58a877 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2013-09-17 Mats Erik Andersson g...@gisladisker.se
+
+ pmccabe2html: Portability to other awk versions.
+ The functions systime() and strftime() are available
+ in Gawk only. Properly close two HTML-tags 'style'
+ and 'span'.
+ * build-aux/pmccabe2html (BEGIN): Store timing
+ strings in EPOCH_TIME and CHRONOS_TIME. Replace
+ systime() in HTML_COMMENT.
+ (html_header): Correctly close tag 'style'.
+ (END): Replace strftime() by CHRONOS_TIME. Close
+ tag 'span' correctly, not as 'div'.
+
2013-09-17 Mats Erik Andersson g...@gisladisker.se (tiny change)
getgroups: statement without effect
diff --git a/build-aux/pmccabe2html b/build-aux/pmccabe2html
index 863c73e..094c3e9 100644
--- a/build-aux/pmccabe2html
+++ b/build-aux/pmccabe2html
@@ -47,6 +47,10 @@
# Prologue configuration
BEGIN {
+# Portable lookup of present time.
+date +%s | getline epoch_time
+date | getline chronos_time
+
section_global_stats_p = 1
section_function_cyclo_p = 1
@@ -69,7 +73,7 @@ BEGIN {
Copyright (c) 2007, 2008 Free Software Foundation, Inc.
html_doctype = !DOCTYPE html PUBLIC \-//W3C//DTD HTML 4.01 Transitional//EN\ \
\http://www.w3.org/TR/html401/loose.dtd\;
-html_comment = !-- Generated by gnulib's pmccabe2html at systime() --
+html_comment = !-- Generated by gnulib's pmccabe2html at epoch_time --
html_title = Cyclomatic Complexity report for package_name
# Wiki options
@@ -211,7 +215,7 @@ function html_header ()
print cssline
}
print --
- print /style /
+ print /style
close(css)
}
print /head
@@ -852,12 +856,12 @@ END {
if (output_lang == html)
{
print div class=\page_title\ package_name Cyclomatic Complexity Report/div
-print pReport generated at: span class=\report_timestamp\ strftime() /div/p
+print pReport generated at: span class=\report_timestamp\ chronos_time /span/p
}
if (output_lang == wiki)
{
print == package_name Cyclomatic Complexity Report==
-print Report generated at: ''' strftime() '''
+print Report generated at: ''' chronos_time '''
}
if (section_global_stats_p)
--
1.8.4.rc3
getgroups: Malformed assignment.
Hello there, this is a demonstration of the usefulness of -Werror! The module getgroups erroneously has == instead of an assignment in line 89. Patch is included. Regards, Mats Erik Andersson, on behalf of GNU Inetutils From bf89980eb54951197ff94e19d258df204ad5f20a Mon Sep 17 00:00:00 2001 From: Mats Erik Andersson m...@fridtjuv.inre.mea Date: Tue, 17 Sep 2013 00:44:47 +0200 Subject: [PATCH] getgroups: Misprinted assignment. --- ChangeLog |6 ++ lib/getgroups.c |2 +- 2 filer ändrade, 7 tillägg(+), 1 borttagning(-) diff --git a/ChangeLog b/ChangeLog index 0007e17..042f4ac 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2013-09-17 Mats Erik Andersson g...@gisladisker.se (tiny change) + + getgroups: Statement without effect. + * lib/getgroups.c (rpl_getgroups) [HAVE_GETGROUPS]: + Change equality conditional to expected assignment. + 2013-09-09 Eric Blake ebl...@redhat.com glob: fix compilation diff --git a/lib/getgroups.c b/lib/getgroups.c index 9856adc..e71b543 100644 --- a/lib/getgroups.c +++ b/lib/getgroups.c @@ -86,7 +86,7 @@ rpl_getgroups (int n, gid_t *group) } saved_errno = errno; free (gbuf); - errno == saved_errno; + errno = saved_errno; return result; } -- 1.7.10.4
pmccabe2html: Depends on gawk.
Hello there, it turns out that the module pmccabe2html is strongly dependent on gawk, since it expects systime() (once) and strftime() (twice) to be available as built-in functions. Since I would like to build distributions of libshishi with only mawk, that dependency is a show stopper. Could we please see the demands relaxed somewhat? Best regards, Mats Erik Andersson, on behalf of Shishi
pmccabe2html: Tagging errors in HTML template.
Hello there,
the HTML template in build-aux/pmccabe2html contains
two erroneous tags. Mending them allows Lynx to render
the resulting page, at least for Shishi. Patch included.
Best regards,
Mats Erik Andersson, on behalf of Shishi.
From 5eac6d23d1aa5ae8b658e75e721674e201910130 Mon Sep 17 00:00:00 2001
From: Mats Erik Andersson g...@gisladisker.se
Date: Sun, 15 Sep 2013 16:21:45 +0200
Subject: [PATCH] pmccabe2html: Tagging error in HTML template.
Two erroneous tags prevented lynx to render the page.
One is doubly marking the end /style /, the other
was misnamed, needing a tag span.
---
ChangeLog | 5 +
build-aux/pmccabe2html | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 0007e17..6213d84 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2013-09-15 Mats Erik Andersson g...@gisladisker.se
+
+ * build-aux/pmccabe2html: Fix two tag errors, each of
+ which invalidates the resulting HTML source.
+
2013-09-09 Eric Blake ebl...@redhat.com
glob: fix compilation
diff --git a/build-aux/pmccabe2html b/build-aux/pmccabe2html
index 863c73e..6ac7530 100644
--- a/build-aux/pmccabe2html
+++ b/build-aux/pmccabe2html
@@ -211,7 +211,7 @@ function html_header ()
print cssline
}
print --
- print /style /
+ print /style
close(css)
}
print /head
@@ -852,7 +852,7 @@ END {
if (output_lang == html)
{
print div class=\page_title\ package_name Cyclomatic Complexity Report/div
-print pReport generated at: span class=\report_timestamp\ strftime() /div/p
+print pReport generated at: span class=\report_timestamp\ strftime() /span/p
}
if (output_lang == wiki)
{
--
1.8.4.rc3
pthread fails with OpenBSD 4.6 and 5.0.
Hello there, I have discovered that some fairly recent change to either of the modules 'regex' or 'pthread', is messing unduly with OpenBSD 4.6 and 5.0. For sure, I know that the problem were not present at the beginning of April. /* config.h */ #define HAVE_PTHREAD_H 1 /* #undef HAVE_PTHREAD_SPINLOCK_T */ #define HAVE_PTHREAD_T 1 /* #undef HAVE_RAW_DECL_PTHREAD_SIGMASK */ The issue is that 'regex.o' is being linked against 'pthread.o', but the makefile is not told about this need. In fact, a manual intervention /* talkd/Makefile */ - LIBS = + LIBS = $(LIB_PTHREAD) achieves the final linking, but I do not believe this linking should be there at all for OpenBSD. Correct me if I am wrong. Best regards, Mats Erik Andersson, on behalf of GNU Inetutils.
Re: pthread fails with OpenBSD 4.6 and 5.0.
onsdag den 29 maj 2013 klockan 10:27 skrev Paul Eggert detta: Ludovic Courtès reported a similar problem, and I had the following patch in my pipeline. Could you please try it? I've pushed it into gnulib. I've tested it only cursorily. Thanks. GNU Inetutils builds sucessfully on OpenBSD 4.6and 5.0 with your committed patch. Hydra at NixOS.org provides more successful systems, such as GNU/Linux and FreeBSD. Regards, Mats Erik Andersson
bootstrap: Portability issue on FreeBSD.
Hello there,
the bootstrap script contains a hardcoded call to 'sh',
which renders the self-bootstraping unusable on FreeBSD
and DragonFlyBSD. The reason is that the default Bourne
shell on these systems handles the crucial invocation
$ /bin/sh -c 'echo $1 -- $2' -- old new
new --
by removing the placeholder '--' despite the switch '-c'.
This is a different behaviour from all other '/bin/sh'
tested by me, including GNU/Linux, other BSDm and multiple
shells on OpenSolaris.
The patch given below, will improve the situation to allow
$ CONFIG_SHELL=/usr/local/bin/mksh ./bootstrap
with FreeBSD and DragonFlyBSD in a typical source
directory, like GNU Inetutils.
Best regards,
Mats Erik Andersson, working for GNU Inetutils.
diff --git a/build-aux/bootstrap b/build-aux/bootstrap
index bee7765..43c6219 100755
--- a/build-aux/bootstrap
+++ b/build-aux/bootstrap
@@ -630,7 +630,7 @@ esac
if $bootstrap_sync; then
cmp -s $0 $GNULIB_SRCDIR/build-aux/bootstrap || {
echo $0: updating bootstrap and restarting...
-exec sh -c \
+exec ${CONFIG_SHELL-/bin/sh} -c \
'cp $1 $2 shift exec ${CONFIG_SHELL-/bin/sh} $@' \
-- $GNULIB_SRCDIR/build-aux/bootstrap \
$0 $@ --no-bootstrap-sync
openpty module broken on Solaris
The change introduced in gnulib-9fd is broken on OpenSolaris and Solaris 11. The reason is that said patch erroneously leads to a claim /* config.h */ # define HAVE_OPENPTY 1 This leads to an undefined linker reference in openpty.o and thus also in libgnu.a. On behalf of GNU Inetutils, Mats Erik Andersson
Re: secure_getenv is broken on FreeBSD.
torsdag den 7 februari 2013 klockan 22:04 skrev Paul Eggert detta: Sorry, I don't know how hydra works. Hydra only provides a public error report and a convenient build daemon. I myself build a tar-archive on GNU/Linux, then manually conduct builds on virtualized BSD systems on an OpenSolaris system, augmented by some physical systems when need arises. The hydra output did suggest one fix, though. I pushed the following into gnulib. The patch is needed, even if it doesn't fix your bug. Does it help? That insert fixes the issue on FreeBSD, NetBSD and DragonflyBSD, but OpenBSD is hit by the openpty bug reported in another message, so that variant is still inconclusive. Regards Mats Erik Andersson
Also OpenBSD chokes on openpty
The commit 9fd displays a different error behaviour on OpenBSD, than that previously reported for Solaris. OpenBSD 5.0 does in fact offer openpty(3), but the openpty module now erroneously claim /* config.h */ /* #undef HAVE_OPENPTY */ based on the report during configuration check: checking for const-safe openpty signature conftest.c:370: error: conflicting types for 'openpty' /usr/include/util.h:102: error: previous declaration was here. Clearly the m4-macro is misconceived. On behalf of GNU Inetutils, Mats Erik Andersson
Re: openpty module broken on Solaris
fredag den 8 februari 2013 klockan 10:01 skrev Mats Erik Andersson detta: The change introduced in gnulib-9fd is broken on OpenSolaris and Solaris 11. And OpenBSD. The reason is that said patch erroneously leads to a claim /* config.h */ # define HAVE_OPENPTY 1 It seems to me that this as well as the failure on OpenBSD is due to the single statement ## lib/pty.m4 AC_CHECK_FUNCS([_getpty posix_openpty], [HAVE_OPENPTY=1], [HAVE_OPENPTY=0]) which jumps the conclusion in setting an macro based on tests for unrelated function. That these are indeed unrelated can be gathered from the detected variables reproduced below. The actual results for _getpty and posix_openpty correspond exactly to the non-desirable override of HAVE_OPENPTY as observed on Solaris and on OpenBSD. Best regards, Mats Erik Andersson # FreeBSD 9.0: Succeeds ac_cv_func__getpty=no ac_cv_func_posix_openpt=yes ac_cv_have_decl_posix_openpt=yes ac_cv_have_decl_openpty=yes gl_cv_have_raw_decl_posix_openpt=yes gl_cv_have_raw_decl_openpty=yes # OpenBSD 5.0: Fails ac_cv_func__getpty=no ac_cv_func_posix_openpt=no ac_cv_have_decl_openpty=yes gl_cv_have_raw_decl_posix_openpt=no gl_cv_have_raw_decl_openpty=yes # OpenSolaris, Solaris 11: Fail ac_cv_func__getpty=no ac_cv_func_posix_openpt=yes ac_cv_have_decl_posix_openpt=yes ac_cv_have_decl_openpty=no gl_cv_have_raw_decl_openpty=no gl_cv_have_raw_decl_posix_openpt=yes
Re: secure_getenv is broken on FreeBSD.
onsdag den 6 februari 2013 klockan 22:31 skrev Paul Eggert detta: On 02/06/2013 05:10 PM, Mats Erik Andersson wrote: Does not suffice! Same error as before I assume you tried it by hand? Yes. Checking the sequence once more: * Inetutils with gnulib-7517e2 builds on FreeBSD-9.0 since secure_getopt is not used. * Inetutils with gnulib-f65962 is broken on FreeBSD-9.0 since tempname is making secure_getenv mandatory, against my will! * Cherrypicking the __need_getopt fix, removes the error ./getopt.h:199: error: redefinition of 'struct option'. However, the two more serious errors In file included from ./stdlib.h:96, from secure_getenv.c:18: ./unistd.h:548: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'extern' ./stdlib.h:607: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'extern' which appeared with gnulib-f65962 are still present, and they prevent any progress. a sed-scissor reveals that lib/unistd.h and lib/stdlib.h both stumble into problems when evaluating _GL_CXXALIAS_SYS. That sounds like a different issue, which would presumably neeed a different patch. Question: How do I test whether _GL_CXXALIAS_SYS is intelligibly expanded? The build system stands in my way, making the preprocessed intermediaries inaccessible. The two abortive errors are pointing in this direction, though. Regards, Mats Erik Andersson
secure_getenv is broken on FreeBSD.
Hello there, the recent module secure_getenv is broken on FreeBSD 8.2 and 9.0. Extracting from [1] gives the essence: gcc ... -c secure_getenv.c In file included from ./unistd.h:114, from ./stdlib.h:96, from secure_getenv.c:18: ./getopt.h:199: error: redefinition of 'struct option' Clearly the implementation is not protecting previous inclusions sufficiently diligently. On behalf og GNU Inetutils, Mats Erik Andersson [1] http://hydra.nixos.org/build/4007025
Re: secure_getenv is broken on FreeBSD.
onsdag den 6 februari 2013 klockan 16:14 skrev Paul Eggert detta: Thanks for that bug report. I pushed the following into gnulib master, and I hope it fixes that bug. Does it work for you? (It's needed for other reasons anyway, so if it doesn't fix your bug further patches are needed.) Does not suffice! Same error as before, but a sed-scissor reveals that lib/unistd.h and lib/stdlib.h both stumble into problems when evaluating _GL_CXXALIAS_SYS. I am not sure whether it is a usable hint, or a mere decoy. Regards, Mats E A
Multiple argp_fmtstream_puts, etcetera.
Hello there, the recent change to lib/argp-fmtstream.h is breaking the possibility of building GNU inetutils on an i386 system running Debian testing. The cause is multiple definitions of argp_fmtstream_*, as can be inferred from the error text reproduced below. Resetting the source to gnulib-baaadca1 avoids the present issue, i.e., undoing gnulib-b7298256. Best regards, Mats Erik Andersson, on behalf of GNU Inetutils make: Entering directory `/tmp/bygg/src' CCLD hostname ../lib/libgnu.a(argp-fmtstream.o): In function `argp_fmtstream_write': argp-fmtstream.c:(.text+0x0): multiple definition of `argp_fmtstream_write' ../lib/libgnu.a(argp-help.o):argp-help.c:(.text+0x0): first defined here ../lib/libgnu.a(argp-fmtstream.o): In function `argp_fmtstream_puts': argp-fmtstream.c:(.text+0x6a): multiple definition of `argp_fmtstream_puts' ../lib/libgnu.a(argp-help.o):argp-help.c:(.text+0x6a): first defined here ../lib/libgnu.a(argp-fmtstream.o): In function `argp_fmtstream_putc': argp-fmtstream.c:(.text+0xbd): multiple definition of `argp_fmtstream_putc' ../lib/libgnu.a(argp-help.o):argp-help.c:(.text+0xbd): first defined here ../lib/libgnu.a(argp-fs-xinl.o): In function `argp_fmtstream_write': argp-fs-xinl.c:(.text+0x0): multiple definition of `argp_fmtstream_write' ../lib/libgnu.a(argp-help.o):argp-help.c:(.text+0x0): first defined here ../lib/libgnu.a(argp-fs-xinl.o): In function `argp_fmtstream_puts': argp-fs-xinl.c:(.text+0x6a): multiple definition of `argp_fmtstream_puts' ../lib/libgnu.a(argp-help.o):argp-help.c:(.text+0x6a): first defined here ../lib/libgnu.a(argp-fs-xinl.o): In function `argp_fmtstream_putc': argp-fs-xinl.c:(.text+0xbd): multiple definition of `argp_fmtstream_putc' ../lib/libgnu.a(argp-help.o):argp-help.c:(.text+0xbd): first defined here collect2: error: ld returned 1 exit status make: *** [hostname] Fel 1 make: Leaving directory `/tmp/bygg/src'
Re: Multiple argp_fmtstream_puts, etcetera.
torsdag den 27 december 2012 klockan 18:58 skrev Paul Eggert detta: On 12/27/2012 02:47 PM, Mats Erik Andersson wrote: the recent change to lib/argp-fmtstream.h is breaking the possibility of building GNU inetutils on an i386 system running Debian testing. The cause is multiple definitions of argp_fmtstream_*, as can be inferred from the error text reproduced below. Thanks for reporting that. I pushed the following, which should fix it: Compiles correctly now. Thank you!
Re: fstatat.c broken in OpenBSD 4.6
lördag den 29 september 2012 klockan 19:16 skrev Jim Meyering detta: Mats Erik Andersson wrote: fstatat.c:26:10: #include expects FILENAME or FILENAME That appears to be due to a typo. Can you confirm the following fix solves the problem? Works well. The misprint explains why also removal was effective.
Re: readutmp: Non-portable UT_PID use.
Dear all, torsdag den 6 september 2012 klockan 07:59 skrev Jim Meyering detta: Eric Blake wrote: Jim likes favoring over , so I'm swapping this to '0 UT_PID (u)'. Thanks Mats and Eric. That looks fine. With this new readutmp module, I have renovated the talkd server of GNU Inetutils to work correctly for GNU/Linux, DragonflyBSD, both using utmpx, and for OpenBSD, FreeBSD (= 8.3), these using a minimal utmp. Unfortunately, the author of the new utmpx support in FreeBSD 9.0 has implemented so noticeable deviations that the module is now broken for that release. The most obvious cause is that utmpname() or utmpxname() do not exist. The closest replacement is setutxdb(). Furthermore, the functionality of pututxline() is particular to say the least, and the file names are singular: /var/run/utx.active /var/run/utx.lastlogin /var/run/utx.log The module needs some adaption in order to fit well enough. Best regards, Mats Erik Andersson, on behalf of GNU Inetutils
readutmp: Non-portable UT_PID use.
Dear all, the module readutmp is broken for the standard use read_utmp(..., READ_UTMP_USER_PROCESS | READ_UTMP_CHECK_PIDS) for all releases of FreeBSD until 8.3, and all OpenBSD ever released. The reason is that those systems do not provide `utmp.ut_pid', thus making the macro UT_PID(u) identical to naught, and then turning the predicate UT_PID (u) = 0 found in desirable_utmp_entry(), into a permanent true clause. This makes desirable_utmp_entry() discard every legitimate user's UTMP entry for said BSD releases. NetBSD and DragonflyBSD are not touched by this malfunction. Below are two suggestions that work equally well on Debian Squeeze and on OpenBSD 4.6. Best regards, Mats Erik Andersson From 36e7aa46f858fb7ae96fa7047ff161da8a57607a Mon Sep 17 00:00:00 2001 From: Mats Erik Andersson g...@gisladisker.se Date: Wed, 5 Sep 2012 00:03:32 +0200 Subject: [PATCH] readutmp.c: Non-portable use of UT_PID. * lib/readutmp.c [HAVE_STRUCT_XTMP_UT_PID]: Check OPTIONS with READ_UTMP_CHECK_PIDS only if `utmp.ut_pid' exists. --- lib/readutmp.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/lib/readutmp.c b/lib/readutmp.c index f89dd68..8266e40 100644 --- a/lib/readutmp.c +++ b/lib/readutmp.c @@ -67,11 +67,13 @@ desirable_utmp_entry (STRUCT_UTMP const *u, int options) bool user_proc = IS_USER_PROCESS (u); if ((options READ_UTMP_USER_PROCESS) !user_proc) return false; +#if HAVE_STRUCT_XTMP_UT_PID if ((options READ_UTMP_CHECK_PIDS) user_proc (UT_PID (u) = 0 || (kill (UT_PID (u), 0) 0 errno == ESRCH))) return false; +#endif return true; } -- 1.7.2.5 From 60fcbc2763d6b657c62b921ed263fbd5a0794df6 Mon Sep 17 00:00:00 2001 From: Mats Erik Andersson g...@gisladisker.se Date: Wed, 5 Sep 2012 21:51:39 +0200 Subject: [PATCH] readutmp.c: Portability improved UT_PID use. * lib/readutmp.c (desirable_utmp_entry) READ_UTMP_CHECK_PIDS: Use `UT_PID (u) 0' as absolute condition. --- lib/readutmp.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/readutmp.c b/lib/readutmp.c index f89dd68..2ac803b 100644 --- a/lib/readutmp.c +++ b/lib/readutmp.c @@ -69,8 +69,8 @@ desirable_utmp_entry (STRUCT_UTMP const *u, int options) return false; if ((options READ_UTMP_CHECK_PIDS) user_proc - (UT_PID (u) = 0 - || (kill (UT_PID (u), 0) 0 errno == ESRCH))) + UT_PID (u) 0 + (kill (UT_PID (u), 0) 0 errno == ESRCH)) return false; return true; } -- 1.7.2.5
Piping sed stalls on OpenSolaris 2010.03
Dear all,
at some stage the generated make file lib/Makefile began using
a three-member pipe for sed in order to generate lib/unistd.h and
lib/wchar.h. This change is not portable to OpenSolaris 2010.03
using snv_134, since make as well as gmake stalls at
GEN unistd.h
GEN wchar.h
and only at these. The change took place somewhere between the release
of inetutils-1.8 and inetutils-1.9.1! However, neither NexentaCore with
snv_134f, nor OpenIndiana are affected by the present issue.
The problem is that modules/unistd and modules/wchar are, as sole
modules, implementing a rewrite action using the template model
{ echo A comment;
sed -e 's,re,txt,g' file |
sed -e 's,re2,txt2,g' |
sed -e 's,re3,txt3,g'; } outfile
All other modules implement pipes using one or two levels, not three.
This three level construct stalls on OpenSolaris 2010.03, presumably
waiting for input, since the expected output file contains only the
comment at inspection time after abortion. Rewriting the make file
to implement the shorter pipe
{ echo A comment;
sed -e 's,re,txt,g' file tmpfile ;
sed -e 's,re2,txt2,g' tmpfile |
sed -e 's,re3,txt3,g'; } outfile
fully resolves the issue with said OpenSolaris variant.
It is conceivable that the issue arises since the Korn shell
does not execute the final pipe member in a subshell, but since
neither OpenBSD, nor some other OpenIndiana/OpenSolaris systems
display the same behaviour, the matter is convoluted! Still,
I recommend a reformulation of the sed-scripting as found in
modules/unistd and modules/wchar.
Best regards,
Mats Erik Andersson, ex officio GNU Inetutils.
Re: Piping sed stalls on OpenSolaris 2010.03
fredag den 13 april 2012 klockan 07:59 skrev Paul Eggert detta:
On 04/13/2012 03:32 AM, Mats Erik Andersson wrote:
{ echo A comment;
sed -e 's,re,txt,g' file |
sed -e 's,re2,txt2,g' |
sed -e 's,re3,txt3,g'; } outfile
All other modules implement pipes using one or two levels, not three.
This three level construct stalls on OpenSolaris 2010.03, presumably
waiting for input
This sounds like a serious bug with OpenSolaris.
But perhaps it is a bug in the script.
The relevant trace part is the one given below.
Prior to the this /usr/gnu/bin/sed, i.e., /usr/bin/gsed
has been put to work, using ksh93 and gmake. Same brk lines
were removed, and my identification of I/O has been inserted.
I find this inconclusive, except that the expected write(2)
never appears.
Best regards,
Mats E A
MEA: Comments as made by Mats Erik Andersson
14115: write(1, o s e ,c l o s e .., 5120)= 5120
MEA: Writing for line 299, lib/unistd.in.h
14115: read(0, r f o r p o r t a b.., 4096) = 4096
MEA: Reading from line 243 or 481, lib/unistd.in.h
14115: read(0, E T C W D\n _ G L _ W A.., 4096) = 4096
MEA: Reading from line 598, lib/unistd.in.h
14115: write(1, o i d _ g l _ u n r e.., 5120)= 5120
MEA: Writing for line 466, lib/unistd.in.h
14115: read(0, c a s t , b e c a u s.., 4096) = 4096
MEA: Reading from line 708 or later, lib/unistd.in.h
14054: waitid(P_ALL, 0, 0x08046B70, WEXITED|WTRAPPED) (sleeping...)
14077: waitid(P_ALL, 0, 0x08046AE0, WEXITED|WTRAPPED) (sleeping...)
14099: waitid(P_ALL, 0, 0x08045070, WEXITED|WTRAPPED|WSTOPPED|WCONTINUED)
(sleeping...)
14107: waitid(P_ALL, 0, 0x08044310, WEXITED|WTRAPPED|WSTOPPED|WCONTINUED)
(sleeping...)
14109: waitid(P_ALL, 0, 0x080469C0, WEXITED|WTRAPPED) (sleeping...)
14117: read(0, 0xFEF6AFD8, 1024) (sleeping...)
14119: read(0, 0x0809991C, 5120) (sleeping...)
14111: waitid(P_ALL, 0, 0x08042B50, WEXITED|WTRAPPED|WSTOPPED|WCONTINUED)
(sleeping...)
14115: write(1, 0x080A462C, 5120) (sleeping...)
14119: Received signal #2, SIGINT, in read() [default]
14119: read(0, 0x0809991C, 5120) Err#4 EINTR
14109: Received signal #2, SIGINT, in waitid() [caught]
14109: waitid(P_ALL, 0, 0x080469C0, WEXITED|WTRAPPED) Err#91 ERESTART
14109: lwp_sigmask(SIG_SETMASK, 0x0002, 0x) = 0xFFBFFEFF
[0x]
readline: Adaption for NetBSD.
Dear all, I would like to propose a modification to the M4 file for the module `readline', which provides a functional detection also for NetBSD. The main obstacle is that NetBSD uses the library `editline', and offer readline functionality as a wrapper based on said library. The present state of the Gnulib module is not able to detect this properly. We have been using a somewhat similar local script in GNU Inetutils, successfully since four months, but I still had to introduce changes in order to cope with caching issues. I found that AC_CACHE_CHECK must be performed prior to AC_LIB_LINKFLAGS_BODY, since `-lreadline' is no longer the basis. Also, the string `, requires ...' must be removed to avoid duplicates; removed once applied, that is. (Visible in OpenBSD.) There ought to be more room for better caching, but this is a functional starter. It behaves correctly for GNU/Linux with and without `readline/readline.h'. Best regards, Mats Erik Andersson, for GNU Inetutils diff --git a/m4/readline.m4 b/m4/readline.m4 index 903886d..e2c12cc 100644 --- a/m4/readline.m4 +++ b/m4/readline.m4 @@ -1,4 +1,4 @@ -# readline.m4 serial 10 +# readline.m4 serial 11 dnl Copyright (C) 2005-2006, 2009-2012 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -13,18 +13,18 @@ AC_DEFUN([gl_FUNC_READLINE], AC_REQUIRE([AC_LIB_PREPARE_PREFIX]) AC_REQUIRE([AC_LIB_RPATH]) - dnl Search for libreadline and define LIBREADLINE, LTLIBREADLINE and - dnl INCREADLINE accordingly. - AC_LIB_LINKFLAGS_BODY([readline]) + AC_CACHE_CHECK([for readline], [gl_cv_lib_readline], [ +dnl Search for libreadline and define LIBREADLINE, LTLIBREADLINE and +dnl INCREADLINE accordingly. +AC_LIB_LINKFLAGS_BODY([readline]) - dnl Add $INCREADLINE to CPPFLAGS before performing the following checks, - dnl because if the user has installed libreadline and not disabled its use - dnl via --without-libreadline-prefix, he wants to use it. The AC_LINK_IFELSE - dnl will then succeed. - am_save_CPPFLAGS=$CPPFLAGS - AC_LIB_APPENDTOVAR([CPPFLAGS], [$INCREADLINE]) +dnl Add $INCREADLINE to CPPFLAGS before performing the following checks, +dnl because if the user has installed libreadline and not disabled its use +dnl via --without-libreadline-prefix, he wants to use it. The AC_LINK_IFELSE +dnl will then succeed. +am_save_CPPFLAGS=$CPPFLAGS +AC_LIB_APPENDTOVAR([CPPFLAGS], [$INCREADLINE]) - AC_CACHE_CHECK([for readline], [gl_cv_lib_readline], [ gl_cv_lib_readline=no am_save_LIBS=$LIBS dnl On some systems, -lreadline doesn't link without an additional @@ -53,12 +53,31 @@ AC_DEFUN([gl_FUNC_READLINE], LIBS=$am_save_LIBS ]) + dnl In case of failure, examine whether libedit can act + dnl as replacement. Small NetBSD systems use editline + dnl as wrapper for readline. + if test $gl_cv_lib_readline = no; then +am_save_LIBS=$LIBS +LIBS=$am_save_LIBS -ledit -ltermcap +AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include stdio.h +#include readline/readline.h]], + [[readline((char*)0);]])], + [gl_cv_lib_readline=yes]) +LIBS=$am_save_LIBS +dnl This wrapper does not reference libreadline at all. +dnl Set the correct linking according to editline(3). +LIBREADLINE='-ledit -ltermcap' +LTLIBREADLINE='-ledit -ltermcap' + fi + if test $gl_cv_lib_readline != no; then AC_DEFINE([HAVE_READLINE], [1], [Define if you have the readline library.]) extra_lib=`echo $gl_cv_lib_readline | sed -n -e 's/yes, requires //p'` if test -n $extra_lib; then LIBREADLINE=$LIBREADLINE $extra_lib LTLIBREADLINE=$LTLIBREADLINE $extra_lib + # Prevent duplicates next time around. + gl_cv_lib_readline=`echo $gl_cv_lib_readline | sed -e 's/\(yes\).*/\1/'` fi AC_MSG_CHECKING([how to link with libreadline]) AC_MSG_RESULT([$LIBREADLINE])
Format poissoning in argp-parse.c.
Dear all, there is a potential attack vector, and easily avoidable, in lib/argp-parser.c of GNUlib. This came to my attention by the modifications Guillem Jover [1] does to GNU Inetutils' source archives. The relevant change is reproduced below. (Yes, I will act myself on all those changes that only concern our own source!) The problem is that the result of dgettext() is fed directly as format string into __argp_error(). A benevolent translator would produce a constant string without format escapes, but I know from practice that the depreciated format %q will cause OpenSolaris to segfault, so a malevolent attacker could in fact cause some damage. Best regards, Mats Erik Andersson [1] http://patch-tracker.debian.org/patch/series/dl/inetutils/2:1.9-1/71_ftbfs_format_security.patch diff --git a/lib/argp-parse.c b/lib/argp-parse.c index 39b8336..d9f08b6 100644 --- a/lib/argp-parse.c +++ b/lib/argp-parse.c @@ -154,7 +154,7 @@ argp_version_parser (int key, char *arg, struct argp_state *state) else if (argp_program_version) fprintf (state-out_stream, %s\n, argp_program_version); else -__argp_error (state, dgettext (state-root_argp-argp_domain, +__argp_error (state, %s, dgettext (state-root_argp-argp_domain, (PROGRAM ERROR) No version known!?)); if (! (state-flags ARGP_NO_EXIT)) exit (0);
arpg-help: Warning with NetBSD and amd64.
Dear all, I observe a warning for NetBSD 5.1 on amd64, a warning which is absent for i386. Its effect is to disable two assertion statements. assert (num_entries = SIZE_MAX / sizeof (struct hol_entry)); CC argp-help.o argp-help.c: In function 'make_hol': argp-help.c:467: warning: comparison is always true due to limited range of data type argp-help.c: In function 'hol_append': argp-help.c:883: warning: comparison is always true due to limited range of data type CC argp-parse.o A corresponding message does not appear for GNU/kFreeBSD, flavour amd64. Best regards, Mats Erik Andersson, on behalf of GNU Inetutils.
Re: libgnu: rpl_getcwd broken on OpenBSD 4.6
fredag den 18 november 2011 klockan 18:07 skrev Paul Eggert detta: Thanks for the further details about the problem. [...] Anyway, I've verified that the following patch fixes the bug on Solaris 8, so I've pushed it into gnulib. Can you please try it for OpenBSD 4? Thanks. I'll also CC: this to Kai Habel, as I think it'll fix his problem too. Issue resolved for OpenBSD!
Re: libgnu: rpl_getcwd broken on OpenBSD 4.6
torsdag den 17 november 2011 klockan 22:02 skrev Paul Eggert detta: On 11/17/11 13:51, Mats Erik Andersson wrote: Why is your code not falling back to the native getcwd()? Presumably the OpenBSD getcwd has some sort of incompatibility or bug, and gnulib's trying to work around it. Without more information, it's hard to say for sure.. Is the complete source code and build log available? It has worked perfectly until yesterday, and it so happens that GNUlib saw som alteration to the getcwd module the very same day! I cannot say with certainty which working GNUlib commit I had before pulling in the latest versin yesterday afternoon. I will back track the failure more, but the two culprits were named in the first message. We have not changed any relevant code in our FTP client (which triggered this error) for quite some time. Regards Mats E A
Re: libgnu: rpl_getcwd broken on OpenBSD 4.6
Dear Paul, fredag den 18 november 2011 klockan 10:23 skrev Paul Eggert detta: On 11/18/11 02:25, Mats Erik Andersson wrote: I will back track the failure more Thanks. A similar problem was recently reported for octave on mingw; see http://lists.gnu.org/archive/html/bug-gnulib/2011-11/msg00237.html. That bug report had a bit more information, enough so that I committed a partial fix for it; see http://lists.gnu.org/archive/html/bug-gnulib/2011-11/msg00245.html. We're awaiting more information there. Quite possibly my commit will affect OpenBSD too, so you probably want to try the updated gnulib when you investigate the failure. My original errors were verbatim to msg00237.html, modulo elementary notions. After your pushed commit the issue with fdopendir() is resolved, but the fstatat() error remains. The following is my manual traceback. Regards, Mats E A /* Build steps in lib/, i.e., GNU lib */ CC fdopendir.o CC forkpty.o CC fstatat.o CC getcwd.o CC getcwd-lgpl.o /* Build step for GNU Inetutils */ CCLD ftp cmds.o(.text+0x194): In function `another': /tmp/inetutils/ftp/cmds.c:171: warning: strcpy() is almost always misused, please use strlcpy() cmds.o(.text+0x1578): In function `remglob': /tmp/inetutils/ftp/cmds.c:967: warning: strcat() is almost always misused, please use strlcat() cmds.o(.text+0x123): In function `another': /tmp/inetutils/ftp/cmds.c:145: warning: sprintf() is often misused, please use snprintf() ../lib/libgnu.a(getcwd.o)(.text+0x283): In function `rpl_getcwd': /tmp/inetutils/lib/getcwd.c:300: undefined reference to `fstatat' collect2: ld returned 1 exit status *** Error code 1 /* * Code analysis of GNU lib for OpenBSD 4.6. */ /* * config.h */ #define GNULIB_OPENAT 1 #define GNULIB_TEST_OPENAT 1 /* #undef HAVE_OPENAT */ /* #undef HAVE_RAW_DECL_OPENAT */ #define GNULIB_FSTATAT 1 #define GNULIB_TEST_FSTATAT 1 /* #undef HAVE_FSTATAT */ /* #undef HAVE_RAW_DECL_FSTATAT */ /* #undef HAVE_WORKING_FSTATAT_ZERO_FLAG */ /* * lib/getcwd.c */ #if defined HAVE_OPENAT || defined GNULIB_OPENAT # define HAVE_OPENAT_SUPPORT 1 #else # define HAVE_OPENAT_SUPPORT 0 #endif #if HAVE_OPENAT_SUPPORT entry_status = fstatat (fd, d-d_name, st, AT_SYMLINK_NOFOLLOW); #else Conclusion: The conditional defined HAVE_OPENAT || defined GNULIB_OPENAT sets HAVE_OPENAT_SUPPORT = 1, thus invoking a call to fstatat(), but is not accompanied by the relevant module inclusion of fstatat. The module is built, but not automatically included in libgnu.a.
Re: libgnu: rpl_getcwd broken on OpenBSD 4.6
Dear Paul, fredag den 18 november 2011 klockan 12:52 skrev Paul Eggert detta: On 11/18/11 12:07, Mats Erik Andersson wrote: The [fstatat] module is built, but not automatically included in libgnu.a. OK, thanks. Now we need to find out why that problem is happening. Recently Bruno Haible made several platform tests of our snapshot: http://lists.gnu.org/archive/html/bug-inetutils/2011-11/msg1.html He mentioned fstatat issues in Mac OX X, FreeBSD, mingw. The issue in OpenBSD was masked by another omission. The fstatat module lists this in its configure.ac section: gl_FUNC_FSTATAT if test $HAVE_FSTATAT = 0 || test $REPLACE_FSTATAT = 1; then AC_LIBOBJ([fstatat]) fi AC_REQUIRE([AC_C_INLINE]) dnl because 'inline' is used in lib/openat.h gl_MODULE_INDICATOR([fstatat]) dnl for lib/openat.h gl_SYS_STAT_MODULE_INDICATOR([fstatat]) The AC_LIBOBJ([fstatat]) should put the fstatat module into libgnu.a. Can you see why it is not having its intended effect? You might look into config.log for starters. No macro fstatat is ever defined; see below. Also, can you double-check libgnu.a for all occurrences of fstatat and/or rpl_fstatat? Something like nm -o libgnu.a | grep fstatat, or whatever the moral equivalent of that is, on OpenBSD. $ nm -o lib/libgnu.a | grep fstatat fstatat.o: U __errno fstatat.o: U __guard fstatat.o: U __stack_smash_handler fstatat.o: U fchdir fstatat.o: U free fstatat.o: U free_cwd fstatat.o: F fstatat.c fstatat.o: U lstat fstatat.o: U openat_proc_name fstatat.o: U openat_restore_fail fstatat.o: U openat_save_fail fstatat.o: U restore_cwd fstatat.o: T rpl_fstatat fstatat.o: U save_cwd fstatat.o: U stat getcwd.o: U fstatat Intermission: rpl_fstatat() exists, but not fstatat(). /* * config.h */ #define GNULIB_FSTATAT 1 #define GNULIB_TEST_FSTATAT 1 /* #undef HAVE_FSTATAT */ /* #undef HAVE_RAW_DECL_FSTATAT */ /* #undef HAVE_WORKING_FSTATAT_ZERO_FLAG */ /* * lib/fstatat.c */ # if ! HAVE_WORKING_FSTATAT_ZERO_FLAG # define AT_FUNC_NAME rpl_fstatat # else # define AT_FUNC_NAME fstatat # endif Intermission: This is probably broken. I recommend a positive logic: # if HAVE_WORKING_FSTATAT_ZERO_FLAG # define AT_FUNC_NAME fstatat # else # define AT_FUNC_NAME rpl_fstatat # endif At least an improved detection is needed in negative logic: # if ! defined HAVE_WORKING_FSTATAT_ZERO_FLAG \ || ! HAVE_WORKING_FSTATAT_ZERO_FLAG # define AT_FUNC_NAME rpl_fstatat # else # define AT_FUNC_NAME fstatat # endif Now take notice of REPLACE_FSTATAT in the build file after configuration. /* * Makefile */ GNULIB_FSTATAT = 1 HAVE_FSTATAT = 0 REPLACE_FSTATAT = 0 /* * lib/sys/stat.h */ #if 1 /* GNULIB_FSTATAT */ # if 0 /* REPLACE_FSTATAT */ # if !(defined __cplusplus defined GNULIB_NAMESPACE) # undef fstatat # define fstatat rpl_fstatat # endif In effect, this says /* rpl_fstatat() is never replacing fstatat() */ #if 0 # define fstatat rpl_fstatat #endif Conclusion: The computation of REPLACE_FSTATAT is broken. Should it be something like the following? /* * lib/sys_stat.in.h */ #if @GNULIB_FSTATAT@ # if @REPLACE_FSTATAT@ || ! @HAVE_FSTATAT@ Best regards, Mats E A
libgnu: rpl_getcwd broken on OpenBSD 4.6
(CC to bug-inetutils) Today the compilation of libgnu for GNU Inetutils is broken in rpl_getcwd on OpenBSD 4.6. The code is correct for GNU/Linux, GNU/kFreeBSD, and GNU/OpenSolaris, but not OpenBSD. The linker is not able to detect lib/getcwd.c: 246: undefined reference to 'fdopendir' lib/getcwd.c: 300: undefined reference to 'fstatat' Why is your code not falling back to the native getcwd()? Best regards, Mats Erik Andersson, on behalf of GNU Inetutils
Portability issue for error_tail().
Dear all, I have found an exceptional portability issue when building GNU lib for NexentaCore/i386-pc-solaris2.11. Said system lacks the library call error (status, errno, format, ...) which therefore is brought in from GNU lib. However, should a programmer happen to erroneously write error (EXIT_FAILURE, EPERM, NULL); nothing serious will happen on GNU/Linux with Glibc, but for NexentaCore the GNU lib code will produce a segmentation fault in gnulib/error.c:265 (error_tail) vfprintf(stderr, NULL, args) Seemingly the Solaris library can not recover from a NULL format string. Some sort of runtime check might be of benefit in error_tail() to prevent this crash. Observe that the setting #undef _LIBC is in effect on this particular OpenSolaris instance, and probably on all such systems. Best regards, Mats Erik Andersson, GNU Inetutils
Incorrect detection of member sa_len.
Dear all, [resending a seemingly lost message] the m4 helper in `m4/getaddrinfo.m4` is incorrectly implementing a test whether `struct sockaddr` contains a member `sa_len`. Any BSD system must include `sys/types.h` in order for the test code to deliver a trustworthy answer. As always this header must precede `sys/socket.h` on any BSD system. In fact, this flawed test takes precedence over an otherwise sound and correct test implemented in GNU Inetutils, thus producing a false negative on OpenBSD and FreeBSD. It is easily observered that, after executing the bootstrap script shipped for GNU Inetutils, the resulting `configure` contains two tests for `sa_len`, one correct and the other wrong. Unluckily the wrong one gets to determine `config.h` Best regards, Mats Erik Andersson, member of GNU Inetutils diff --git a/m4/getaddrinfo.m4 b/m4/getaddrinfo.m4 index 94c276f..2662093 100644 --- a/m4/getaddrinfo.m4 +++ b/m4/getaddrinfo.m4 @@ -105,7 +105,9 @@ AC_DEFUN([gl_PREREQ_GETADDRINFO], [ dnl Including sys/socket.h is wrong for Windows, but Windows does not dnl have sa_len so the result is correct anyway. - AC_CHECK_MEMBERS([struct sockaddr.sa_len], , , [#include sys/socket.h]) + AC_CHECK_MEMBERS([struct sockaddr.sa_len], , , [ +#include sys/types.h +#include sys/socket.h]) AC_CHECK_HEADERS_ONCE([netinet/in.h])
Re: An issue with unlocked-io.h and bootstrapping.
onsdag den 3 november 2010 klockan 10:53 skrev Jim Meyering detta: Mats Erik Andersson wrote: Hello, I have made a strange observation concerning lib/unlocked-io.h which appears when running the bootstrap script for GNU Inetutils. [...] remains, which is pointing at the non-existent location ../gnulib/unlocked-io.h Thanks for the report. There is already code in gnulib's bootstrap script designed to remove dangling symlinks from m4/ and lib/-style directories: # Remove any dangling symlink matching *.m4 or *.[ch] in some # gnulib-populated directories. Such .m4 files would cause aclocal to fail. # The following requires GNU find 4.2.3 or newer. Considering the usual # portability constraints of this script, that may seem a very demanding # requirement, but it should be ok. Ignore any failure, which is fine, # since this is only a convenience to help developers avoid the relatively # unusual case in which a symlinked-to .m4 file is git-removed from gnulib # between successive runs of this script. find $m4_base $source_base \ -depth \( -name '*.m4' -o -name '*.[ch]' \) \ -type l -xtype l -delete /dev/null 21 If it's not working for you, perhaps you've changed the definition of source_base or you're using an inadequate version of find. Otherwise, please investigate. The bootstrapping is performed on Debian GNU/Linux testing/Squeeze, so I doubt that find is at fault. I will try to dig further though. It did not matter if I brought the tree using rsync -Ca to OpenBSD, GNU/kFreeBSD, or GNU/Linux. The same error occurred. Best regards.
An issue with unlocked-io.h and bootstrapping.
Hello, I have made a strange observation concerning lib/unlocked-io.h which appears when running the bootstrap script for GNU Inetutils. Until very recently, unlocked-io was included as a dependency in our bootstrap.conf. Upon my complaint, Alfred M. Szmidt remove that entry, after which the following issue vanished completely. Therefore we suspect there be a bug in GNUlib on this matter. Now, running bootstrap on a fresh cheackout of GNU Inetutils, and then happily running rsync -Ca . ../temp/ one would expect a source tree where configuration and compilation works. Right? But alas, it does not. An empty soft link lib/unlocked-io.h remains, which is pointing at the non-existent location ../gnulib/unlocked-io.h Performing a full copy, or using tar/cpio pipes, will of course work, but not the pruning incvolved in rsync -Ca. Best regards, Mats Erik Andersson (member of GNU Inetutils)
On OpenBSD and if_freenameindex(3).
Hello, influenced by an exchange with Simon Josefsson, where we have on issue with the present matter in GNU Inetutils, I would like to mention this subject, since GNUlib seems not to resolve the matter to our satisfaction! In OpenBSD (definitely in 4.6) there is a POSIX violation, quoting Simon here, since the header file states ### /usr/include/net/if.h #define if_freenameindex(x) free(x) This macro causes difficulties for me in inetutils/ifconfig/if_index.*. I am told the POSIX specification demands if_freenameindex(3) to be a proper function. Is this situation covered for in GNUlib, or should an increased use of conditionals on HAVE_STRUCT_IF_NAMEINDEX be the intended way to overcome this issue? Best regards, Mats E A
Re: On OpenBSD and if_freenameindex(3).
tisdag den 21 september 2010 klockan 14:22 skrev Simon Josefsson detta: As an initial response to this problem, I'm installing a self check of the net/if.h interface. See below. Mats, if you could quote the compiler errors you get when building the self-check below on OpenBSD, that would be useful. The next step is to see how gnulib can provide a replacement that works on various systems. Perhaps OpenBSD isn't the only system not working here. /Simon Quickest reply without need to test compile: #include sys/types.h #include sys/socket.h #include net/if.h is the mandatory order for OpenBSD! Lest config.h knows that, the test must augmented. Will return later for more info. Mats E A
Re: On OpenBSD and if_freenameindex(3).
tisdag den 21 september 2010 klockan 15:52 skrev Simon Josefsson detta: Mats Erik Andersson mats.anders...@gisladisker.se writes: tisdag den 21 september 2010 klockan 14:22 skrev Simon Josefsson detta: As an initial response to this problem, I'm installing a self check of the net/if.h interface. See below. Mats, if you could quote the compiler errors you get when building the self-check below on OpenBSD, that would be useful. The next step is to see how gnulib can provide a replacement that works on various systems. Perhaps OpenBSD isn't the only system not working here. /Simon Quickest reply without need to test compile: #include sys/types.h #include sys/socket.h #include net/if.h is the mandatory order for OpenBSD! Lest config.h knows that, the test must augmented. Will return later for more info. That's the first thing a gnulib net/if.h replacement header should provide then, since I believe the net/if.h header needs to be self-contained according to POSIX. It would be interesting to see if the self tests works even if you make the above modification, though. Also try running it with a command line parameter and check that it prints all the host interfaces on your machine. My protocol report_for_test_net_if.txt is attached. I am not able to compile the test into any working executable for OpenBSD 4.6. The mishaps are due to if_freenameindex. In contrast, the original text works for Debian Squeeze, of course. Mats E A Test protocol of test-net_if.c on OpenBSD 4.6 === Common compiling step $ gcc test-net_if.c Line numbering in printouts is consistent since all of my inclusion additions were inserted once and then deactivated using // as protector. ## ## Only config.h removed from the suggested module. ## In file included from test-net_if.c:22: /usr/include/net/if.h:240: error: `AF_MAX' undeclared here (not in a function) /usr/include/net/if.h:578: error: field `ifru_addr' has incomplete type /usr/include/net/if.h:579: error: field `ifru_dstaddr' has incomplete type /usr/include/net/if.h:580: error: field `ifru_broadaddr' has incomplete type /usr/include/net/if.h:598: error: field `ifra_addr' has incomplete type /usr/include/net/if.h:599: error: field `ifra_dstaddr' has incomplete type /usr/include/net/if.h:601: error: field `ifra_mask' has incomplete type /usr/include/net/if.h:639: error: field `addr' has incomplete type /usr/include/net/if.h:640: error: field `dstaddr' has incomplete type In file included from /usr/include/net/if.h:657, from test-net_if.c:22: /usr/include/net/if_arp.h:79: error: field `arp_pa' has incomplete type /usr/include/net/if_arp.h:80: error: field `arp_ha' has incomplete type test-net_if.c: In function `main': test-net_if.c:30: error: `if_freenameindex' undeclared (first use in this function) test-net_if.c:30: error: (Each undeclared identifier is reported only once test-net_if.c:30: error: for each function it appears in.) ## ## Addition: ## ## #include sys/types.h ## In file included from test-net_if.c:22: /usr/include/net/if.h:240: error: `AF_MAX' undeclared here (not in a function) /usr/include/net/if.h:578: error: field `ifru_addr' has incomplete type /usr/include/net/if.h:579: error: field `ifru_dstaddr' has incomplete type /usr/include/net/if.h:580: error: field `ifru_broadaddr' has incomplete type /usr/include/net/if.h:598: error: field `ifra_addr' has incomplete type /usr/include/net/if.h:599: error: field `ifra_dstaddr' has incomplete type /usr/include/net/if.h:601: error: field `ifra_mask' has incomplete type /usr/include/net/if.h:639: error: field `addr' has incomplete type /usr/include/net/if.h:640: error: field `dstaddr' has incomplete type In file included from /usr/include/net/if.h:657, from test-net_if.c:22: /usr/include/net/if_arp.h:79: error: field `arp_pa' has incomplete type /usr/include/net/if_arp.h:80: error: field `arp_ha' has incomplete type test-net_if.c: In function `main': test-net_if.c:30: error: `if_freenameindex' undeclared (first use in this function) test-net_if.c:30: error: (Each undeclared identifier is reported only once test-net_if.c:30: error: for each function it appears in.) ## ## Addition: ## ## #include sys/socket.h ## In file included from test-net_if.c:21: /usr/include/sys/socket.h:152: error: syntax error before u_int8_t /usr/include/sys/socket.h:170: error: syntax error before u_int8_t /usr/include/sys/socket.h:173: error: syntax error before u_int64_t /usr/include/sys/socket.h:239: error: syntax error before uid_t /usr/include/sys/socket.h:244: error: syntax error before gid_t /usr/include/sys/socket.h:372: error: syntax error before socklen_t /usr/include/sys/socket.h:376: error: syntax error before socklen_t /usr/include/sys/socket.h:398: error: syntax error before socklen_t /usr/include/sys/socket.h:454: error: syntax error before caddr_t /usr/include/sys/socket.h
Re: On OpenBSD and if_freenameindex(3).
tisdag den 21 september 2010 klockan 22:46 skrev Simon Josefsson detta: Mats Erik Andersson mats.anders...@gisladisker.se writes: My protocol report_for_test_net_if.txt is attached. I am not able to compile the test into any working executable for OpenBSD 4.6. The mishaps are due to if_freenameindex. Thanks, this is very useful. Is there a if_freenameindex symbol in the OpenBSD libc? Use 'nm' on /lib/libc.so to test. If there is, it might be an InetUtils bug after all, since POSIX allows if_freenameindex to ALSO be defined as a CPP macro. Negative answer, no symbol if_freenameindex present in libc.so.51.0. Of course the symbols if_nameindex, if_nametoindex, and if_indextoname are present. Therefore not even the relaxed demand that Bruno Haible mentioned is satisfied. POSIX hin und POSIX her, wen kümmert's? Regards, Mats E A
Failure of IPv6 detection for BSD.
Hello,
in detecting the size of struct sockaddr_in6 for BSD, in my
case OpenBSD 4.6, the inclusion of sys/types.h is mandatory.
Thus the test case must read
#include sys/types.h
#include netinet/in.h
int
main (void)
{
if (sizeof (struct sockaddr_in6))
return 0;
else
return 0;
}
Since sys/types.h is missing in the configure script
built using bootstrap, the result is that OpenBSD is
judged as being inferior, according to config.log:
configure:31742: WARNING: IPv6 support not available, disabling IPv6
This is most unfortunate!
Best regards,
Mats E Andersson
Re: Failure of IPv6 detection for BSD.
Dear Bruno, lördag den 18 september 2010 klockan 16:45 skrev Bruno Haible detta: Hello Mats, ... All uses of netinet/in.h in gnulib's *.m4 files and module descriptions are preceded with an include of sys/types.h. So, either you must be using an outdated gnulib, or the .m4 file with the configure test that you mention must come from outside gnulib. Well, bootstrap was run for GNU Inetutils on Debian GNU/Linux Squeeze two days ago, then the resulting tree was moved to OpenBSD 4.6 where the configure script was included. The versions of the Autotools are too old in OpenBSD, so I need to go via GNU/Linux to generate the configure script. Today I wanted to now why GNU Inetutils did not want to build Ping6 on OpenBSD, while is did so very nicely in GNU/Linux. My analysis led me this find. In particular, config.log from GNU/Linux contains #define IPV6 1 while the corresponding statement is missing in OpenBSD. The failing test is configure:31699: checking for struct sockaddr_in6 and it fails with 23 [sic] complaints if the kind error: syntax error before in_addr_t, u_int8_t, etcetera, which is obviously caused by the lacking sys/types.h. To be honest, I can not tell if the shortcoming is due to Autotools or due to bootstrap/GNUlib. You are much better equipped to decide that than I will ever be. Best regards, Mats E A
Re: Failure of IPv6 detection for BSD.
Dear Bruno, lördag den 18 september 2010 klockan 17:19 skrev Bruno Haible detta: Mats Erik Andersson wrote: The failing test is configure:31699: checking for struct sockaddr_in6 configure is generared from a multitude of files. If you grep for 'for struct sockaddr_in6' in all *.m4, configure.ac, and configure.in files in that project (or even everywhere on your system), where do you find the source code of that test? The only hits are in config.log of different origins. Searches in most parts of the file systems for Debian GNU/Linux and OpenBSD disclose this! A further analysis points to this test ### inetutils/configure.ac, line 330 ### if test ! X$ipv6 = Xno test $working_ipv6 = Xyes; then AC_CHECK_TYPE(struct sockaddr_in6, , working_ipv6=no, [#include netinet/in.h]) fi When I take the expanded test in configure and I insert the missing header file, like ### inetutils/configure, line 31698 ### if test ac_fn_c_check_type $LINENO struct sockaddr_in6 \ ac_cv_type_struct_sockaddr_in6 \ #include sys/types.h #include netinet/in.h if test ... else fi fi then I _do_ get the successful detection. As a result the __new__ config.log contains #define IPV6 1 which I was missing in the setup generated by bootstrap. With this new knowledge I observe many tests in configure.ac that encapsulate my manual insertion in a conditional on HAVE_SYS_TYPES_H. This is clearly needed also in sensing struct sockaddr_in6. It seems to me that the blame must go to autoconf. Right? Or is the template configure.ac maintained by GNU Inetutils incomplete? Regards, Mats
[patch] lib/login_tty.c: Controlling terminal in OpenBSD.
Hello again,
a new observation from my bug chasing.
The assumptions made in lib/login_tty.c, which are set
on display as inherited from Solaris, these prerequisites
are __NOT__ sufficient for OpenBSD. The reason is clearly
displayed in tty(4) of OpenBSD origin. Only after an ioctl
call with TIOCSCTTY is the controlling terminal established.
The patch below has been successfully applied to OpenBSD 4.6,
and was tested in order to build inetutils-telnetd.
Without my changes the telnet session does not get a
controlling terminal, as ksh complains loudly about,
and in addition the deactivation of echoing fails
during password passing. When the patch is applied,
the echoing stops and the expected ctty is present,
since ksh stops complaining about crippled job-control!
Best regards,
Mats Erik Andersson, fil. dr
_
diff --git a/lib/login_tty.c b/lib/login_tty.c
index 0403391..e06e916 100644
--- a/lib/login_tty.c
+++ b/lib/login_tty.c
@@ -22,6 +22,10 @@
#include fcntl.h
#include unistd.h
+#if __OpenBSD__
+# include sys/ioctl.h
+#endif
+
int
login_tty (int slave_fd)
{
@@ -53,6 +57,11 @@ login_tty (int slave_fd)
close (dummy_fd);
}
+#if __OpenBSD__
+ /* Needed to activate the controlling terminal, see tty(4). */
+ ioctl (slave_fd, TIOCSCTTY, NULL);
+#endif
+
/* Assign fd to the standard input, standard output, and standardd error of
the current process. */
for (i = 0; i 3; i++)
signature.asc
Description: Digital signature
Detection of utmp/pty for *BSD.
Hello, in working on GNU Inetutils I have been forced to observe that the autoconfiguration fails for OpenBSD or FreeBSD in two instances (for which I see a solution), and that these ought to be mended by Gnulib. Tests related to utmp and openpty/forkpty, which are activated by the configure script, fail primarily due to the missing inclusion of sys/types.h in the generated test sources conftest.c. This header file is not automatically included in BSD, like it would be in GNU/Linux, thus the failure. 1. m4/readutmp.m4 This concerns OpenBSD and FreeBSD. The test must be reformulated using #ifdef HAVE_UTMP_H # if [...] # endif # include sys/types.h # include utmp.h #endif 2. m4/pty.m4 Here only FreeBSD is relevant. Four times the proper header file inclusion must read #ifdef HAVE_LIBUTIL_H # include sys/types.h # include libutil.h #endif Best regards, Mats Erik Andersson, fil. dr
Re: Detection of utmp/pty for *BSD.
torsdag den 9 september 2010 klockan 21:39 skrev Bruno Haible detta:
Hello Mats,
Thank you for your reports. Can you please also say on which
versions of OpenBSD and FreeBSD you observed the problems?
I need this info for investigating and for documenting the issue.
Bruno
The quick punch lines first:
* utmp.h is __NOT__ self-contained, neither for OpenBSD, nor FreeBSD.
* libutil.h is __NOT__ self-contained for FreeBSD.
In contrast,
* util.h __is__ self-contained for OpenBSD.
The following code fails to compile for OpenBSD 4.4 and 4.6, as well
as for FreeBSD 6.4 and 8.0:
#include utmp.h
int main(void) {
return 0;
}
The next code fails for FreeBSD 6.4 and 8.0:
#include libutil.h
int main(void) {
return 0;
}
All these failures are rescued by the simple insertion of a single
#include sys/types.h
before either of the original header files, but not after!
I have verified the above failures with the given snippets,
but they were originally discovered after bootstrapping the
code for GNU Inetutils from the git-HEAD stage.
Like there is a test whether sys/socket.h is self-contained
in any given OS, my observations suggest that similar tests
for self-containedness of utmp.h and libutil.h would
indeed improve the relevance of the autoconfiguration.
As the typical examples of this necessity let me mention that
some tests performed for openpty() on FreeBSD, and for getutent()
on OpenBSD and FreeBSD, fail a priory because the corresponding
header file are non-self-contained. That getutent() in reallity
is non-existent in OpenBSD and FreeBSD is in fact a conclusion
that can not be drawn from the tests, as they are recorded by
the logging into config.log.
Regards,
Mats Erik Andersson, fil. dr
