Re: Instructions on new bootstrap?
You've only just changed these. I'm not going to go to the wall over it tho. I just don't like the fact Miguel took the name, even if he managed to popularize it. I was never a contributor to emacs or much of one for the Linux kernel, so I never registered a complaint. Anyway, I've finished my objection at this point. :( On 7/30/22 22:36, Bruno Haible wrote: I have also updated the public documentation on www.gnu.org. The sections that changed regarding 'bootstrap' are: https://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html https://www.gnu.org/software/gnulib/manual/html_node/Developer-tools.html
Re: split bootstrap in two phases
On 7/30/22 16:43, Bruno Haible wrote: I offered to help Miguel de Icaza with his Gnome project, he didn't want the help, but did adopt my project's name. Oh, so the similarity between the names is not completely fortuitous. But meanwhile the name has spread; it is now even used in the Linux kernel [2]. I guess it's too late to turn back the clock. "This train has departed", we say in German. It's left the station in English, too. I'm just thinking we don't need an extra rail car running around the tracks. :)
Re: split bootstrap in two phases
On 7/30/22 13:45, Simon Josefsson via Gnulib discussion list wrote: Wonderful, thank you! I have yet to digest everything, so I'll fall back on stylistic comments: The first phase is a script 'autopull.sh'. The second phase is a script 'autogen.sh'. I'd like to object to that name. :) I offered to help Miguel de Icaza with his Gnome project, he didn't want the help, but did adopt my project's name. I've even gotten some folks to ask me for help with their bootstrapping scripts because they were named, "autogen.sh". So, please, not that. :)
Re: gl_CONDITIONAL & AM_CONDITIONAL
Hi Bruno, On 4/11/22 17:24, Bruno Haible wrote: > All these macros GL_GENERATE_*, GL_COND_*, gl_CONDITIONAL are > undocumented. Therefore you don't need to learn about them; > all you need is to give a "How to reproduce" to allow us > debugging the problem. > > So: >- What git repository / branch / tarball did you start with? autogen's current GIT on gnu.org [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = bk...@git.savannah.gnu.org:/srv/git/autogen.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master - What commands did you use? Once you've got autogen installed and GNULIBDIR env variable set and specify a temporary directory via "TMPDIR=whatever": bash -x config/bootstrap Attached are some files with my logs. Yours will look a little different. Anyway, all the tracing output will be dumped into: $TMPDIR/ag-bs-*.tdir - Which are your automake, autoconf versions? $ for f in automake autoconf libtool ; do $f --version | head -n 1 ; done automake (GNU automake) 1.15.1 autoconf (GNU Autoconf) 2.69 libtool (GNU libtool) 2.4.6 - What's the complete output? attached. Thank you! Regards, Bruce build-logs.tJz Description: Binary data
gl_CONDITIONAL & AM_CONDITIONAL
autoopts/Makefile.am:383: error: GL_GENERATE_STDNORETURN_H does not appear in AM_CONDITIONAL Once upon a time, I was readily able to use gnulib. However, I retired and didn't have much compelling need to keep up with usage changes. However, there are a couple of tweaks and the current autogen release is a bit long in the tooth. But I cannot build it. I have a bunch of similar messages for quite a few GL_* conditionals: GL_COND_OBJ_DUP2 GL_COND_OBJ_MSVC_INVAL GL_COND_OBJ_MSVC_NOTHROW GL_COND_OBJ_NANOSLEEP GL_COND_OBJ_PSELECT GL_COND_OBJ_PTHREAD_SIGMASK GL_COND_OBJ_RAISE GL_COND_OBJ_SELECT GL_COND_OBJ_SIGPROCMASK GL_GENERATE_ALLOCA_H GL_GENERATE_ERRNO_H GL_GENERATE_LIMITS_H GL_GENERATE_STDALIGN_H GL_GENERATE_STDBOOL_H GL_GENERATE_STDDEF_H GL_GENERATE_STDINT_H GL_GENERATE_STDNORETURN_H GL_GENERATE_SYS_SOCKET_H and I don't know how they are supposed to wind up getting wrapped in ??_CONDITIONAL() m4 macros. Well, some seem to be: $ grep -E '\'*.m4') config/gnulib-comp.m4: gl_CONDITIONAL([GL_COND_OBJ_DUP2], [test $REPLACE_DUP2 = 1]) config/gnulib-comp.m4: AM_COND_IF([GL_COND_OBJ_DUP2], [ config/gnulib-comp.m4: gl_CONDITIONAL([GL_COND_OBJ_MSVC_INVAL], config/gnulib-comp.m4: gl_CONDITIONAL([GL_COND_OBJ_MSVC_NOTHROW], config/gnulib-comp.m4: gl_CONDITIONAL([GL_COND_OBJ_NANOSLEEP], config/gnulib-comp.m4: gl_CONDITIONAL([GL_COND_OBJ_PSELECT], config/gnulib-comp.m4: gl_CONDITIONAL([GL_COND_OBJ_PTHREAD_SIGMASK], config/gnulib-comp.m4: AM_COND_IF([GL_COND_OBJ_PTHREAD_SIGMASK], [ config/gnulib-comp.m4: gl_CONDITIONAL([GL_COND_OBJ_RAISE], config/gnulib-comp.m4: AM_COND_IF([GL_COND_OBJ_RAISE], [ config/gnulib-comp.m4: gl_CONDITIONAL([GL_COND_OBJ_SELECT], [test $REPLACE_SELECT = 1]) config/gnulib-comp.m4: gl_CONDITIONAL([GL_COND_OBJ_SIGPROCMASK], [test $HAVE_POSIX_SIGNALBLOCKING = 0]) config/gnulib-comp.m4: AM_COND_IF([GL_COND_OBJ_SIGPROCMASK], [ and it doesn't necessarily suppress the error message: autoopts/Makefile.am:140: error: GL_COND_OBJ_DUP2 does not appear in AM_CONDITIONAL even though it is in an AM_COND_IF() macro. So, do I need to completely re-learn gnulib, or is there something simple?
Re: New way to integrate gnulib into projects?
On 5/17/21 1:17 AM, Simon Josefsson wrote: I still think the best solution is to put much of the gnulib stuff into an installable gnulib-dev package that would be required by the bootstrap script. I proposed that about 2 decades ago, but we're still spending gobs of compute and wall clock resources recomputing the same stuff. :( The problem is what to do if your project requires a newer version of some gnulib file. We already have that problem. Every now and then I try to build some project for some reason or another, but it turns out it needs a more recent libwhatever-dev installed. I install that, but _it_ needs libsomethingelse-dev, but my version isn't up-to-date enough. Or I can't find it at all. An out-of-date gnulib-dev wouldn't be anything new. OTOH, I'm retired, less quixotic and mostly use computers for email, Zoom and PhotoShop, which won't even run on Linux. (I've tried emulation, no go. :) Cheers - Bruce
Re: New way to integrate gnulib into projects?
On 5/15/21 1:01 AM, Simon Josefsson via Gnulib discussion list wrote: However, running ./bootstrap remains painfully slow. Amen!!! Then a second run of ./bootstrap in the directory would avoid the gnulib-tool step, and only run autoreconf and friends. A new cfg.mk variable to tell ./bootstrap to avoid checking out the gnulib repository and run gnulib-tool by default would be needed. Thoughts? I think most of the functionality I want could be achieved today by clever use of 'AUTORECONF=true AUTOPOINT=true LIBTOOLIZE=true ./bootstrap' and clever cfg.mk instrumenting with some hook together with './bootstrap --no-git'. So I could probably test my approach with only minimal changes to ./bootstrap now. I'd add it as "./bootstrap --brief" and no-op the commands internally. I still think the best solution is to put much of the gnulib stuff into an installable gnulib-dev package that would be required by the bootstrap script. I proposed that about 2 decades ago, but we're still spending gobs of compute and wall clock resources recomputing the same stuff. :(
Re: implementing fmemopen, open_memstream
Hi, On 2/21/21 3:07 PM, Bruno Haible wrote: What do you do on AIX, HP-UX, Solaris, OpenServer, UnixWare, native Windows ? Their stdio implementation does not contain function pointers in structs. One option is to wrap all of the file pointer functions in stdio and have the wrapper look for when it needs to call the wrapped function vs. calling registered functions. That's a bit of work, but it could be gotten to work. Otherwise, it means you can't do a drop-in fopen replacement that works on strings. Having a consistent implementation that works on the first two sets of platforms is about as good as one can do in that case. Also, I worked for SCO and when it committed seppuku with bad lawyering it pretty much put OpenServer and UnixWare on life support, if that. Who would still be writing stuff for those platforms? :) Cheers - Bruce
Re: new module 'string-buffer'
Hi,
On 2/21/21 12:55 PM, Bruno Haible wrote:
What alternative does gnulib offer to people who use open_memstream()?
open_memstream is not portable:
https://www.gnu.org/software/gnulib/manual/html_node/open_005fmemstream.html
I mentioned this a couple of decades ago. There was no solution, so I
rolled my own.
But gnulib cannot provide a drop-in replacement since it would require
unportable stream hackery (worse that stdio-impl.h).
The alternative is a string buffer module. Gnulib has some modules that
sound good at first sight but don't fulfil the need:
I wanted something that could act like a dropin replacement for
fopen-ing a regular file. There are some quirks (if memory serves), but
it is based on either fopencookie or funopen:
#ifdef HAVE_FOPENCOOKIE
cookie_io_functions_t iof;
iof.read = pRd;
iof.write = pWr;
iof.seek = fmem_seek;
iof.close = fmem_close;
res = fopencookie(pFMC, mode, iof);
#else
res = funopen(pFMC, pRd, pWr, fmem_seek, fmem_close);
#endif
I would prefer to pull a new module and dump mine, but it needs seek and
close functionality.
/**
* @file fmemopen.c
*
* Copyright (C) 2004-2020 by Bruce Korb. All rights reserved.
*
* This code was inspired from software written by
* Hanno Mueller, kont...@hanno.de
* and completely rewritten by Bruce Korb, bk...@gnu.org
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
#if defined(ENABLE_FMEMOPEN)
#include
typedef enum {
FMEMC_INVALID = 0,
FMEMC_GET_BUF_ADDR
} fmemctl_t;
typedef struct {
enum { FMEMC_GBUF_LEAVE_OWNERSHIP,
FMEMC_GBUF_TAKE_OWNERSHIP
} own;
char * buffer;
size_t buf_size;
size_t eof;
} fmemc_get_buf_addr_t;
#ifdef __gnu_hurd__
#define _IOT__IOTBASE_fmemc_get_buf_addr_t sizeof(fmemc_get_buf_addr_t)
#endif
#define IOCTL_FMEMC_GET_BUF_ADDR \
_IOWR('m', FMEMC_GET_BUF_ADDR, fmemc_get_buf_addr_t)
#if defined(HAVE_FOPENCOOKIE)
typedef off64_t * seek_off_t;
typedef int seek_ret_t;
#elif defined(HAVE_FUNOPEN)
typedef fpos_t seek_off_t;
typedef fpos_t seek_ret_t;
# ifdef NEED_COOKIE_FUNCTION_TYPEDEFS
typedef int (cookie_read_function_t )(void *, char *, int);
typedef int (cookie_write_function_t)(void *, char const *, int);
typedef fpos_t (cookie_seek_function_t )(void *, fpos_t, int);
typedef int (cookie_close_function_t)(void *);
# endif /* NEED_COOKIE_FUNCTION_TYPEDEFS */
#endif
#define PROP_TABLE \
_Prop_( read, "Read from buffer") \
_Prop_( write, "Write to buffer" ) \
_Prop_( append, "Append to buffer okay" ) \
_Prop_( binary, "byte data - not string" ) \
_Prop_( create, "allocate the string" ) \
_Prop_( truncate, "start writing at start" ) \
_Prop_( allocated, "we allocated the buffer" ) \
_Prop_( fixed_size, "writes do not append")
#define _Prop_(n,s) BIT_ID_ ## n,
typedef enum { PROP_TABLE BIT_CT } fmem_flags_e;
#undef _Prop_
#define FLAG_BIT(n) (1 << BIT_ID_ ## n)
typedef unsigned long mode_bits_t;
typedef unsigned char buf_bytes_t;
typedef struct fmem_cookie_s fmem_cookie_t;
struct fmem_cookie_s {
mode_bits_tmode;
buf_bytes_t * buffer;
size_t buf_size;/* Full size of buffer */
size_t next_ix; /* Current position */
size_t eof; /* End Of File */
size_t pg_size; /* size of a memory page.
Future architectures allow it to vary
by memory region. */
};
typedef struct {
FILE * fp;
fmem_
Re: Hidden files in autoconf 2.70 distribution?
Tho the instance is particular to gnulib, it is of a more general interest, too. On 12/9/20 6:21 AM, Zack Weinberg wrote: This conversation should happen on the Gnulib mailing list; both git-version-gen and maint.mk are maintained there. I have no particular opinion about whether it is appropriate to use dot-files for this purpose. (Context that got trimmed off the top: Bob is concerned about the files named ".prev-version", ".version", and ".tarball-version" in the autoconf 2.70 release tarball.)
Innocuous warnings
I'm prepping gnu-pw-mgr for a release and decided to scrutinize the
build log.
1. timespec.c and timespec.h define _GL_TIMESPEC_INLINE
2. unistd.[ch] do the same thing for _GL_UNISTD_INLINE
3. unlocked-io.h define both {fread,fwrite}_unlocked, but so does
/usr/include/bits/stdio.h
timespec.c:2:0: warning: "_GL_TIMESPEC_INLINE" redefined
#define _GL_TIMESPEC_INLINE _GL_EXTERN_INLINE
In file included from ../config.h:1478:0,
from timespec.c:1:
./timespec.h:29:0: note: this is the location of the previous definition
# define _GL_TIMESPEC_INLINE _GL_INLINE
...
unistd.c:2:0: warning: "_GL_UNISTD_INLINE" redefined
#define _GL_UNISTD_INLINE _GL_EXTERN_INLINE
In file included from ../config.h:1473:0,
from unistd.c:1:
./unistd.h:664:0: note: this is the location of the previous definition
# define _GL_UNISTD_INLINE _GL_INLINE
..
In file included from libopts.c:21:0:
unlocked-io.h:110:0: warning: "fread_unlocked" redefined
# define fread_unlocked(_w,_x,_y,_z) fread (_w,_x,_y,_z)
In file included from /usr/include/stdio.h:859:0,
from ../lib/stdio.h:43,
from ../config.h:1467,
from libopts.c:2:
/usr/include/bits/stdio.h:144:0: note: this is the location of the
previous definition
# define fread_unlocked(ptr, size, n, stream) \
In file included from libopts.c:21:0:
unlocked-io.h:117:0: warning: "fwrite_unlocked" redefined
# define fwrite_unlocked(_w,_x,_y,_z) fwrite (_w,_x,_y,_z)
In file included from /usr/include/stdio.h:859:0,
from ../lib/stdio.h:43,
from ../config.h:1467,
from libopts.c:2:
/usr/include/bits/stdio.h:168:0: note: this is the location of the
previous definition
# define fwrite_unlocked(ptr, size, n, stream) \
Re: gc-pbkdf2-sha1 must not be deprecated
On 9/22/20 10:03 AM, Bruno Haible wrote:
I'm not really familiar with these. Does the libgcrypt documentation help,
maybe?
Bruno
I have become much more familiar that I'd really like to be. It seems
that without the crypto/gc-pbkdf2-sha1 module defined, then
GNULIB_GC_HMAC_SHA1 is not defined so the switch statement falls through
to the error return. If crypto/gc-pbkdf2 provides a definition for
GC_SHA1, then the code needs to handle it. There are legitimate uses for
SHA1, even if it should not be used for signing files. It cannot be
obsoleted. Ever.
101 Gc_rc
102 gc_pbkdf2_hmac (Gc_hash hash,
103 const char *P, size_t Plen,
104 const char *S, size_t Slen,
(gdb)
105 unsigned int c, char *DK, size_t dkLen)
106 {
107 gc_prf_func prf;
108 size_t hLen;
109
110 switch (hash)
111 {
112 #if GNULIB_GC_HMAC_SHA1
113 case GC_SHA1:
114 prf = gc_hmac_sha1;
(gdb)
115 hLen = GC_SHA1_DIGEST_SIZE;
116 break;
117 #endif
118
119 #if GNULIB_GC_HMAC_SHA256
120 case GC_SHA256:
121 prf = gc_hmac_sha256;
122 hLen = GC_SHA256_DIGEST_SIZE;
123 break;
124 #endif
(gdb)
125
126 #if GNULIB_GC_HMAC_SHA512
127 case GC_SHA512:
128 prf = gc_hmac_sha512;
129 hLen = GC_SHA512_DIGEST_SIZE;
130 break;
131 #endif
132
133 default:
134 return GC_INVALID_HASH;
(gdb)
135 }
136
137 return gc_pbkdf2_prf (prf, hLen, P, Plen, S, Slen, c, DK,
dkLen);
138 }
Re: gc-pbkdf2-sha1 is deprecated
Hi Bruno, et al.,
The failing difference isn't whether or not I use gc_pbkdf2_hmac vs.
gc_pbkdf2_sha1, the failing difference is whether or not I specify the
crypto/gc-pbkdf2-sha1 module vs. the crypto/gc-pbkdf2 module. The former
works, the latter does not, with the rest of my project entirely
unchanged. Feel free to test it, assuming you have the autogen suite for
bootstrapping:
[remote "origin"]
url = bk...@git.savannah.gnu.org:/srv/git/gnu-pw-mgr.git
Without specifying the "-sha1" module, the make check fails with the
pbkdf2 function returning 5. Here's the patch that causes the project to
fail:
diff --git a/bootstrap.conf b/bootstrap.conf
index b0e397a..7703c6f 100755
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -90,7 +90,7 @@ initialize() {
gnulib_modules='
base64 \
close \
- crypto/gc-pbkdf2-sha1 \
+ crypto/gc-pbkdf2 \
crypto/gc-random \
crypto/sha256 \
ctype \
and it yields this error message:
+++T=gpw-53> /u/bkorb/tools/gnu-pw-mgr-bld/src/gnu-pw-mgr
--config-file=/tmp/gpw-3tsXGB/.local/gnupwmgr.cfg --rehash=1 -i test-tag who
gnu-pw-mgr fatal error:
gc_pbkdf2_sha1 returned error code 5
On 9/21/20 3:49 PM, Bruce Korb wrote:
It may go away, because the module crypto/gc-pbkdf2 contains more
generic API to do the same thing: gc_pbkdf2_hmac with first argument
GC_SHA1.
Bruno
Re: gc-pbkdf2-sha1 is deprecated
gnu-pw-mgr fatal error: gc_pbkdf2_hmac returned error code 5 (5 --> GC_INVALID_HASH) I think they work differently. rc = gc_pbkdf2_hmac(GC_SHA1, hash_source, hash_src_len, salt, salt_len, OPT_VALUE_PBKDF2,// <-- pbkdf2 reprocessing count hash_output, hash_out_len); if (rc != GC_OK) die(GNU_PW_MGR_EXIT_INVALID, pbkdf2_err_fmt, rc); On 9/18/20 9:32 AM, Bruno Haible wrote: Hi Bruce, Next question: what do I do about crypto/gc-pbkdf2-sha1? It is labeled as "deprecated", but I need a function that produces precisely the same result. It really doesn't matter to me that folks have figured out how to jigger a file to produce an arbitrary sha1 sum. I only need a fairly random result from summing a few tens of bytes of text. So as long as "deprecate" doesn't mean it's going away, I'm fine. It may go away, because the module crypto/gc-pbkdf2 contains more generic API to do the same thing: gc_pbkdf2_hmac with first argument GC_SHA1. Bruno
gc-pbkdf2-sha1 is deprecated
Hi Bruno, et al., Next question: what do I do about crypto/gc-pbkdf2-sha1? It is labeled as "deprecated", but I need a function that produces precisely the same result. It really doesn't matter to me that folks have figured out how to jigger a file to produce an arbitrary sha1 sum. I only need a fairly random result from summing a few tens of bytes of text. So as long as "deprecate" doesn't mean it's going away, I'm fine. I use the code to create an unguessable password. Just because it's possible to use different source text to produce the same password doesn't matter at all. :) Cheers - Bruce
Re: Trying to bootstrap my project, distcheck doesn't configure
Hi Bruno,
On 9/14/20 3:53 PM, Bruno Haible wrote:
Hi Bruce,
It would help if you would give a pointer to the source code you are
trying to bootstrap. Because a single line in Makefile.am or configure.ac
can have a big effect.
It lives on my home machine while I try to get it ready for prime time.
As you may recollect, autogen is a monster. You can pull a copy from
GNU's git repo, if you're interested:
https://savannah.gnu.org/git/?group=autogen
It is documented here:
https://www.gnu.org/software/gnulib/manual/html_node/Modified-build-rules.html
Apparently, somewhere along the line I added "--lib=do_not_make_me".
That had to have been years ago and I have no recollection of adding
that. Anyway, that triggered some do_not_make_me_la_SOURCE += whatever
stuff, which was not added previously. I have no idea how those names
get selected, but after a grep, sed and unique sort, I came up with this
list:
EXTRA_do_not_make_me_la_SOURCES =
do_not_make_me_la_DEPENDENCIES =
do_not_make_me_la_LIBADD =
do_not_make_me_la_SOURCES =
These aren't documented on that page. I googled for "do_not_make_me" and
got no results, tho were I to do it today, I'd likely get this email
thread. :) Anyway, I am gathering from reading what you've pointed to
that the grep/sed/sort accommodation is the right solution. Thank you.
Regards, Bruce
For your possible (unlikely?) entertainment:
fix_do_not_make_me() {
local fix_list=$(
grep -l FIX-DO-NOT-MAKE-ME \
$(find * -type f -name 'Makefile.am'))
local sedcmd= vlist= f= v=
for f in $fix_list
do
sedcmd=$'/^##* *FIX-DO-NOT-MAKE-ME/ {\ns/.*//\n'
vlist=$(sed -n '/do_not_make_me/s/ *[+=].*//p' $f | \
sort -u)
if test ${#vlist} -gt 1
then
sedcmd+=$'i\\\n'
for v in $vlist
do
sedcmd+="$(printf '%-32s=' $v)"$'\\\n'
done
sedcmd+=$'\n'
fi
sedcmd+='}'
sed "$sedcmd" $f > $f.make-me-fixed
mv -f $f.make-me-fixed $f
done
}
Re: Trying to bootstrap my project, distcheck doesn't configure
Sorry, Mathieu, I can now see I sent it to the wrong list. On 9/14/20 11:33 AM, Mathieu Lirzin wrote: I'm hitting this that I've never seen before: $ grep do_not_make_me au*bld/autoopts/Makefile.am do_not_make_me_la_LIBADD += @LTALLOCA@ do_not_make_me_la_DEPENDENCIES += @LTALLOCA@ EXTRA_do_not_make_me_la_SOURCES += alloca.c EXTRA_do_not_make_me_la_SOURCES += dup2.c do_not_make_me_la_SOURCES += fd-hook.c do_not_make_me_la_SOURCES += gettext.h EXTRA_do_not_make_me_la_SOURCES += msvc-inval.c EXTRA_do_not_make_me_la_SOURCES += msvc-nothrow.c EXTRA_do_not_make_me_la_SOURCES += nanosleep.c do_not_make_me_la_SOURCES += parse-duration.c EXTRA_do_not_make_me_la_SOURCES += raise.c EXTRA_do_not_make_me_la_SOURCES += select.c do_not_make_me_la_SOURCES += sig-handler.c EXTRA_do_not_make_me_la_SOURCES += sigaction.c EXTRA_do_not_make_me_la_SOURCES += sigprocmask.c do_not_make_me_la_SOURCES += sockets.h sockets.c do_not_make_me_la_SOURCES += stat-time.c do_not_make_me_la_SOURCES += sys_socket.c do_not_make_me_la_SOURCES += timespec.c do_not_make_me_la_SOURCES += unistd.c which trigger error messages that I can get around by hacking in dummy initial assignments, but I'm guessing that's not the intended method. I need a clue, please? Thank you. It seems that gnulib-tool inserts these into my Makefile.am, but doesn't insert the initial plain assignment. I have no idea what new ones may crop up, so I've added a "##FIX-DO-NOT-MAKE-ME" line to my Makefile.am's. That gets fixed by figuring out which ones get automatically inserted. e.g.: BUILT_SOURCES = MOSTLYCLEANFILES = EXTRA_do_not_make_me_la_SOURCES = do_not_make_me_la_DEPENDENCIES = do_not_make_me_la_LIBADD = do_not_make_me_la_SOURCES = But I still have confusing problems: autoopts/Makefile.am:33: warning: variable 'EXTRA_do_not_make_me_la_SOURCES' is defined but no program or autoopts/Makefile.am:33: library has 'do_not_make_me_la' as canonical name (possible typo) autoopts/Makefile.am:36: warning: variable 'do_not_make_me_la_SOURCES' is defined but no program or autoopts/Makefile.am:36: library has 'do_not_make_me_la' as canonical name (possible typo) autoopts/Makefile.am:35: warning: variable 'do_not_make_me_la_LIBADD' is defined but no program or autoopts/Makefile.am:35: library has 'do_not_make_me_la' as canonical name (possible typo) autoopts/Makefile.am:34: warning: variable 'do_not_make_me_la_DEPENDENCIES' is defined but no program or autoopts/Makefile.am:34: library has 'do_not_make_me_la' as canonical name (possible typo) doc/Makefile.am:40: installing 'config/texinfo.tex' and I have no obvious workaround for it. And Googling 'gnulib do_not_make_me' yields nothing.
Re: error: GL_GENERATE_ERRNO_H does not appear in AM_CONDITIONAL
Hi Bruno,
On Fri, Sep 6, 2019 at 3:25 PM Bruno Haible wrote:
> Hi Bruce,
> > Bootstrap messages:
> >
> > autoopts/Makefile.am:97: error: GL_GENERATE_ERRNO_H does not appear in
> > AM_CONDITIONAL
> > autoopts/Makefile.am:152: error: GL_GENERATE_STDDEF_H does not appear
> > in AM_CONDITIONAL
>
> These two message indicate that the 'configure' script was not correctly
> generated.
>
I had guessed that.
There are many possible causes. Before you revisit your build system,
> I would
> - try the same thing from a pristine checkout (no leftover files from
> a couple of years ago),
>
Countless years ago, my build process became blowing away the build tree,
cloning the repo tree, populating it only with managed files, and *then*
go in and bootstrap/autoreconf/configure/make. The configure stuff
has bit-rotted.
> - verify that the -I options passed to aclocal contain the directory
> where errno_h.m4 and stddef_h.m4 have been copied to.
>
It looks right:
libtoolize: linking file 'config/lt~obsolete.m4'
+shlib=run_autotools-177> doit /usr/local/bin/aclocal -I config
((note: I'm using a fancy PS4 here.
viz. PS4="+${prog}=\${FUNCNAME:-=}-\$LINENO> "))
+shlib=doit-34> test x/usr/local/bin/aclocal '!=' x:
+shlib=doit-36> echo 'RUN: /usr/local/bin/aclocal -I config'
RUN: /usr/local/bin/aclocal -I config
+shlib=doit-37> eval /usr/local/bin/aclocal -I config
++shlib=doit-37> /usr/local/bin/aclocal -I config
configure.ac:121: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE 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...
config/ag_macros.m4:215: AG_LINK_SETJMP is expanded from...
config/ag_macros.m4:568: INVOKE_AG_MACROS is expanded from...
configure.ac:121: the top level
configure.ac:121: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
.
Makefile.am: installing './COPYING' using GNU General Public License v3 file
Makefile.am: Consider adding the COPYING file to the version control
system
Makefile.am: for your code, to avoid questions about which license your
project uses
agen5/Makefile.am: installing 'config/depcomp'
parallel-tests: installing 'config/test-driver'
autoopts/Makefile.am:97: error: GL_GENERATE_ERRNO_H does not appear in
AM_CONDITIONAL
autoopts/Makefile.am:152: error: GL_GENERATE_STDDEF_H does not appear in
AM_CONDITIONAL
doc/Makefile.am:38: installing 'config/texinfo.tex'
+shlib=doit-37> die 'FAILURE 1: /usr/local/bin/automake --gnu
--add-missing'
+shlib=die-27> echo 'bootstrap failure: FAILURE 1:
/usr/local/bin/automake --gnu --add-missing'
$ ls config
00gnulib.m4 extern-inline.m4 lib-ld.m4 pkg.m4
absolute-header.m4 gendocs.sh lib-link.m4 snippet
ag_macros.m4gen-files.tar.gz liboptschk.m4 snprintfv.m4
bootstrap gen-list.txt libopts.m4 stat-time.m4
bootstrap.local gnulib-cache.m4lib-prefix.m4 stddef_h.m4
bootstrap.shlib gnulib-common.m4 libtool.m4 stdnoreturn.m4
compile gnulib-comp.m4 ltmain.sh test-driver
config.guessgnulib-tool.m4 lt~obsolete.m4 texinfo.tex
config.rpathguile.m4 ltoptions.m4time_h.m4
config.sub host-cpu-c-abi.m4 ltsugar.m4 unlocked-io.m4
depcomp include_next.m4ltversion.m4warn-on-use.m4
errno_h.m4 install-defs.shmissing wchar_t.m4
extensions.m4 install-sh mk-shdefs.in
Re: Patch required to avoid breakage
On Wed, Aug 8, 2018 at 3:09 PM Bruno Haible wrote: > 1) The error occurs in directory libopts/, which contains a hand-made > use of gnulib modules - without use of gnulib-tool. This is not > supported, because internals of modules can change without notice. > Instead, please take a look at this documentation section: > https://www.gnu.org/software/gnulib/manual/html_node/Multiple-instances.html#Multiple-instances Thank you. Maybe. I use gnulib-tool to pull the sources into autogen and then spin off a libopts tarball. That tarball includes the gnulib stuff. My intention was to be able to unroll it, add in ACLOCAL_AMFLAGS and have it work. It needs work. > 2) You hand-imported module 'stdnoreturn'. But it depends on module > 'snippets/_Noreturn'. You didn't hand-import this module correctly. > Namely, the 'Files: lib/_Noreturn.h' should translate into an action > of yours that copies gnulib/lib/_Noreturn.h to libopts/_Noreturn.h. I guess this is where my confusion lives. I see that when I specify a mess of modules, those modules pull in their "Depends-on:" modules. Mostly. I'll add snippet/_Noreturn to the autogen stuff and see where that goes. Again, thank you so very much for your help. I had gotten to aimless wandering now knowing how far South I had gotten. > 3) The EXTRA_DIST addition in libopts/Makefile.am is correct. > gnulib-tool would do it for you, but you chose to do it by hand. It is actually a computed list, based on what gets pulled in via gnulib-tool. > 4) Later on, I need to distribute the man page, despite the fact it is rebuldable. You have been a great help. Thank you so much. Regards, Bruce
Re: Patch required to avoid breakage
https://drive.google.com/open?id=1LYwEFhDRF-dflvdQUmJyw0XYwv9Ebp8m
I don't know if "wget" works with that link, but you get an offer to
download it.
86 tar -xJf gnu-pw-mgr.tar.xz
87 cd gnu-pw-mgr-v2.4-dirty/
88 ./configure --prefix=${PWD%/*}/gnu-pw-mgr-install
89 make
90 make dist
On Wed, Aug 8, 2018 at 9:17 AM Bruno Haible wrote:
>
> Hi Bruce,
>
> > But I cannot determine what patch I need to fix it.
> > gnulib-tool installs a bunch of stuff in "lib/" that seems like
> > it ought to handle it, but I get this message anyway:
> >
> > > No rule to make target '_Noreturn.h', needed by 'distdir-am'
>
> There is absolutely no chance that we could help you, when you give
> out that little information. Already with normal bugs you need to
> provide either some context, or "How to reproduce" steps.
>
> With gnulib-tool and Automake, build issues are very sensitive
> to details. Therefore in this area a textual "How to reproduce"
> is often not enough.
>
> The best way to go forward is that you do a "make distclean",
> create a tarball of the project, upload it somewhere, and then
> show the sequence of commands - starting with a 'wget ...' -
> which gets you to this error message.
>
> Bruno
>
--
- Bruce
Re: Patch required to avoid breakage
Dear Paul Eggert, On Wed, Aug 8, 2018 at 8:41 AM Bruce Korb wrote: > > But I cannot determine what patch I need to fix it. > gnulib-tool installs a bunch of stuff in "lib/" that seems like > it ought to handle it, but I get this message anyway: > > > No rule to make target '_Noreturn.h', needed by 'distdir-am' > > I fixed it in one project by adding EXTRA_DIST += lib/_Noreturn.h > to the top level Makefile.am, but that seems like the wrong answer. > The "stdnoreturn" module should not be exposing its internal workings this > way. I misremembered. I'd applied the same hack to the failing project but still have the issue. Any suggestions, Paul?
Patch required to avoid breakage
But I cannot determine what patch I need to fix it. gnulib-tool installs a bunch of stuff in "lib/" that seems like it ought to handle it, but I get this message anyway: > No rule to make target '_Noreturn.h', needed by 'distdir-am' I fixed it in one project by adding EXTRA_DIST += lib/_Noreturn.h to the top level Makefile.am, but that seems like the wrong answer. The "stdnoreturn" module should not be exposing its internal workings this way.
Re: lib/stdio-read.c == gnulib/m4/stdio_h.m4
On Tue, Jul 31, 2018 at 11:06 AM Bruce Korb wrote: > > Solved. cd $GNULIB_SRCDIR m4file=$(grep -i 'def.*gl_MACRO_NOT_FOUND' $(git ls-files | grep m4/) | sed 's/:.*//') grep $m4file $(git ls-files|grep module)
Re: lib/stdio-read.c == gnulib/m4/stdio_h.m4
Solved.
On Tue, Jul 31, 2018 at 9:42 AM Bruce Korb wrote:
> OK, if I hand link the files gnulib/lib/stdio-{read,write}.c to lib/.
> I get further, but that raises the question of "Why is that not done
> by gnulib-tool?"
>
> Anyway, with that by-hand intervention, I get to this:
The messages that followed were a consequence of extra -I options that
were added to solve problems caused by the two stdio files not having
been installed in lib.
SUMMARY:
My best guess is that there were module dependency changes. Likely, I
directly depended on a module that was indirectly depended upon by
another. That other was listed, but when its dependencies changed, my
build got broken. I do not know how hard it would be to construct a
gnulib wrapper around autoreconf that could check for missing gnulib
stuff, but it'd have made my life easier. Basically, "tee(1)" the
output into a temp file and, on error. search through it for gl_[A-Z]*
macro failures and for missing files that live in gnulib/lib. I'd get
"a round tuit" late this fall, if it'd be received.
Re: lib/stdio-read.c == gnulib/m4/stdio_h.m4
On Tue, Jul 31, 2018 at 9:05 AM Bruce Korb wrote:
>
> Could this be involved in my errors?
> The messages from autoreconf:
>
>
> autoreconf: running: aclocal -I m4 -I libopts/m4 -I gnulib/m4
> missing file lib/stdio-read.c
> configure.ac:48: error: expected source file, required through
> AC_LIBSOURCES, not found
> m4/gnulib-comp.m4:138: gl_INIT is expanded from...
> configure.ac:48: the top level
> autom4te: /usr/bin/m4 failed with exit status: 1
> aclocal: error: echo failed with exit status: 1
> autoreconf: aclocal failed with exit status: 1
OK, if I hand link the files gnulib/lib/stdio-{read,write}.c to lib/.
I get further, but that raises the question of "Why is that not done
by gnulib-tool?"
Anyway, with that by-hand intervention, I get to this:
aclocal: ignoring macro gl_00GNULIB in gnulib/m4/00gnulib.m4: 46
aclocal: error: couldn't open directory 'm4 gnulib/m4 libopts/m4': No
such file or directory
autoreconf: aclocal failed with exit status: 1
The fact that I am writing means that those three directories actually exist:
$ ls -ld m4 gnulib/m4 libopts/m4
drwxr-xr-x 2 bkorb dev 24576 Jul 31 08:45 gnulib/m4
drwxr-xr-x 2 bkorb dev 4096 Jul 28 11:14 libopts/m4
drwxr-xr-x 2 bkorb dev 4096 Jul 31 08:45 m4
and those directories are looked for 'cuz I tools aclocal to do so:
$ grep 'ACLOCAL_AMFLAGS' Makefile.am
ACLOCAL_AMFLAGS = -I m4 -I libopts/m4 -I gnulib/m4
I was told before that "gnulib/m4" should not be needed, but without it,
certain gl_* macros cannot be found.
lib/stdio-read.c == gnulib/m4/stdio_h.m4
Could this be involved in my errors? The messages from autoreconf: autoreconf: running: aclocal -I m4 -I libopts/m4 -I gnulib/m4 missing file lib/stdio-read.c configure.ac:48: error: expected source file, required through AC_LIBSOURCES, not found m4/gnulib-comp.m4:138: gl_INIT is expanded from... configure.ac:48: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: error: echo failed with exit status: 1 autoreconf: aclocal failed with exit status: 1 == $ find gnu-pw-mgr-bld/* -type f|xargs fgrep lib/stdio-read.c gnu-pw-mgr-bld/autom4te.cache/traces.0t: dnl This ifdef is necessary to avoid an error "missing file lib/stdio-read.c" Binary file gnu-pw-mgr-bld/gnulib/.git/index matches gnu-pw-mgr-bld/gnulib/m4/stdio_h.m4: dnl This ifdef is necessary to avoid an error "missing file lib/stdio-read.c" gnu-pw-mgr-bld/gnulib/modules/nonblocking:lib/stdio-read.c >From stdio_h.m4: dnl This ifdef is necessary to avoid an error "missing file lib/stdio-read.c" dnl "expected source file, required through AC_LIBSOURCES, not found". It is dnl also an optimization, to avoid performing a configure check whose result dnl is not used. But it does not make the test of GNULIB_STDIO_H_NONBLOCKING dnl or GNULIB_NONBLOCKING redundant. m4_ifdef([gl_NONBLOCKING_IO], [ gl_NONBLOCKING_IO if test $gl_cv_have_nonblocking != yes; then REPLACE_STDIO_READ_FUNCS=1 AC_LIBOBJ([stdio-read]) fi ])
Since I am desperate, ...
I've been trying a lot of things to get autoreconf to work. I'm running it with --verbose, but not getting any useful hints out of it. autoreconf: running: aclocal -I m4 -I libopts/m4 -I gnulib/m4 missing file lib/stdio-read.c configure.ac:48: error: expected source file, required through AC_LIBSOURCES, not found m4/gnulib-comp.m4:138: gl_INIT is expanded from... configure.ac:48: the top level with that error, I added the "stdio" module and still got the error: bootstrap: running: gnulib/gnulib-tool --no-changelog --aux-dir=build-aux --m4-base=m4 --libtool --symlink --import base64 close crypto/gc-pbkdf2-sha1 crypto/sha256 ctype fdl gendocs... Module list with included dependencies (indented): absolute-header [] stdbool stddef stdint stdio <<= stdlib stdnoreturn [...] File list: . So now I am either failing earlier or later and there are no hints about which it might be. (Previously, it was failing on gl_SC_RANDOM not being defined in some ill-defined place. I think forcing "-I gnulib/m4" into the aclocal command line fixed that.) $ for f in autoconf automake libtool ; do $f --version |head -n 1; done autoconf (GNU Autoconf) 2.69 automake (GNU automake) 1.16.1 libtool (GNU libtool) 2.4.6
Re: Why is gl_GC_RANDOM not found?
Another downside to using config files from a previously built distribution is that I cannot roll a new tarball. Maybe I could by using "tar cJf", but "make dist" fails. Does anyone have any suggestions for debugging? On Mon, Jul 30, 2018 at 10:53 AM Bruce Korb wrote: > > On Sun, Jul 29, 2018 at 5:55 PM Bruce Korb wrote: > > My solution is to unroll a distribution tarball and copy over any > files not in the source tree. > I don't think that's an ideal solution tho. I added $(LIB_CRYPTO) but > the autoreconf > still chokes on gl_GC_RANDOM. Sorry to be so dense, but the error message > leaves no clues for me. -- - Bruce
Re: Why is gl_GC_RANDOM not found?
On Sun, Jul 29, 2018 at 5:55 PM Bruce Korb wrote: My solution is to unroll a distribution tarball and copy over any files not in the source tree. I don't think that's an ideal solution tho. I added $(LIB_CRYPTO) but the autoreconf still chokes on gl_GC_RANDOM. Sorry to be so dense, but the error message leaves no clues for me.
Re: Why is gl_GC_RANDOM not found?
gnulib/gnulib-tool --no-changelog --aux-dir=build-aux --m4-base=m4 --libtool --symlink --import base64 close crypto/gc-pbkdf2-sha1 crypto/sha256 ctype fdl gendocs inttypes lgpl-2.1 malloc-posix snprintf stdbool stdnoreturn strdup-posix strstr random time termios So you are referring to this? You may need to add #include directives for the following .h files. #include ... You may need to use the following Makefile variables when linking. Use them in _LDADD when linking a program, or in _a_LDFLAGS or _la_LDFLAGS when linking a library. $(LIB_CRYPTO) Don't forget to - add "lib/Makefile" to AC_CONFIG_FILES in ./configure.ac, - mention "lib" in SUBDIRS in Makefile.am, - mention "-I m4" in ACLOCAL_AMFLAGS in Makefile.am, - mention "m4/gnulib-cache.m4" in EXTRA_DIST in Makefile.am, - invoke gl_EARLY in ./configure.ac, right after AC_PROG_CC_C99, - invoke gl_INIT in ./configure.ac. bootstrap: running: autoreconf --symlink --install
Re: Why is gl_GC_RANDOM not found?
I am using Gary Vaughan's bootstrap script from years ago. It's worked fine all this time, but I'll instrument it to see what gives. On Sat, Jul 28, 2018 at 7:09 PM Bruno Haible wrote: > > Bruce Korb wrote: > > $ autoreconf --symlink --install > > configure.ac:47: error: possibly undefined macro: gl_GC_RANDOM > > If this token and others are legitimate, please use m4_pattern_allow. > > See the Autoconf documentation. > > autoreconf: /usr/bin/autoconf failed with exit status: 1 > > $ fgrep gl_GC_RANDOM $(find gnulib/m4 libopts/m4 m4 -name '*.m4') > > gnulib/m4/gc-random.m4:AC_DEFUN([gl_GC_RANDOM], > > Some guesses: > - It looks like the maintainer of your package has invoked gnulib-tool > and not followed all the maintainer advice that gnulib-tool prints at > the end. > Try re-running gnulib-tool with the same arguments (usually done > via some autogen.sh, bootstrap, Makefile.devel, or through the invocation > cached in gnulib-cache.m4), and verify that all the maintainer advice > has been followed. > - Or maybe some -I options have been removed from ACLOCAL_AMFLAGS, to > avoid a warning from not-yet-released versions of Automake? > > Bruno > -- - Bruce
Re: Why is gl_GC_RANDOM not found?
Even with: export AUTOCONF=$(command -v autocnof)\ -Ignulib/m4 ?? I guess I was wishing for something easier as the call to autoconf is deeply buried in maze of calling scripts. I'll try another day. Thank you!! On Sat, Jul 28, 2018 at 3:47 PM Paul Eggert wrote: > > Bruce Korb wrote: > > $ autoreconf --symlink --install > > configure.ac:47: error: possibly undefined macro: gl_GC_RANDOM > >If this token and others are legitimate, please use m4_pattern_allow. > >See the Autoconf documentation. > > autoreconf: /usr/bin/autoconf failed with exit status: 1 > > $ fgrep gl_GC_RANDOM $(find gnulib/m4 libopts/m4 m4 -name '*.m4') > > gnulib/m4/gc-random.m4:AC_DEFUN([gl_GC_RANDOM], > > autoreconf doesn't normally look in gnulib/m4. You can use 'strace -f' to see > where it's actually looking. -- - Bruce
Why is gl_GC_RANDOM not found?
$ autoreconf --symlink --install configure.ac:47: error: possibly undefined macro: gl_GC_RANDOM If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 $ fgrep gl_GC_RANDOM $(find gnulib/m4 libopts/m4 m4 -name '*.m4') gnulib/m4/gc-random.m4:AC_DEFUN([gl_GC_RANDOM],
Re: Another patch (warning)
Hi Eric, On Thu, Jun 21, 2018 at 5:43 AM Eric Blake wrote: > > On 06/20/2018 02:34 PM, Bruce Korb wrote: > > diff --git a/lib/random_r.c b/lib/random_r.c > > index 697ca5f..cd2537a 100644 > > --- a/lib/random_r.c > > +++ b/lib/random_r.c > > @@ -286,7 +286,7 @@ __initstate_r (unsigned int seed, char *arg_state, > > size_t n, > >buf->rand_type = type; > >buf->rand_sep = separation; > >buf->rand_deg = degree; > > - state = &((int32_t *) arg_state)[1]; /* First location. */ > > + state = &((int32_t *) (unsigned long) arg_state)[1]; /* First location. > > Shouldn't that be (uintptr_t) rather than (unsigned long), to be safe on > machines where long is 32 bits but pointers are 64 (hello Windows)? I supposed. I hacked it this way because it worked on Linux and OS/X. I don't do windows. :) Anyway, I think your more careful analysis is correct. You (gnulib folks) need to use memcpy. Sorry. (Or wrap it with a macro to accommodate forgiving architectures.) Cheers - Bruce
Another patch (warning)
diff --git a/lib/random_r.c b/lib/random_r.c
index 697ca5f..cd2537a 100644
--- a/lib/random_r.c
+++ b/lib/random_r.c
@@ -286,7 +286,7 @@ __initstate_r (unsigned int seed, char *arg_state,
size_t n,
buf->rand_type = type;
buf->rand_sep = separation;
buf->rand_deg = degree;
- state = &((int32_t *) arg_state)[1]; /* First location. */
+ state = &((int32_t *) (unsigned long) arg_state)[1]; /* First location.
*/
/* Must set END_PTR before srandom. */
buf->end_ptr = [degree];
@@ -318,7 +318,7 @@ weak_alias (__initstate_r, initstate_r)
int
__setstate_r (char *arg_state, struct random_data *buf)
{
- int32_t *new_state = 1 + (int32_t *) arg_state;
+ int32_t *new_state = 1 + (int32_t *) (unsigned long) arg_state;
int type;
int old_type;
int32_t *old_state;
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -Wcast-align
-Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes
-Wwrite-strings -Wno-format -fno-strict-aliasing -Wstrict-aliasing=2 -MT
random_r.lo -MD -MP -MF .deps/random_r.Tpo -c random_r.c -fno-common -DPIC
-o .libs/random_r.o
random_r.c:289:13: warning: cast from 'char *' to 'int32_t *' (aka 'int *')
increases required alignment from 1 to 4
[-Wcast-align]
state = &((int32_t *) arg_state)[1]; /* First location. */
^
random_r.c:321:28: warning: cast from 'char *' to 'int32_t *' (aka 'int *')
increases required alignment from 1 to 4
[-Wcast-align]
int32_t *new_state = 1 + (int32_t *) arg_state;
^
2 warnings generated.
Re: gendocs broken?
Thanks, Padraig. I'll pull the new version. I'm still conflicted tho: I like having the manuals broken by section and the "makeinfo" version seems to only do it by node. Oh, well. Anyway, thank you for pointing me in the right direction! Cheers - Bruce On Sun, Jun 17, 2018 at 2:31 PM Pádraig Brady wrote: > > On 17/06/18 12:11, Bruce Korb wrote: > > Hi Pádraig, > > > > If "texi2html" is out of date, then how do I get HTML? > > I want to keep my online docs up to date. If there's a better > > way, I'm for that. I confess I don't closely track stuff so > > when better ways come around, I need to find out by bumping > > into something. This is such a bump. It would be convenient > > if I could just tell the script to "make html" and it figured > > out how to do that. :) Also, if it cannot (like I didn't have > > texi2html installed), it should *FAIL* rather than silently > > creating an empty html file. It took an hour of futzing around > > to finally figure out that the execution failure of the non- > > existent texi2html was silently ignored. :( > > I'm not too familiar with these tools TBH, > but makeinfo is used to generate html if --texi2html > is not passed to this gendocs.sh script. > texi2html docs also point to makeinfo being the > focus of development now. > > I've pushed my patch. > > cheers, > Pádraig > -- - Bruce
Re: gendocs broken?
OK. Figured it out. The manual_node tree gets populated by the script by default. I'm going to guess that the manual_section and manual_chapter trees were removed for some reason? My habit was to read the manual-by-section stuff rather than manual-by-node, but that is no big deal. On 06/17/18 12:11, Bruce Korb wrote: > Hi Pádraig, > > If "texi2html" is out of date, then how do I get HTML? > I want to keep my online docs up to date. If there's a better > way, I'm for that. I confess I don't closely track stuff so > when better ways come around, I need to find out by bumping > into something. This is such a bump. It would be convenient > if I could just tell the script to "make html" and it figured > out how to do that. :) Also, if it cannot (like I didn't have > texi2html installed), it should *FAIL* rather than silently > creating an empty html file. It took an hour of futzing around > to finally figure out that the execution failure of the non- > existent texi2html was silently ignored. :( > > Thank you! > > On 06/16/18 20:27, Pádraig Brady wrote: >> On 16/06/18 16:14, Bruce Korb wrote: >>>> html_split> eval 'env LANG= LC_MESSAGES= LC_ALL= LANGUAGE= texi2html >>> --output gnu-pw-mgr.html --split=node --node-files >>> --css-ref=/software/gnulib/manual.css -c TOP_NODE_UP_URL=/manual >>> "/u/gnu/proj/gnu-pw-mgr-bld/doc/gnu-pw-mgr.texi"' >>>>> html_split> env LANG= LC_MESSAGES= LC_ALL= LANGUAGE= texi2html >>> --output gnu-pw-mgr.html --split=node --node-files >>> --css-ref=/software/gnulib/manual.css -c TOP_NODE_UP_URL=/manual >>> /u/gnu/proj/gnu-pw-mgr-bld/doc/gnu-pw-mgr.texi >>> Option c is ambiguous (check, conf-dir, css-include, css-ref) >>> Try 'texi2html --help' for usage instructions. >>> >>> >>> Using "-conf" seems to work >>> >>> diff --git a/build-aux/gendocs.sh b/build-aux/gendocs.sh >>> index 9d418b9..3a64a14 100755 >>> --- a/build-aux/gendocs.sh >>> +++ b/build-aux/gendocs.sh >>> @@ -2,7 +2,7 @@ >>> # gendocs.sh -- generate a GNU manual in many formats. This script is >>> # mentioned in maintain.texi. See the help message below for usage >>> details. >>> >>> -scriptversion=2018-03-06.19 >>> +scriptversion=2018-06-16.16 >>> >>> # Copyright 2003-2018 Free Software Foundation, Inc. >>> # >>> @@ -58,7 +58,7 @@ EMAIL=webmast...@gnu.org # please override with --email >>> commonarg= # passed to all makeinfo/texi2html invcations. >>> dirargs= # passed to all tools (-I dir). >>> dirs= # -I directories. >>> -htmlarg="--css-ref=/software/gnulib/manual.css -c TOP_NODE_UP_URL=/manual" >>> +htmlarg="--css-ref=/software/gnulib/manual.css -conf >>> TOP_NODE_UP_URL=/manual" >>> infoarg=--no-split >>> generate_ascii=true >>> generate_html=true >>> >>> >> Do you need to use texi2html ? >> In any case -conf is not supported by texi2any or makeinfo. >> Does the following work for you? >> >> diff --git a/build-aux/gendocs.sh b/build-aux/gendocs.sh >> index 9d418b9..91c058d 100755 >> --- a/build-aux/gendocs.sh >> +++ b/build-aux/gendocs.sh >> @@ -59,6 +59,7 @@ commonarg= # passed to all makeinfo/texi2html invcations. >> dirargs= # passed to all tools (-I dir). >> dirs= # -I directories. >> htmlarg="--css-ref=/software/gnulib/manual.css -c TOP_NODE_UP_URL=/manual" >> +default_htmlarg=true >> infoarg=--no-split >> generate_ascii=true >> generate_html=true >> @@ -163,7 +164,7 @@ while test $# -gt 0; do >> --common)shift; commonarg=$1;; >> --docbook) docbook=yes;; >> --email) shift; EMAIL=$1;; >> ---html) shift; htmlarg=$1;; >> +--html) shift; default_htmlarg=false; htmlarg=$1;; >> --info) shift; infoarg=$1;; >> --no-ascii) generate_ascii=false;; >> --no-html) generate_ascii=false;; >> @@ -199,6 +200,11 @@ commonarg=" $dirargs $commonarg" >> # For most of the following, the base name is just $PACKAGE >> base=$PACKAGE >> >> +if $default_htmlarg && test -n "$use_texi2html"; then >> + # The legacy texi2html doesn't support TOP_NODE_UP_URL >> + htmlarg="--css-ref=/software/gnulib/manual.css" >> +fi >> + >> if test -n "$srcfile"; then >># but here, we use the basename of $srcfile >>base=`basename "$srcfile"` >> >> >> >> . >> > > >
Re: gendocs broken?
Hi Pádraig, If "texi2html" is out of date, then how do I get HTML? I want to keep my online docs up to date. If there's a better way, I'm for that. I confess I don't closely track stuff so when better ways come around, I need to find out by bumping into something. This is such a bump. It would be convenient if I could just tell the script to "make html" and it figured out how to do that. :) Also, if it cannot (like I didn't have texi2html installed), it should *FAIL* rather than silently creating an empty html file. It took an hour of futzing around to finally figure out that the execution failure of the non- existent texi2html was silently ignored. :( Thank you! On 06/16/18 20:27, Pádraig Brady wrote: > On 16/06/18 16:14, Bruce Korb wrote: >>> html_split> eval 'env LANG= LC_MESSAGES= LC_ALL= LANGUAGE= texi2html >> --output gnu-pw-mgr.html --split=node --node-files >> --css-ref=/software/gnulib/manual.css -c TOP_NODE_UP_URL=/manual >> "/u/gnu/proj/gnu-pw-mgr-bld/doc/gnu-pw-mgr.texi"' >>>> html_split> env LANG= LC_MESSAGES= LC_ALL= LANGUAGE= texi2html >> --output gnu-pw-mgr.html --split=node --node-files >> --css-ref=/software/gnulib/manual.css -c TOP_NODE_UP_URL=/manual >> /u/gnu/proj/gnu-pw-mgr-bld/doc/gnu-pw-mgr.texi >> Option c is ambiguous (check, conf-dir, css-include, css-ref) >> Try 'texi2html --help' for usage instructions. >> >> >> Using "-conf" seems to work >> >> diff --git a/build-aux/gendocs.sh b/build-aux/gendocs.sh >> index 9d418b9..3a64a14 100755 >> --- a/build-aux/gendocs.sh >> +++ b/build-aux/gendocs.sh >> @@ -2,7 +2,7 @@ >> # gendocs.sh -- generate a GNU manual in many formats. This script is >> # mentioned in maintain.texi. See the help message below for usage >> details. >> >> -scriptversion=2018-03-06.19 >> +scriptversion=2018-06-16.16 >> >> # Copyright 2003-2018 Free Software Foundation, Inc. >> # >> @@ -58,7 +58,7 @@ EMAIL=webmast...@gnu.org # please override with --email >> commonarg= # passed to all makeinfo/texi2html invcations. >> dirargs= # passed to all tools (-I dir). >> dirs= # -I directories. >> -htmlarg="--css-ref=/software/gnulib/manual.css -c TOP_NODE_UP_URL=/manual" >> +htmlarg="--css-ref=/software/gnulib/manual.css -conf >> TOP_NODE_UP_URL=/manual" >> infoarg=--no-split >> generate_ascii=true >> generate_html=true >> >> > Do you need to use texi2html ? > In any case -conf is not supported by texi2any or makeinfo. > Does the following work for you? > > diff --git a/build-aux/gendocs.sh b/build-aux/gendocs.sh > index 9d418b9..91c058d 100755 > --- a/build-aux/gendocs.sh > +++ b/build-aux/gendocs.sh > @@ -59,6 +59,7 @@ commonarg= # passed to all makeinfo/texi2html invcations. > dirargs= # passed to all tools (-I dir). > dirs= # -I directories. > htmlarg="--css-ref=/software/gnulib/manual.css -c TOP_NODE_UP_URL=/manual" > +default_htmlarg=true > infoarg=--no-split > generate_ascii=true > generate_html=true > @@ -163,7 +164,7 @@ while test $# -gt 0; do > --common)shift; commonarg=$1;; > --docbook) docbook=yes;; > --email) shift; EMAIL=$1;; > ---html) shift; htmlarg=$1;; > +--html) shift; default_htmlarg=false; htmlarg=$1;; > --info) shift; infoarg=$1;; > --no-ascii) generate_ascii=false;; > --no-html) generate_ascii=false;; > @@ -199,6 +200,11 @@ commonarg=" $dirargs $commonarg" > # For most of the following, the base name is just $PACKAGE > base=$PACKAGE > > +if $default_htmlarg && test -n "$use_texi2html"; then > + # The legacy texi2html doesn't support TOP_NODE_UP_URL > + htmlarg="--css-ref=/software/gnulib/manual.css" > +fi > + > if test -n "$srcfile"; then ># but here, we use the basename of $srcfile >base=`basename "$srcfile"` > > > > . >
gendocs broken?
>html_split> eval 'env LANG= LC_MESSAGES= LC_ALL= LANGUAGE= texi2html --output gnu-pw-mgr.html --split=node --node-files --css-ref=/software/gnulib/manual.css -c TOP_NODE_UP_URL=/manual "/u/gnu/proj/gnu-pw-mgr-bld/doc/gnu-pw-mgr.texi"' >>html_split> env LANG= LC_MESSAGES= LC_ALL= LANGUAGE= texi2html --output gnu-pw-mgr.html --split=node --node-files --css-ref=/software/gnulib/manual.css -c TOP_NODE_UP_URL=/manual /u/gnu/proj/gnu-pw-mgr-bld/doc/gnu-pw-mgr.texi Option c is ambiguous (check, conf-dir, css-include, css-ref) Try 'texi2html --help' for usage instructions. Using "-conf" seems to work diff --git a/build-aux/gendocs.sh b/build-aux/gendocs.sh index 9d418b9..3a64a14 100755 --- a/build-aux/gendocs.sh +++ b/build-aux/gendocs.sh @@ -2,7 +2,7 @@ # gendocs.sh -- generate a GNU manual in many formats. This script is # mentioned in maintain.texi. See the help message below for usage details. -scriptversion=2018-03-06.19 +scriptversion=2018-06-16.16 # Copyright 2003-2018 Free Software Foundation, Inc. # @@ -58,7 +58,7 @@ EMAIL=webmast...@gnu.org # please override with --email commonarg= # passed to all makeinfo/texi2html invcations. dirargs= # passed to all tools (-I dir). dirs= # -I directories. -htmlarg="--css-ref=/software/gnulib/manual.css -c TOP_NODE_UP_URL=/manual" +htmlarg="--css-ref=/software/gnulib/manual.css -conf TOP_NODE_UP_URL=/manual" infoarg=--no-split generate_ascii=true generate_html=true
Re: Bug#801825: autogen: non-free file "doc/gendocs_template" (CC-BY-ND-3.0)
On 10/14/15 16:15, Dmitry Smirnov wrote: Package: autogen Version: 1:5.18.6-3 Severity: important File "doc/gendocs_template" contains the following at line 82: This page is licensed under a http://creativecommons.org/licenses/by-nd/3.0/us/;>Creative Commons Attribution-NoDerivs 3.0 United States License. Please investigate. This file comes from gnulib.
Re: Compiling GNU Sharutils on NetBSD
On 04/06/15 11:26, HIRAMATSU Yoshifumi wrote: --- lib/fseeko.c.orig 2015-04-05 22:42:44.0 +0900 +++ lib/fseeko.c2015-04-05 22:42:52.0 +0900 @@ -125,7 +125,7 @@ fp-_flags = ~_IO_EOF_SEEN; fp-_offset = pos; #elif defined __sferror || defined __DragonFly__ /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin */ -# if defined __CYGWIN__ +# if defined __CYGWIN__ || (defined __NetBSD__ __NetBSD_Version__ = 6) /* fp_-_offset is typed as an integer. */ fp_-_offset = pos; # else $ grep -E $'^[ \t]*.*NetBSD' lib/fseeko.c Please let me know when this has been patched so I can re-roll sharutils. Thanks.
warning: case value '0' not in enumerated
gc-gnulib.c: In function 'gc_hash_open':
gc-gnulib.c:669:5: warning: case value '0' not in enumerated type
'Gc_hash_mode' [-Wswitch]
case 0:
^
diff --git a/lib/gc-gnulib.c b/lib/gc-gnulib.c
index a1276c9..ee60f85 100644
--- a/lib/gc-gnulib.c
+++ b/lib/gc-gnulib.c
@@ -664,15 +664,8 @@ gc_hash_open (Gc_hash hash, Gc_hash_mode mode,
gc_hash_handle * outhandle)
break;
}
- switch (mode)
-{
-case 0:
- break;
-
-default:
- rc = GC_INVALID_HASH;
- break;
-}
+ if (mode != 0)
+rc = GC_INVALID_HASH;
if (rc == GC_OK)
*outhandle = ctx;
That, or add to the definition of enum Gc_hash_mode:
GC_HMUNKNOWN = 0
Re: [PATCH] lib/parse-datetime.y: Add ability to parse output of GNU date(1)
On 02/02/15 09:27, Pádraig Brady wrote: On 02/02/15 16:41, Chris Lamb wrote: We are currently in a funny situation where GNU date can't parse its own output: $ date --date=$(date) date: invalid date ‘Mon 2 Feb 16:37:46 GMT 2015’ I don't think this will work as the output from date(1) is ambiguous. For example locales change change the output order, and names. In your example, date(1) can parse US locale default format, but not UK: $ date -d$(LC_TIME=en_GB date) date: invalid date ‘Mon 2 Feb 17:23:25 GMT 2015’ It would still be useful to make the ways for doing this more readily known. e.g. in examples: touch -t $(date --date @$(( $(date +%s) + 10 )) +%Y%m%d%H%M.%S) file set the modify time of file to 10 seconds from now. It's a little obtuse.
Re: [PATCH] lib/parse-datetime.y: Add ability to parse output of GNU date(1)
True. It was mostly a plea for some (findable) documentation. In truth, my most common usage is more like: touch -t $(date --date@$(( $(stat -c %Y file1) + 10 )) +%Y%m%d%H%M.%S ) file2 Still, I use such constructs rarely enough that I don't know what's reasonable. An example for use in touch would be nice: Display date suitable for use with touch(1): $ date --date @$seconds_since_epoch +%Y%m%d%H%M.%S This: $ date --date @$seconds --format=touch is probably a touch too much, but would be easier to remember. On Wed, Feb 4, 2015 at 10:05 AM, Jim Meyering j...@meyering.net wrote: On Wed, Feb 4, 2015 at 9:25 AM, Bruce Korb bruce.k...@gmail.com wrote: On 02/02/15 09:27, Pádraig Brady wrote: On 02/02/15 16:41, Chris Lamb wrote: We are currently in a funny situation where GNU date can't parse its own output: $ date --date=$(date) date: invalid date 'Mon 2 Feb 16:37:46 GMT 2015' I don't think this will work as the output from date(1) is ambiguous. For example locales change change the output order, and names. In your example, date(1) can parse US locale default format, but not UK: $ date -d$(LC_TIME=en_GB date) date: invalid date 'Mon 2 Feb 17:23:25 GMT 2015' It would still be useful to make the ways for doing this more readily known. e.g. in examples: touch -t $(date --date @$(( $(date +%s) + 10 )) +%Y%m%d%H%M.%S) file set the modify time of file to 10 seconds from now. It's a little obtuse. If you are willing to rely on GNU date's --date=... option, you can set FILE's mtime to 10 seconds in the future more concisely with this: touch -d '10 seconds' FILE
Re: gettext problems
On 12/06/14 15:05, Daiki Ueno wrote: Looking at sharutils/bootstrap, it invokes autopoint before gnulib-tool --import, and then pulls the 'gettext' module from Gnulib. That means intl.m4 and po.m4 will be replaced with Gnulib's version. I tried the attached patch and it seems to work. Yes, it does. Thank you. So I have two questions: why do you need 'gettext' module from Gnulib and why do you run autopoint before gnulib-tool --import? Somewhere along the line my toe was stubbed and running autopoint seemed to be indicated. I tried it, things got better and I had no reason to go back, until my toe was stubbed again. :) Since gnulib advertises itself as having the most up-to-the-second gettext, it seemed mighty odd that my installed version had a more recent version number than that of gnulib. Oh, well, your patch worked just fine. I now use my installed gettext and it is likely to be sufficiently up-to-date for my needs. Thank you! Regards, Bruce
gettext problems
I am getting this error message: *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext \ version 0.19 but the autoconf macros are from gettext version 0.18 Googling yields: https://www.gnu.org/software/gnulib/manual/html_node/gettextize-and-autopoint.html If you get an error message like *** error: gettext infrastructure mismatch: ..., it means that a new GNU gettext release was made, and its autoconf macros were integrated into Gnulib and now mismatch the po/ infrastructure. In this case, fetch and install the new GNU gettext release and run gettextize followed by gnulib-tool. and my gettext is the latest release and I synced gnulib immediately before stumbling on this problem. What's wrong? Do I need to install an older version of gettext? $ gettext --version|head -n2 gettext (GNU gettext-runtime) 0.19.3 Copyright (C) 1995-1997, 2000-2007 Free Software Foundation, Inc. $ autoconf --version|head -n2 autoconf (GNU Autoconf) 2.69 Copyright (C) 2012 Free Software Foundation, Inc. I think the gettext copyright date is out of date. It was released Oct this year. Thank you!
Re: gettext problems
Hi all, On 12/06/14 10:29, Bruce Korb wrote: I am getting this error message: *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext \ version 0.19 but the autoconf macros are from gettext version 0.18 What's wrong? Do I need to install an older version of gettext? I still do not know what the issue is, but I've kludged around the problem. A real, full-fledged, honest-to-God kludge: when gnulib-tool is done assembling the m4 directory, I copy over intl.m4 and gettext.m4 from my /usr/local/share/aclocal directory. It all works now. The problem is related (somehow) to gnulib-comp.m4. The original flavor of that file lives in gnulib/m4 and does not contain the string GNU_GETTEXT_VERSION, but the installed version does: $ find sharutils-bld -type f|xargs fgrep AM_GNU_GETTEXT_VERSION [...] sharutils-bld/m4/gnulib-comp.m4: AM_GNU_GETTEXT_VERSION([0.18.1]) Since all is the gettext maintainer and I am all out of time for this, I leave it to you-all to please be kind enough to figure out how to fix it once and for all. :) Thank you!! Regards, Bruce
Re: parse-duration.c - TIME_MAX conflict
On 06/17/14 09:06, Jonas 'Sortie' Termansen wrote: It actually turns out that POSIX has reserved the _MIN and _MAX suffixes for limits.h as stated in POSIX 2008 `2.2.2 The Name Space'. It has a nice table with all the POSIX namespace rules that you can view online: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02_02 Hmmm. Missed it. Probably wrong search term. Thank you. They still claim any symbol ending with '_t' and such a claim weakens the strength of their claim on name spaces. But since my name is not Don Quixote, I'm not going to try to push them to make a more modest and targeted name space claims.
Fwd: [bug-gettext] gettext ChangeLog
FYI -- Forwarded message -- From: Daiki Ueno u...@gnu.org Date: Mon, Jun 16, 2014 at 1:28 AM Subject: Re: [bug-gettext] gettext ChangeLog To: Bruce Korb bruce.k...@gmail.com Cc: bug-gettext bug-gett...@gnu.org Bruce Korb bruce.k...@gmail.com writes: Anyway, once that worked, the gnulib stuff populates the intl directory using gettext-provided scripts. Well and good, but the make dist chokes and dies because some ChangeLog thingy is not found in the intl dir. Another silly mistake, sorry. I dropped the ChangeLog creation when migrating to git-version-gen, but forgot to adjust Makefiles. I've just pushed the attached fix. For now, I just create a gibberish file on the fly. Works for me. Yes, please use this as a workaround until 0.19.2. Thanks for reporting. Regards, -- Daiki Ueno From ac9430edfd11fe8ad68705440805ea15979ed565 Mon Sep 17 00:00:00 2001 From: Daiki Ueno u...@gnu.org Date: Mon, 16 Jun 2014 16:48:33 +0900 Subject: [PATCH] intl: Stop installing ChangeLog.inst After the git-version-gen migration (commit fbf4e276), the creation of gettext-tools/intl/ChangeLog.inst in configure.ac was removed because we lost access to $RELEASE_DATE. Given that intl/VERSION provides enough information, simply drop the ChangeLog file. Problem reported by Bruce Korb in https://lists.gnu.org/archive/html/bug-gettext/2014-06/msg00022.html. * Makefile.in (install-data): Don't install ChangeLog.inst. (distclean): Don't remove ChangeLog.inst. (uninstall): Don't remove ChangeLog under $(gettextsrcdir)/intl. (dist): Don't include ChangeLog in the distribution. --- gettext-runtime/intl/ChangeLog | 15 +++ gettext-runtime/intl/Makefile.in | 10 ++ 2 files changed, 17 insertions(+), 8 deletions(-) diff --git a/gettext-runtime/intl/ChangeLog b/gettext-runtime/intl/ChangeLog index 1cca769..c131010 100644 --- a/gettext-runtime/intl/ChangeLog +++ b/gettext-runtime/intl/ChangeLog @@ -1,3 +1,18 @@ +2014-06-16 Daiki Ueno u...@gnu.org + + intl: Stop installing ChangeLog.inst + After the git-version-gen migration (commit fbf4e276), the + creation of gettext-tools/intl/ChangeLog.inst in configure.ac was + removed because we lost access to $RELEASE_DATE. Given that + intl/VERSION provides enough information, simply drop the + ChangeLog file. + Problem reported by Bruce Korb in + https://lists.gnu.org/archive/html/bug-gettext/2014-06/msg00022.html. + * Makefile.in (install-data): Don't install ChangeLog.inst. + (distclean): Don't remove ChangeLog.inst. + (uninstall): Don't remove ChangeLog under $(gettextsrcdir)/intl. + (dist): Don't include ChangeLog in the distribution. + 2014-06-10 Daiki Ueno u...@gnu.org * gettext 0.19.1 released. diff --git a/gettext-runtime/intl/Makefile.in b/gettext-runtime/intl/Makefile.in index 7151d39..4529551 100644 --- a/gettext-runtime/intl/Makefile.in +++ b/gettext-runtime/intl/Makefile.in @@ -460,7 +460,6 @@ install-data: all if test $(PACKAGE) = gettext-tools; then \ $(mkdir_p) $(DESTDIR)$(gettextsrcdir); \ $(INSTALL_DATA) VERSION $(DESTDIR)$(gettextsrcdir)/VERSION; \ - $(INSTALL_DATA) ChangeLog.inst $(DESTDIR)$(gettextsrcdir)/ChangeLog; \ dists=COPYING.LIB $(DISTFILES.common); \ for file in $$dists; do \ $(INSTALL_DATA) $(srcdir)/$$file \ @@ -571,7 +570,7 @@ uninstall: : ; \ fi if test $(PACKAGE) = gettext-tools; then \ - for file in VERSION ChangeLog COPYING.LIB $(DISTFILES.common) $(DISTFILES.generated); do \ + for file in VERSION COPYING.LIB $(DISTFILES.common) $(DISTFILES.generated); do \ rm -f $(DESTDIR)$(gettextsrcdir)/$$file; \ done; \ else \ @@ -622,11 +621,6 @@ clean: mostlyclean distclean: clean rm -f Makefile ID TAGS - if test $(PACKAGE) = gettext-runtime || test $(PACKAGE) = gettext-tools; then \ - rm -f ChangeLog.inst $(DISTFILES.normal); \ - else \ - : ; \ - fi maintainer-clean: distclean @echo This command is intended for maintainers to use; @@ -646,7 +640,7 @@ dist distdir: Makefile additional=$(DISTFILES.normal); \ fi; \ $(MAKE) $(DISTFILES.common) $(DISTFILES.generated) $$additional; \ - for file in ChangeLog $(DISTFILES.common) $(DISTFILES.generated) $$additional; do \ + for file in $(DISTFILES.common) $(DISTFILES.generated) $$additional; do \ if test -f $$file; then dir=.; else dir=$(srcdir); fi; \ cp -p $$dir/$$file $(distdir) || test $$file = Makefile.in || exit 1; \ done; \ -- 1.9.3
Re: parse-duration.c - TIME_MAX conflict
On 06/14/14 14:37, Bruce Korb wrote:
On 06/11/14 15:46, Jim Meyering wrote:
I wrote the patch, and tested by running this:
./gnulib-tool --create-testdir --dir=/tmp/x --with-tests --test
parse-duration
Excellent. Please push it, thank you!
Actually, it occurs to me that the result still uses TIME_MAX and, if not
guarded,
still conflicts with glibc's claim to a new name. I still think that
implementations
need an unambiguously distinct name space. *_MAX is too greedy.
diff --git a/ChangeLog b/ChangeLog
index 6fff9d7..4711a03 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2014-06-11 Bruce Korb bk...@gnu.org
+ Jim Meyering address@hidden
+
+ parse-duration: eliminate 68 year duration limit
+ * lib/parse-duration.c: Include intprops.h.
+ (TIME_MAX): rename to MAX_DURATION and define to
+ TYPE_MAXIMUM(time_t).
+ * modules/parse-duration (Depends-on): Add intprops.
+ Reported by Jonas 'Sortie' Termansen.
+
2014-06-14 Paul Eggert egg...@cs.ucla.edu
pthread: don't assume AC_CANONICAL_HOST, port better to Solaris, etc.
diff --git a/lib/parse-duration.c b/lib/parse-duration.c
index 037e81e..82a1193 100644
--- a/lib/parse-duration.c
+++ b/lib/parse-duration.c
@@ -27,6 +27,8 @@
#include stdlib.h
#include string.h
+#include intprops.h
+
#ifndef NUL
#define NUL '\0'
#endif
@@ -51,7 +53,8 @@ typedef enum {
#define SEC_PER_MONTH (SEC_PER_DAY * 30)
#define SEC_PER_YEAR(SEC_PER_DAY * 365)
-#define TIME_MAX0x7FFF
+#undef MAX_DURATION
+#define MAX_DURATIONTYPE_MAXIMUM(time_t)
/* Wrapper around strtoul that does not require a cast. */
static unsigned long
@@ -80,14 +83,14 @@ scale_n_add (time_t base, time_t val, int scale)
return BAD_TIME;
}
- if (val TIME_MAX / scale)
+ if (val MAX_DURATION / scale)
{
errno = ERANGE;
return BAD_TIME;
}
val *= scale;
- if (base TIME_MAX - val)
+ if (base MAX_DURATION - val)
{
errno = ERANGE;
return BAD_TIME;
diff --git a/modules/parse-duration b/modules/parse-duration
index 46288c0..6184dc4 100644
--- a/modules/parse-duration
+++ b/modules/parse-duration
@@ -6,6 +6,7 @@ lib/parse-duration.h
lib/parse-duration.c
Depends-on:
+intprops
configure.ac:
Re: parse-duration.c - TIME_MAX 2038 unpreparedness
On 06/10/14 17:49, Jim Meyering wrote: Why impose such a limit? I'd go with TYPE_MAXIMUM (time_t). a) because I do not read BASH headers (or any other headers) for fun. Unless I get bumped somehow, I don't know about such things, and b) like I said, if anybody on the planet really needs a time difference in excess of 68 years, I'd be mightily surprised. Now that I know about TYPE_MAXIMUM, I'll use it, sure. Meanwhile, please be re-assured that in the soon-to-come 24 years from now, an unmodified parse-duration will not choke. :)
Re: parse-duration.c - TIME_MAX 2038 unpreparedness
On 06/11/14 15:46, Jim Meyering wrote: I wrote the patch, and tested by running this: ./gnulib-tool --create-testdir --dir=/tmp/x --with-tests --test parse-duration Excellent. Please push it, thank you!
Re: parse-duration.c - TIME_MAX 2038 unpreparedness
On 06/01/14 10:04, Jonas 'Sortie' Termansen wrote: Hi, I noticed that lib/parse-duration.c does: #define TIME_MAX 0x7FFF This is naturally entirely unacceptable as the 2038 bug ((time_t) INT32_MAX) is coming up soon OK, I promise to fix it within the next 24 years. In truth, since this is a _duration_, it really constrains the result to be within 68 years. I did actually think about it for a few moments and decided a rigorous solution didn't warrant the effort. It would probably be best to not use a define named TIME_MAX, as that name would be ideal if a standard header wanted to expose the domain of time_t for use in cases like this (indeed, this came up because I am adding a TIME_MAX constant to my libc). I also Googled for a POSIX It's mine and you can't have it statement for the value name and got no results. I do kind-of like the DEC regime of prefixing values with SYS$, but that is another world. Since that value is used internally, I'll just prefix it with: #undef TIME_MAX and document the constraint that time differences beyond 68 years are not supported. Or maybe: #ifdef TIME_MAX #define TIME_LIMIT TIME_MAX #else #define TIME_LIMIT (((time_t)~0) 1) #endif But I really think 68 years will cover the need. :) Cheers - Bruce
Re: There is no returning
On 11/17/13 13:18, Ludovic Courtès wrote: What would you think of sticking to the standard and less problematic ‘_Noreturn’ identifier in Gnulib? (I also agree that it’s better for Guile’s public headers to use ‘__noreturn__’, but using ‘noreturn’ was not completely silly either.) noreturn is a C11 keyword and does not need #define-ing, except as a C11 compatibility thing. When you #include stdnoreturn.h, that token should work as expected. gnulib makes that available.
Re: There is no returning
On 11/10/13 00:13, Harlan Stenn wrote: Bruce, I'm seeing build errors on psp-fb1 with the guile headers as well, and autogen-5.18.2. Errors like this: /usr/bin/gcc-4.6 -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts \ -g -O2 -MT autogen-ag.o -MD -MP -MF .deps/autogen-ag.Tpo -c -o autogen-ag.o \ `test -f 'ag.c' || echo './'`ag.c In file included from /usr/include/libguile.h:40:0, from autogen.h:60, from ag.c:7: /usr/include/libguile/error.h:39:24: error: expected ')' before '__attribute__' /usr/include/libguile/error.h:39:24: error: expected ',' or ';' before ')' token The cause seems to be a bad interaction between gnulib's stdnoreturn module and the Guile headers. I'm chasing that now. # 28 /usr/include/libguile/error.h 3 4 extern SCM scm_system_error_key; extern SCM scm_num_overflow_key; extern SCM scm_out_of_range_key; extern SCM scm_args_number_key; extern SCM scm_arg_type_key; extern SCM scm_memory_alloc_key; extern SCM scm_misc_error_key; extern void scm_error (SCM key, const char *subr, const char *message, SCM args, SCM rest) __attribute__ ((__attribute__ ((__noreturn__; from the generated stdnoreturn.h: /* The definition of _Noreturn is copied here. */ #if !defined _Noreturn __STDC_VERSION__ 201112 # if (3 = __GNUC__ || (__GNUC__ == 2 8 = __GNUC_MINOR__) \ || 0x5110 = __SUNPRO_C) # define _Noreturn __attribute__ ((__noreturn__)) # elif 1200 = _MSC_VER # define _Noreturn __declspec (noreturn) # else # define _Noreturn # endif #endif [...] # define noreturn _Noreturn And looking into Guile sources: $ find /usr/include/libguile -type f|xargs grep -Ei '^#define.*noreturn' /usr/include/libguile/__scm.h:#define SCM_NORETURN __attribute__ ((noreturn)) So noreturn gets #define-d to: __attribute__ ((__noreturn__)) and SCM_NORETURN is: __attribute__ ((noreturn)) Too clever by way more than half. The correct fix is not obvious to me. It seems like the correct attribute spelling is: __attribute__ ((__noreturn__)) but the Guile code spells it in a way whereby gnulib fixes the thing. No way out.
Re: There is no returning
On 11/10/13 12:41, Paul Eggert wrote:
A better solution, if you want to be portable to
MSVC, is to use _Noreturn instead of noreturn.
This is for reasons described in stdnoreturn.in.h.
'_Noreturn' is a bit ugly; if you don't care about
MSVC, then __attribute__((__noreturn__)) is
a good way to go.
Hi Paul,
Thanks. As mentioned in the GCC pages, using the prefix/suffix
of __ is the right way to go -- for Guile. For me, I control
neither the gnulib variation on stdnoreturn.h nor the libguile/__scm.h
headers. So rather than unwinding noreturn attributes for
functions that do not return, I'll hack up some really ugly stuff:
This:
if GL_GENERATE_STDNORETURN_H
$(STDNORETURN_H) : libguile/__scm.h
libguile/__scm.h :
$(SHELL) $(srcdir)/fix-guile.sh $(LIBGUILE_CFLAGS)
endif
Plus this:
guile_scm_h=
while test $# -gt 0
do
case $1 in
-I )
test -f $2/libguile/__scm.h {
guile_scm_h=$2/libguile/__scm.h
break
}
;;
-I* )
f=${1#-I}
test -f $f/libguile/__scm.h {
guile_scm_h=$f/libguile/__scm.h
break
}
;;
esac
shift
done
test -z $guile_scm_h {
guile_scm_h=/usr/include/libguile/__scm.h
test -f $guile_scm_h || {
echo The Guile header __scm.h cannot be found
exit 1
} 12
}
test -d libguile || mkdir libguile || {
echo cannot make libguile directory
exit 1
} 12
sed $'/^#define[ \t]SCM_NORETURN/s/RETURN..*/RETURN _Noreturn/' \
$guile_scm_h libguile/__scm.h
Re: [PATCH] maint.mk: get current gnulib revision correctly.
On 10/27/13 17:46, Pádraig Brady wrote: gnulib_dir ?= $(srcdir)/gnulib -gnulib-version = $$(cd $(gnulib_dir) git describe) +gnulib-version = $$(cd $(gnulib_dir) git rev-parse --short HEAD) bootstrap-tools ?= autoconf,automake,gnulib ... This would change the announce message from: Gnulib v0.0-7848-g4a82904 to: Gnulib 4a82904 That, or /path/to/gnulib\nGnulib 4a82904 I'd suggest: gnulib-version = $$(cd $(gnulib_dir) /dev/null git rev-parse --short HEAD) because I've been bitten a number of times. (Hi Gary!) - Bruce
Is it me, or is git.sv.gnu.org down?
$ git pull ssh: Could not resolve hostname git.savannah.gnu.org: Name or service not known fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. $ ping -c2 git.sv.gnu.org PING git.sv.gnu.org (140.186.70.72) 56(84) bytes of data. 64 bytes from vcs.savannah.gnu.org (140.186.70.72): icmp_seq=1 ttl=49 time=121 ms 64 bytes from vcs.savannah.gnu.org (140.186.70.72): icmp_seq=2 ttl=49 time=121 ms --- git.sv.gnu.org ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 121.345/121.479/121.614/0.373 ms
_GL_INLINE_HEADER_BEGIN/END left behind
The compile error message: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lib -I../src -I../lib -I../libopts \ -I../libopts -g -O2 -MT pw-pw.o -MD -MP -MF .deps/pw-pw.Tpo \ -c -o pw-pw.o `test -f 'pw.c' || echo './'`pw.c In file included from pw.h:47:0, from pw.c:20: ../lib/unistd.h:603:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'extern' lib/unistd.h contains: 593 #if 1 594 # if 0 595 /* Automatically included by modules that need a replacement for close. */ 596 # if !(defined __cplusplus defined GNULIB_NAMESPACE) 597 # undef close 598 # define close rpl_close 599 # endif 600 _GL_FUNCDECL_RPL (close, int, (int fd)); 601 _GL_CXXALIAS_RPL (close, int, (int fd)); 602 # else 603 _GL_CXXALIAS_SYS (close, int, (int fd)); 604 # endif 605 _GL_CXXALIASWARN (close); 606 #elif 0 607 # undef close 608 # define close close_used_without_requesting_gnulib_module_close 609 #elif defined GNULIB_POSIXCHECK 610 # undef close 611 /* Assume close is always declared. */ 612 _GL_WARN_ON_USE (close, close does not portably work on sockets - 613 use gnulib module close for portability); 614 #endif The post-pre-processed result: _GL_INLINE_HEADER_BEGIN # 603 ../lib/unistd.h 3 extern int _gl_cxxalias_dummy; extern int _gl_cxxalias_dummy; # 1839 ../lib/unistd.h 3 _GL_INLINE_HEADER_END GCC doesn't like that _GL_INLINE_HEADER_xxx stuff.
Re: getopt: checking exlusive options?
On 07/23/13 08:55, Bernhard Voelker wrote: Okay, there is the gengetopt project [2], but this doesn't seem to be ideal for simplifying existing code. [1] http://git.kernel.org/?p=utils/util-linux/util-linux.git;a=blob;f=include/optutils.h [2] http://www.gnu.org/software/gengetopt/ http://www.gnu.org/software/autogen/manual/html_node/AutoOpts.html#AutoOpts
Re: sig2str and str2sig use in C++
On 06/10/13 22:41, Paul Eggert wrote:
Maybe someone else can come up with something even better.
This:
#define SIG_OFFSET_AFTER_START 0
static char const sig_strings[] =
#ifdef SIGHUP
#define SIG_HUP_OFFSET SIG_OFFSET_AFTER_START
#define SIG_OFFSET_AFTER_HUP (SIG_OFFSET_AFTER_START + 4)
HUP\0
#else
#define SIG_OFFSET_AFTER_HUP SIG_OFFSET_AFTER_START
#endif
#ifdef SIGINT
#define SIG_INT_OFFSET SIG_OFFSET_AFTER_HUP
#define SIG_OFFSET_AFTER_INT (SIG_OFFSET_AFTER_HUP + 4)
INT\0
#else
#define SIG_OFFSET_AFTER_INT SIG_OFFSET_AFTER_HUP
#endif
[...]
static unsigned int sig_offsets[] = {
#ifdef SIGHUP
[SIGHUP] = SIG_HUP_OFFSET,
#endif
#ifdef SIGINT
[SIGINT] = SIG_INT_OFFSET,
#endif
derived from the attached files?
AutoGen Definitions sig2str;
sig = HUP, INT, QUIT,ILL, TRAP,ABRT,FPE,
KILL,SEGV,BUS, PIPE,ALRM,TERM,USR1,
USR2,CHLD,URG, STOP,TSTP,CONT,TTIN,
TTOU,SYS, POLL,VTALRM, PROF,XCPU,XFSZ,
IOT, EMT, PHONE, WIND,CLD, PWR, CANCEL,
LWP, WAITING, FREEZE, THAW,LOST,WINCH, INFO,
IO, STKFLT, DANGER, GRANT, MIGRATE, MSG, PRE,
RETRACT, SAK, SOUND, ALRM1, KAP, VIRT,WINDOW,
KILLTHR, DIL;
sig2str.tpl
Description: application/vnd.groove-tool-template
Re: sig2str and str2sig use in C++
On 06/13/13 12:32, Daniel J Sebald wrote: derived from the attached files? That's pretty nice Bruce. Please explain how this will be used in the build process, just so I understand. Not all users of gnulib necessarily have code generation tools, so the generated file needs to get checked into gnulib. I've attached a full patch this time. So the generated file (sig2str-def.c) gets built by gnulib maintainers whenever they need to modify the signal list or change the format of the resulting sig2str-def.c file. ... If I'm following, the first stage is that autoconf (?) will look through all definitions for those beginning with SIG and then create Nope. The thing gets nailed down at compile time based on what SIGxxx macros get defined in signal.h. The offsets to every string are computed by the compiler based on the text the C pre-processor lets the compiler see. The list of potential signals needs to be known by gnulib maintainers. It feels that we are working toward creating a table that doesn't group according to the signal number (i.e., synonyms), Correct. It is basically unordered, though it is close to numerical order. But since it's not 100%, you have to treat it as unordered. The ordering is actually the order of the definitions in sig2str.def. I suppose that is a more initial expectation for how such a thing would be organized. It does feel a little unusual. Cheers - Bruce From 93d1de20ca8881c58b276534393f370735c5b5e1 Mon Sep 17 00:00:00 2001 From: Bruce Korb bk...@gnu.org Date: Thu, 13 Jun 2013 13:30:18 -0700 Subject: [PATCH] make strings static const data minimizing fixup * lib/sig2str.def: list of potential signal names * lib/sig2str.tpl: conversion instructions from list to sig2str-def.c * lib/sig2str-def.c: derived from the above two files * lib/sig2str.c: remove the data generated above (str2signum): adjust data references (sig2str): likewise --- lib/sig2str-def.c | 648 ++ lib/sig2str.c | 218 +- lib/sig2str.def | 21 ++ lib/sig2str.tpl | 36 +++ 4 files changed, 710 insertions(+), 213 deletions(-) create mode 100644 lib/sig2str-def.c create mode 100644 lib/sig2str.def create mode 100644 lib/sig2str.tpl diff --git a/lib/sig2str-def.c b/lib/sig2str-def.c new file mode 100644 index 000..feb45df --- /dev/null +++ b/lib/sig2str-def.c @@ -0,0 +1,648 @@ + +#define SIG_OFFSET_AFTER_START 0 + +static char const sig_strings[] = +#ifdef SIGHUP +#define SIG_HUP_OFFSET SIG_OFFSET_AFTER_START + HUP\0 +#define SIG_OFFSET_AFTER_HUP (SIG_OFFSET_AFTER_START + 4) +#else +#define SIG_OFFSET_AFTER_HUP SIG_OFFSET_AFTER_START +#endif + +#ifdef SIGINT +#define SIG_INT_OFFSET SIG_OFFSET_AFTER_HUP + INT\0 +#define SIG_OFFSET_AFTER_INT (SIG_OFFSET_AFTER_HUP + 4) +#else +#define SIG_OFFSET_AFTER_INT SIG_OFFSET_AFTER_HUP +#endif + +#ifdef SIGQUIT +#define SIG_QUIT_OFFSET SIG_OFFSET_AFTER_INT + QUIT\0 +#define SIG_OFFSET_AFTER_QUIT (SIG_OFFSET_AFTER_INT + 5) +#else +#define SIG_OFFSET_AFTER_QUIT SIG_OFFSET_AFTER_INT +#endif + +#ifdef SIGILL +#define SIG_ILL_OFFSET SIG_OFFSET_AFTER_QUIT + ILL\0 +#define SIG_OFFSET_AFTER_ILL (SIG_OFFSET_AFTER_QUIT + 4) +#else +#define SIG_OFFSET_AFTER_ILL SIG_OFFSET_AFTER_QUIT +#endif + +#ifdef SIGTRAP +#define SIG_TRAP_OFFSET SIG_OFFSET_AFTER_ILL + TRAP\0 +#define SIG_OFFSET_AFTER_TRAP (SIG_OFFSET_AFTER_ILL + 5) +#else +#define SIG_OFFSET_AFTER_TRAP SIG_OFFSET_AFTER_ILL +#endif + +#ifdef SIGABRT +#define SIG_ABRT_OFFSET SIG_OFFSET_AFTER_TRAP + ABRT\0 +#define SIG_OFFSET_AFTER_ABRT (SIG_OFFSET_AFTER_TRAP + 5) +#else +#define SIG_OFFSET_AFTER_ABRT SIG_OFFSET_AFTER_TRAP +#endif + +#ifdef SIGFPE +#define SIG_FPE_OFFSET SIG_OFFSET_AFTER_ABRT + FPE\0 +#define SIG_OFFSET_AFTER_FPE (SIG_OFFSET_AFTER_ABRT + 4) +#else +#define SIG_OFFSET_AFTER_FPE SIG_OFFSET_AFTER_ABRT +#endif + +#ifdef SIGKILL +#define SIG_KILL_OFFSET SIG_OFFSET_AFTER_FPE + KILL\0 +#define SIG_OFFSET_AFTER_KILL (SIG_OFFSET_AFTER_FPE + 5) +#else +#define SIG_OFFSET_AFTER_KILL SIG_OFFSET_AFTER_FPE +#endif + +#ifdef SIGSEGV +#define SIG_SEGV_OFFSET SIG_OFFSET_AFTER_KILL + SEGV\0 +#define SIG_OFFSET_AFTER_SEGV (SIG_OFFSET_AFTER_KILL + 5) +#else +#define SIG_OFFSET_AFTER_SEGV SIG_OFFSET_AFTER_KILL +#endif + +#ifdef SIGBUS +#define SIG_BUS_OFFSET SIG_OFFSET_AFTER_SEGV + BUS\0 +#define SIG_OFFSET_AFTER_BUS (SIG_OFFSET_AFTER_SEGV + 4) +#else +#define SIG_OFFSET_AFTER_BUS SIG_OFFSET_AFTER_SEGV +#endif + +#ifdef SIGPIPE +#define SIG_PIPE_OFFSET SIG_OFFSET_AFTER_BUS + PIPE\0 +#define SIG_OFFSET_AFTER_PIPE (SIG_OFFSET_AFTER_BUS + 5) +#else +#define SIG_OFFSET_AFTER_PIPE SIG_OFFSET_AFTER_BUS +#endif + +#ifdef SIGALRM +#define SIG_ALRM_OFFSET SIG_OFFSET_AFTER_PIPE + ALRM\0 +#define SIG_OFFSET_AFTER_ALRM (SIG_OFFSET_AFTER_PIPE + 5) +#else +#define SIG_OFFSET_AFTER_ALRM SIG_OFFSET_AFTER_PIPE +#endif + +#ifdef SIGTERM +#define SIG_TERM_OFFSET SIG_OFFSET_AFTER_ALRM + TERM\0 +#define SIG_OFFSET_AFTER_TERM
The real patch
I copied something inexpertly. EXIT needs to be added to the string array and the offset table needs the offset to it. From f1db6e39e6ea4d7ba0af2f1dbb281b2a0f481b5e Mon Sep 17 00:00:00 2001 From: Bruce Korb bk...@gnu.org Date: Thu, 13 Jun 2013 13:38:40 -0700 Subject: [PATCH] make strings static const data minimizing fixup * lib/sig2str.def: list of potential signal names * lib/sig2str.tpl: conversion instructions from list to sig2str-def.c * lib/sig2str-def.c: derived from the above two files * lib/sig2str.c: remove the data generated above (str2signum): adjust data references (sig2str): likewise --- .gitignore| 1 + lib/sig2str-def.c | 651 ++ lib/sig2str.c | 218 +- lib/sig2str.def | 21 ++ lib/sig2str.tpl | 34 +++ 5 files changed, 712 insertions(+), 213 deletions(-) create mode 100644 lib/sig2str-def.c create mode 100644 lib/sig2str.def create mode 100644 lib/sig2str.tpl diff --git a/.gitignore b/.gitignore index b95fb40..a9c2270 100644 --- a/.gitignore +++ b/.gitignore @@ -6,3 +6,4 @@ allsnippets.tmp amsnippet.tmp testdir* +/patches diff --git a/lib/sig2str-def.c b/lib/sig2str-def.c new file mode 100644 index 000..7c9234f --- /dev/null +++ b/lib/sig2str-def.c @@ -0,0 +1,651 @@ + +#define SIG_OFFSET_AFTER_START 0 + +static char const sig_strings[] = +#ifdef SIGHUP +#define SIG_HUP_OFFSET SIG_OFFSET_AFTER_START + HUP\0 +#define SIG_OFFSET_AFTER_HUP (SIG_OFFSET_AFTER_START + 4) +#else +#define SIG_OFFSET_AFTER_HUP SIG_OFFSET_AFTER_START +#endif + +#ifdef SIGINT +#define SIG_INT_OFFSET SIG_OFFSET_AFTER_HUP + INT\0 +#define SIG_OFFSET_AFTER_INT (SIG_OFFSET_AFTER_HUP + 4) +#else +#define SIG_OFFSET_AFTER_INT SIG_OFFSET_AFTER_HUP +#endif + +#ifdef SIGQUIT +#define SIG_QUIT_OFFSET SIG_OFFSET_AFTER_INT + QUIT\0 +#define SIG_OFFSET_AFTER_QUIT (SIG_OFFSET_AFTER_INT + 5) +#else +#define SIG_OFFSET_AFTER_QUIT SIG_OFFSET_AFTER_INT +#endif + +#ifdef SIGILL +#define SIG_ILL_OFFSET SIG_OFFSET_AFTER_QUIT + ILL\0 +#define SIG_OFFSET_AFTER_ILL (SIG_OFFSET_AFTER_QUIT + 4) +#else +#define SIG_OFFSET_AFTER_ILL SIG_OFFSET_AFTER_QUIT +#endif + +#ifdef SIGTRAP +#define SIG_TRAP_OFFSET SIG_OFFSET_AFTER_ILL + TRAP\0 +#define SIG_OFFSET_AFTER_TRAP (SIG_OFFSET_AFTER_ILL + 5) +#else +#define SIG_OFFSET_AFTER_TRAP SIG_OFFSET_AFTER_ILL +#endif + +#ifdef SIGABRT +#define SIG_ABRT_OFFSET SIG_OFFSET_AFTER_TRAP + ABRT\0 +#define SIG_OFFSET_AFTER_ABRT (SIG_OFFSET_AFTER_TRAP + 5) +#else +#define SIG_OFFSET_AFTER_ABRT SIG_OFFSET_AFTER_TRAP +#endif + +#ifdef SIGFPE +#define SIG_FPE_OFFSET SIG_OFFSET_AFTER_ABRT + FPE\0 +#define SIG_OFFSET_AFTER_FPE (SIG_OFFSET_AFTER_ABRT + 4) +#else +#define SIG_OFFSET_AFTER_FPE SIG_OFFSET_AFTER_ABRT +#endif + +#ifdef SIGKILL +#define SIG_KILL_OFFSET SIG_OFFSET_AFTER_FPE + KILL\0 +#define SIG_OFFSET_AFTER_KILL (SIG_OFFSET_AFTER_FPE + 5) +#else +#define SIG_OFFSET_AFTER_KILL SIG_OFFSET_AFTER_FPE +#endif + +#ifdef SIGSEGV +#define SIG_SEGV_OFFSET SIG_OFFSET_AFTER_KILL + SEGV\0 +#define SIG_OFFSET_AFTER_SEGV (SIG_OFFSET_AFTER_KILL + 5) +#else +#define SIG_OFFSET_AFTER_SEGV SIG_OFFSET_AFTER_KILL +#endif + +#ifdef SIGBUS +#define SIG_BUS_OFFSET SIG_OFFSET_AFTER_SEGV + BUS\0 +#define SIG_OFFSET_AFTER_BUS (SIG_OFFSET_AFTER_SEGV + 4) +#else +#define SIG_OFFSET_AFTER_BUS SIG_OFFSET_AFTER_SEGV +#endif + +#ifdef SIGPIPE +#define SIG_PIPE_OFFSET SIG_OFFSET_AFTER_BUS + PIPE\0 +#define SIG_OFFSET_AFTER_PIPE (SIG_OFFSET_AFTER_BUS + 5) +#else +#define SIG_OFFSET_AFTER_PIPE SIG_OFFSET_AFTER_BUS +#endif + +#ifdef SIGALRM +#define SIG_ALRM_OFFSET SIG_OFFSET_AFTER_PIPE + ALRM\0 +#define SIG_OFFSET_AFTER_ALRM (SIG_OFFSET_AFTER_PIPE + 5) +#else +#define SIG_OFFSET_AFTER_ALRM SIG_OFFSET_AFTER_PIPE +#endif + +#ifdef SIGTERM +#define SIG_TERM_OFFSET SIG_OFFSET_AFTER_ALRM + TERM\0 +#define SIG_OFFSET_AFTER_TERM (SIG_OFFSET_AFTER_ALRM + 5) +#else +#define SIG_OFFSET_AFTER_TERM SIG_OFFSET_AFTER_ALRM +#endif + +#ifdef SIGUSR1 +#define SIG_USR1_OFFSET SIG_OFFSET_AFTER_TERM + USR1\0 +#define SIG_OFFSET_AFTER_USR1 (SIG_OFFSET_AFTER_TERM + 5) +#else +#define SIG_OFFSET_AFTER_USR1 SIG_OFFSET_AFTER_TERM +#endif + +#ifdef SIGUSR2 +#define SIG_USR2_OFFSET SIG_OFFSET_AFTER_USR1 + USR2\0 +#define SIG_OFFSET_AFTER_USR2 (SIG_OFFSET_AFTER_USR1 + 5) +#else +#define SIG_OFFSET_AFTER_USR2 SIG_OFFSET_AFTER_USR1 +#endif + +#ifdef SIGCHLD +#define SIG_CHLD_OFFSET SIG_OFFSET_AFTER_USR2 + CHLD\0 +#define SIG_OFFSET_AFTER_CHLD (SIG_OFFSET_AFTER_USR2 + 5) +#else +#define SIG_OFFSET_AFTER_CHLD SIG_OFFSET_AFTER_USR2 +#endif + +#ifdef SIGURG +#define SIG_URG_OFFSET SIG_OFFSET_AFTER_CHLD + URG\0 +#define SIG_OFFSET_AFTER_URG (SIG_OFFSET_AFTER_CHLD + 4) +#else +#define SIG_OFFSET_AFTER_URG SIG_OFFSET_AFTER_CHLD +#endif + +#ifdef SIGSTOP +#define SIG_STOP_OFFSET SIG_OFFSET_AFTER_URG + STOP\0 +#define SIG_OFFSET_AFTER_STOP (SIG_OFFSET_AFTER_URG + 5) +#else +#define SIG_OFFSET_AFTER_STOP SIG_OFFSET_AFTER_URG +#endif + +#ifdef SIGTSTP +#define
Re: (sharutils) make distclean removes doc/uudecode.1
Hi Bob, Thank you for your pointers! Bob wrote: Bruce Korb wrote: The last dinkleberry has to do with libintl. On OS/X: You have LD_LIBRARY_PATH set including /usr/local/lib? It was forced (and done by hand) because without it: $ unset LD_LIBRARY_PATH $ ldd ../src/shar libintl.so.8 = not found I don't know about OS/X so this response may not be useful. I confess, I don't develop much on OS/X. I was granted access to a mess of build platforms at U of Utah and this is just one. I ran a script that did the same thing on all platforms: mkdir /local/shar-$$ \ cd /local/shar-$$ \ configure ~/shar-src \ make \ make check \ make install DESTDIR=$HOME/_$(uname -n) \ rm -rf /local/shar-$$ To my naive way of thinking, that should just work. The configure step clearly figures out that libintl lives in /usr/local, but the build instructions don't do the right thing to yield a working executable: It _looks_ like it finds libintl in /usr/local/lib and then links the executables without marking it with: -Wl,-rpath -Wl,/usr/local/lib Shouldn't that incantation be pretty automatic? The issue of rpath has been a hot-button of contention over the years. It is similar to the conflict between searching for executables using PATH and hard coding the full path to executables. Rpath should not be needed if the ld.so is configured properly. OK, so when someone complains I should say, works as designed? Just how hard is it to test to see if /path/to/libintl.so is in the default link/loader path for a platform? Then, if not, either link against libintl.a or do the proper incantation to make the link/loader look there at run time. How hard can that be? What I _don't_ want is for configure to say all is well and then have the program fall over because it really wasn't. Therefore I would look there for the problem and solution first. If it were my platform, I'd just fix it. I am not an admin, but a guest being given the opportunity to test a release before releasing it. I guess I like simple solutions. Do thus and so and all is well. *sigh*. Thanks - Bruce
Re: Building sharutils 4.13.4 with MinGW
On 04/07/13 10:35, Eli Zaretskii wrote: Here are the MinGW-specific problems with building and testing this release (copy to gnulib list, because many issues are related to gnulib modules). 1. Compilation fails in lib/: This is because idcache.h includes sys/types.h, but gnulib's sys/types.h does not define uid_t and gid_t, and also there are no pwd.h and grp.h in lib/. My solution was to add private pwd.h and grp.h to lib/, and modify idcache.h to include them. But I guess a better solution would be to import more from gnulib, or perhaps enhance the corresponding gnulib modules. Indeed. enhance the corresponding gnulib modules because gnulib is supposed to recursively include everything needed. 2. Compilation warning in lib/: This is because functions getpwuid and getgrgid are unavailable and there are no replacements for them in gnulib. To solve this, I added the missing functions to idcache.c: That would require gnulib cooperation, too. Otherwise, I have to glue it into sources I control. 3. Compilation warnings in src/shar.c: gcc -DLOCALEDIR=\d:/usr/share/locale\ -DHAVE_CONFIG_H -I. -I.. -I../libopts -I. -I.. -I../lib -I../intl -Id:/usr/include -Wno-format-contains-nul -g3 -O2 -Wno-format-contains-nul -MT shar.o -MD -MP -MF .deps/shar.Tpo -c -o shar.o shar.c shar.c: In function 'walktree': shar.c:595:18: warning: assignment makes pointer from integer without a cast [enabled by default] shar.c: In function 'set_submitter': shar.c:1943:18: warning: initialization makes pointer from integer without a cast [enabled by default] make[2]: *** [shar.o] Error 1 The problem here is with basename and dirname, whose declarations are absent. My solution was to add #include libgen.h to lib/system.h (libgen.h in MinGW declares basename and dirname). However, I wonder if gnulib has a better solution. I would hope. Thanks. 4. Link errors for shar.exe: Solution: reorder in src/Makefile.in: Pasted into my Makefile.am. For the other errors: I wrote emulations for fork (always fails), wait (always fails) and pipe (calls _pipe), and also add getuid, getpwnam and getgrnam to idcache.c. However, I think gnulib has replacements for at least some of these functions. Not that I can find. $ list=$(find * -type f) $ fgrep getuid $list $ fgrep getpwnam $list $ fgrep getgrnam $list $ echo $list|egrep getuid|getpwnam|getgrnam $ 5. Link errors for unshar.exe: Solution: add mkstemp to unshar.c. Again, I think gnulib has a module for that, so importing it will solve this. Done. (Added to gnulib modules) 6. uutest-1 test fails because the begin line doesn't match. This is because the mode bits on Windows are not real, beyond the user-read and user-write bits. So it would be nice if on Windows Diff would be invoked like this: DIFF=diff -I^begin 7. shar-4 fails because it uses cmp to compare results with expected ones, which fails due to line endings. Suggest to use Diff instead. Could you suggest a patch for these two, too? :) Maybe a script test so that I know that I have to: sed 's/^begin [0-7][0-7][0-7] /begin 664/' the result file. 8. The configure script botches the popen-binary test: the test program does not include stdio.h, so the compilation fails for reasons that have no relation to the issue being tested. gnulib 9. Using -! or --more-help triggers an error message: d:\usr\eli\utils\sharutils-4.13.4uuencode -! uuencode: illegal option -- ! uuencode (GNU sharutils) - encode a file into email friendly text Usage: uuencode [ -flag | --name ]... [in-file] output-name Try 'uuencode --help' for more information. This is confusing because --help does show these options as available. The reason is that uuencode-options.c does this: #if HAVE_WORKING_FORK #define MORE_HELP_DESC (uuencode_opt_strs+1045) #define MORE_HELP_name (uuencode_opt_strs+1090) #define MORE_HELP_FLAGS (OPTST_IMM | OPTST_NO_INIT) #else #define MORE_HELP_DESC NULL #define MORE_HELP_name NULL #define MORE_HELP_FLAGS (OPTST_OMITTED | OPTST_NO_INIT) #endif which is unnecessary, since the relevant libopts code already knows how to handle the case of !HAVE_WORKING_FORK. = Fixed by enabling the !HAVE_WORKING_FORK block above. Same in shar-opts.c and uudecode-opts.c. Lovely. This is a dilemma. In order to facilitate i18n, I cannot compute help text on the fly. If I don't compute it on the fly, then it has to be the same text for all platforms. I guess I should set it up to handle it -- only handle it as if it were plain help. Rats. All four *-opts.c have the issue. I've modified the source template: #ifdef HAVE_WORKING_FORK #define MORE_HELP_DESC ([=junk=]) #define MORE_HELP_name ([=more junk=]) #define MORE_HELP_FLAGS
Re: [PATCH] Add support for ISO 8601 basic format
The time-difference module, too? On 03/30/13 12:18, Mihai Capotă wrote: + /* ISO 8601 basic date and time of day representation, + 'T' separator, local time zone */ + p = 20110501T115518; + /* ISO 8601 basic date and time of day representation, + 'T' separator, UTC */ + p = 20110501T115518Z; + /* ISO 8601 basic date and time of day representation, + 'T' separator, w/UTC offset */ + p = 20110501T115518-0700; + /* ISO 8601 basic date and time of day representation, + 'T' separator, w/hour only UTC offset */ + p = 20110501T115518-07; + /* ISO 8601 basic date and time of day representation, + 'T' separator, w/hour only UTC offset, with ns */ + p = 20110501T115518,123456789-07;
Re: errno -- errno name ?
On 03/20/13 01:54, Thien-Thi Nguyen wrote: Polish, test, and finally submit the result here. Is there still any interest in this work? This works. Needs to be made portable. Needs some sort of module thing. It amused me to do, but I doubt I'd find time to so all the gnulib polishing. Should build straight away on any Linux platform. errno.txz Description: application/xz-compressed-tar
Re: You may need to add #include directives for the following .h files
On 01/27/13 05:35, Gary V. Vaughan wrote: On 27 Jan 2013, at 03:27, Bruce Korb bruce.k...@gmail.com wrote: Hi Gary, Hey Bruce! Speaking of bootstrap wishes, Hi Gary, Follow up: worked like a charm! Thank you. I use *two* bootstrap.conf files: one by that name and another: bootstrap.std wherein I have my standard stuff. This now goes into my standard stuff, thank you. I also renamed the function, since it is not actually being used in sharutils. It was enough trouble just getting rid of all the old me_FOOBAR autoconf macros. I'm sure it is the reason behind the three dozen header files. They cannot all really be needed... For your amusement, the transcribed functions and my standard stuff are attached and work for me. The bulk consists of your functions, but I also added support for back traces on failure and a failure die function. die differs from the func_error_fatal in that it kills off everything even from within a subshell and it invokes the backtrace function. That latter is a handy thing often enough that I use it. Also, I don't know how you use $debug_cmd, but for me this works very well: PS4='$FUNCNAME ' You always know which function was active for every xtrace entry. Again, thank you! Cheers - Bruce bootstrap.std Description: OpenOffice Draw Template
gnupload ??
$ ../gnulib/build-aux/gnupload --to ftp.gnu.org:sharutils sharutils-4.13.3.tar.xz ../gnulib/build-aux/gnupload: Reading configuration file .gnuploadrc Enter GPG passphrase: Signing sharutils-4.13.3.tar.xz ... Uploading sharutils-4.13.3.tar.xz to ftp.gnu.org:sharutils ... sharutils-4.13.3.tar.xz: 939.65 kB 76.84 kB/s sharutils-4.13.3.tar.xz.sig: 198.00 B 793.45 B/s sharutils-4.13.3.tar.xz.directive.asc: 348.00 B 1.35 kB/s Uploading sharutils-4.13.3.tar.xz to ftp.gnu.org:sharutils ... ncftpput sharutils-4.13.3.tar.xz: server said: Could not create file. ncftpput sharutils-4.13.3.tar.xz.sig: server said: Could not create file. ncftpput sharutils-4.13.3.tar.xz.directive.asc: server said: Could not create file. It worked with this command line for sharutils-4.13.3.tar.gz http://ftp.gnu.org/gnu/sharutils/?C=M;O=D What is the difference?
Re: gnupload ??
I give up. I don't understand the messages. I got these same messages yesterday and the xz file did not show up. I tried it again today, and I believed these messages. I also just now got confirmation that the files are there and I checked. They are there. Beats heck out of me. On 01/07/13 05:34, Bruce Korb wrote: $ ../gnulib/build-aux/gnupload --to ftp.gnu.org:sharutils sharutils-4.13.3.tar.xz ../gnulib/build-aux/gnupload: Reading configuration file .gnuploadrc Enter GPG passphrase: Signing sharutils-4.13.3.tar.xz ... Uploading sharutils-4.13.3.tar.xz to ftp.gnu.org:sharutils ... sharutils-4.13.3.tar.xz: 939.65 kB 76.84 kB/s sharutils-4.13.3.tar.xz.sig: 198.00 B 793.45 B/s sharutils-4.13.3.tar.xz.directive.asc: 348.00 B 1.35 kB/s Uploading sharutils-4.13.3.tar.xz to ftp.gnu.org:sharutils ... ncftpput sharutils-4.13.3.tar.xz: server said: Could not create file. ncftpput sharutils-4.13.3.tar.xz.sig: server said: Could not create file. ncftpput sharutils-4.13.3.tar.xz.directive.asc: server said: Could not create file. It worked with this command line for sharutils-4.13.3.tar.gz http://ftp.gnu.org/gnu/sharutils/?C=M;O=D What is the difference?
Re: gnupload ??
On Mon, Jan 7, 2013 at 2:16 PM, Karl Berry k...@freefriends.org wrote: Uploading sharutils-4.13.3.tar.xz to ftp.gnu.org:sharutils ... sharutils-4.13.3.tar.xz: 939.65 kB 76.84 kB/s ... Uploading sharutils-4.13.3.tar.xz to ftp.gnu.org:sharutils ... ncftpput sharutils-4.13.3.tar.xz: server said: Could not create file. ... Sure looks like gnupload is uploading your release twice. Don't know why. Hasn't been happening for me. That would explain it. Yesterday, I got the same message for the xz file, so I did try to push that file several times. It didn't go until I tried it again today, getting the messages you see. However, this time it worked. Sure seemed weird to me! Thank you - Bruce
Re: error: md5.c invalid use of void expression
On 01/04/13 15:27, Bruce Korb wrote:
This fixes it:
261 memcpy (ctx-buffer, buffer, 64);
262 md5_process_block (ctx-buffer, 64, ctx);
There's no particular reason for having a nested call there anyway.
From 200eb0ed19376b71f4ca8706c1db83be21a59372 Mon Sep 17 00:00:00 2001
From: Bruce Korb bk...@gnu.org
Date: Fri, 4 Jan 2013 15:37:17 -0800
Subject: [PATCH] md5: avoid erroneous construct
* lib/md5.c (md5_process_bytes): un-nest a function call to avoid
a ``invalid use of void expression'' error.
---
ChangeLog |5 +
lib/md5.c |3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index f036ac1..9144aac 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2013-01-04 Bruce Korb bk...@gnu.org
+
+ * lib/md5.c (md5_process_bytes): un-nest a function call to avoid
+ a ``invalid use of void expression'' error.
+
2013-01-04 Paul Eggert egg...@cs.ucla.edu
fprintftime: bring back and reword fwrite comment
diff --git a/lib/md5.c b/lib/md5.c
index c41538c..d90783b 100644
--- a/lib/md5.c
+++ b/lib/md5.c
@@ -258,7 +258,8 @@ md5_process_bytes (const void *buffer, size_t len, struct md5_ctx *ctx)
if (UNALIGNED_P (buffer))
while (len 64)
{
-md5_process_block (memcpy (ctx-buffer, buffer, 64), 64, ctx);
+memcpy (ctx-buffer, buffer, 64);
+md5_process_block (ctx-buffer, 64, ctx);
buffer = (const char *) buffer + 64;
len -= 64;
}
--
1.7.10.4
Re: error: md5.c invalid use of void expression
On 01/04/13 15:21, Bruce Korb wrote:
On 01/04/13 12:47, Paul Eggert wrote:
On 01/03/2013 08:30 AM, Petr Písař wrote:
4.13.1 release replaced SWAP() macro with function.
The 4.13.1 release shipped with an obsolete version of md5.c and md5.h,
which (as you saw) has some problems. I suggest upgrading to
the latest versions of these two files, which you can get here:
http://git.savannah.gnu.org/cgit/gnulib.git/plain/lib/md5.c
http://git.savannah.gnu.org/cgit/gnulib.git/plain/lib/md5.h
As given to me, sharutils included the md5 source.
Since I've gnulib-ified the thing, I'm adding crypto/md5 to the
list of modules I pull. That ought to take care of it... :) Thanks.
In file included from shar.c:55:0:
../lib/md5.c: In function 'md5_process_bytes':
../lib/md5.c:261:13: error: invalid use of void expression
256 #if !_STRING_ARCH_unaligned
257 # define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (uint32_t) != 0)
258 if (UNALIGNED_P (buffer))
259 while (len 64)
260 {
261 md5_process_block (memcpy (ctx-buffer, buffer, 64), 64,
ctx);
262 buffer = (const char *) buffer + 64;
263 len -= 64;
264 }
265 else
266 #endif
This fixes it:
261 memcpy (ctx-buffer, buffer, 64);
262 md5_process_block (ctx-buffer, 64, ctx);
There's no particular reason for having a nested call there anyway.
PATCH: md5.c invalid use of void expression
On 01/04/13 15:38, Bruce Korb wrote:
On 01/04/13 15:27, Bruce Korb wrote:
This fixes it:
261 memcpy (ctx-buffer, buffer, 64);
262 md5_process_block (ctx-buffer, 64, ctx);
There's no particular reason for having a nested call there anyway.
From 200eb0ed19376b71f4ca8706c1db83be21a59372 Mon Sep 17 00:00:00 2001
From: Bruce Korb bk...@gnu.org
Date: Fri, 4 Jan 2013 15:37:17 -0800
Subject: [PATCH] md5: avoid erroneous construct
* lib/md5.c (md5_process_bytes): un-nest a function call to avoid
a ``invalid use of void expression'' error.
---
ChangeLog |5 +
lib/md5.c |3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index f036ac1..9144aac 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2013-01-04 Bruce Korb bk...@gnu.org
+
+ * lib/md5.c (md5_process_bytes): un-nest a function call to avoid
+ a ``invalid use of void expression'' error.
+
2013-01-04 Paul Eggert egg...@cs.ucla.edu
fprintftime: bring back and reword fwrite comment
diff --git a/lib/md5.c b/lib/md5.c
index c41538c..d90783b 100644
--- a/lib/md5.c
+++ b/lib/md5.c
@@ -258,7 +258,8 @@ md5_process_bytes (const void *buffer, size_t len, struct md5_ctx *ctx)
if (UNALIGNED_P (buffer))
while (len 64)
{
-md5_process_block (memcpy (ctx-buffer, buffer, 64), 64, ctx);
+memcpy (ctx-buffer, buffer, 64);
+md5_process_block (ctx-buffer, 64, ctx);
buffer = (const char *) buffer + 64;
len -= 64;
}
--
1.7.10.4
Re: PATCH: md5.c invalid use of void expression
On 01/04/13 16:17, Bruce Korb wrote: This fixes it: 261 memcpy (ctx-buffer, buffer, 64); 262 md5_process_block (ctx-buffer, 64, ctx); There's no particular reason for having a nested call there anyway. $ gcc --version ; uname -a ; /lib/glibc.so.6 gcc (SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189773] Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Linux beethoven 3.4.11-2.16-desktop #1 SMP PREEMPT Wed Sep 26 17:05:00 UTC 2012 (259fc87) x86_64 x86_64 x86_64 GNU/Linux GNU C Library stable release version 2.15 (20120628), by Roland McGrath et al. Copyright (C) 2012 Free Software Foundation, Inc.
Re: PATCH: md5.c invalid use of void expression
There's no particular reason for having a nested call there anyway. But there's also no particular reason why we should avoid it, unless we know more about which environment is broken if we don't avoid it, since as written, it is standards-compliant code. P.S. Just because code is standards compliant doesn't make it easy to follow. Disentangling function calls makes code easier to follow. The only place where I'd put a function call in an argument list is where you are using an accessor function. memcpy is not doing that. Instead, it is returning its first argument as a convenience. That has two consequences: 1) the code is somewhat more cluttered, and 2) GCC complains. Rather forcefully. Hence, the patch.
error: invalid use of void expression
You may have been thinking you were using memcpy, but you were
using bcopy instead. Please apply the patch to md5.c. Thanks!
$ gcc -c shar-i.c
shar-i.c: In function 'md5_process_bytes':
shar-i.c:3087:13: error: invalid use of void expression
1034 extern void bcopy (__const void *__src, void *__dest, size_t __n)
1035 __attribute__ ((__nothrow__ , __leaf__)) __attribute__
((__nonnull__ (1, 2)));
3082 if (len = 64)
3083 {
3084 if (((uintptr_t) (buffer) % _Alignof (uint32_t) != 0))
3085 while (len 64)
3086 {
3087 md5_process_block (bcopy (buffer, ctx-buffer, 64), 64,
ctx);
3088 buffer = (const char *) buffer + 64;
3089 len -= 64;
3090 }
In file included from shar.c:55:0:
../lib/md5.c: In function 'md5_process_bytes':
../lib/md5.c:261:13: error: invalid use of void expression
254 if (len = 64)
255 {
256 #if !_STRING_ARCH_unaligned
257 # define UNALIGNED_P(p) ((uintptr_t) (p) % alignof (uint32_t) != 0)
258 if (UNALIGNED_P (buffer))
259 while (len 64)
260 {
261 md5_process_block (memcpy (ctx-buffer, buffer, 64), 64,
ctx);
262 buffer = (const char *) buffer + 64;
263 len -= 64;
264 }
265 else
Re: error: invalid use of void expression
On 01/04/13 18:25, Eric Blake wrote: On 01/04/2013 05:47 PM, Bruce Korb wrote: You may have been thinking you were using memcpy, but you were using bcopy instead. Please apply the patch to md5.c. Thanks! Rather than fixing the call site of memcpy, we should instead fix the real bug, the fact that you are even doing *ifndef HAVE_MEMCPY and defining memcpy to bcopy() in the first place. I am removing (have removed) md5.[ch] from the sharutils repo. But I have a theory now: Long ago and far away, there used to be a test for memcpy. Somewhere along the line, HAVE_MEMCPY disappeared and sharutils kept working because bcopy works just fine. Then I upgraded to gnulib's md5 and I hit a booby trap and my $'^[ \t]*#[ \t]*define[ \t]+memcpy\' re didn't find the define. It is still ugly to nest functional functions into a single line of code. But I don't care any more. The booby trap lived in sharutils/lib/system.h along side a *LOT* of ancient cruft.
Re: [sharutils-4.11.1] Compilation warnings
On 12/06/12 16:01, Paul Eggert wrote:
You're not the only one. This problem is common enough
that we have a gnulib module that solves it. With
gnulib you can use the ignore-value module and write this:
#include ignore-value.h
...
ignore_value (system (fil_name));
# define ignore_value(x) (({ __typeof__ (x) __x = (x); (void) __x; }))
Years ago, I heard about a compiler optimization test wherein a sample
program could be shown to not have any outputs. The compiler eliminated
everything and the program exited immediately. In a similar vein, can
GCC decide that the result of (x) is not really used and still complain?
Also, as it turns out, this usage is actually injected into code that
gets used by client programs. Consequently, I added the
# if __GNUC__ 3 || (__GNUC__ == 3 __GNUC_MINOR__ 4)
construct into the injected code. Yummy.
Thank you! Regards, Bruce
Re: error: required file 'config.h.in' not found
On Sat, Nov 24, 2012 at 11:57 AM, Paul Eggert egg...@cs.ucla.edu wrote: This often means that you haven't run autoheader, so you might try running that, or running autoreconf (which runs autoheader). Or is supposed to? Below is an xtrace of Gary's bootstrap script that ultimately arrives at: /usr/bin/autoreconf --install but that invocation chokes. I'll see what I can do to get autoreconf to run autoheader. BS-func_autoreconf func_show_eval '/usr/bin/autoreconf --install' 'exit $?' [...] BS-func_show_eval eval '/usr/bin/autoreconf --install' BS-func_show_eval /usr/bin/autoreconf --install configure.ac:32: installing 'build-aux/compile' configure.ac:11: installing 'build-aux/config.guess' configure.ac:11: installing 'build-aux/config.sub' configure.ac:15: installing 'build-aux/install-sh' configure.ac:15: installing 'build-aux/missing' Makefile.am: installing './INSTALL' Makefile.am: installing './COPYING' using GNU General Public License v3 file Makefile.am: Consider adding the COPYING file to the version control system Makefile.am: for your code, to avoid questions about which license your project uses configure.ac:20: error: required file 'config.h.in' not found doc/Makefile.am:42: installing 'build-aux/texinfo.tex' lib/Makefile.am: installing 'build-aux/depcomp' autoreconf: automake failed with exit status: 1
Re: error: required file 'config.h.in' not found
Hi Gary!
On 11/25/12 09:36, Gary V. Vaughan wrote:
You can always get a function call trace from any of my (recent) shell
scripts like this:
debug_cmd='eval echo ${FUNCNAME[0]} $* 2' bash bootstrap
I tend to use debug_cmd=PS4='BS-\$FUNCNAME ' ; set -x bash bootstrap
On error exit, you can also now write backtrace functions in bash.
See the lbuild script in the lustre file system for an example. :)
I'm going to pilfer that and make it more generally useful.
Autoreconf doesn't always run libtoolize (among others) at the correct time,
so the bootstrap invocation of autoreconf is a little tricky... You also
need to be careful AUTOHEADER is not set in the environment (in the calling
shell or your bootstrap.conf, for example).
What revision of bootstrap are you running?
The one from the libposix stuff we did a little while ago...
Do you have a repo or tarball of your source package I can look at to try and
reproduce?
[remote origin]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ssh://git.sv.gnu.org/srv/git/complexity.git
With the new bootstrap, I have new results.
(The new bootstrap has not been pushed.)
BS-func_show_eval eval '/usr/bin/autoreconf --install'
BS-func_show_eval /usr/bin/autoreconf --install
configure.ac:37: installing './compile'
configure.ac:11: installing './config.guess'
configure.ac:11: installing './config.sub'
configure.ac:23: installing './install-sh'
configure.ac:23: installing './missing'
Makefile.am: installing './COPYING' using GNU General Public License v3 file
Makefile.am: Consider adding the COPYING file to the version control system
Makefile.am: for your code, to avoid questions about which license your
project uses
doc/Makefile.am:42: installing 'doc/texinfo.tex'
lib/Makefile.am:59: error: GL_GENERATE_ALLOCA_H does not appear in
AM_CONDITIONAL
lib/Makefile.am:91: error: GL_GENERATE_ERRNO_H does not appear in AM_CONDITIONAL
lib/Makefile.am:133: error: GL_GENERATE_FLOAT_H does not appear in
AM_CONDITIONAL
lib/Makefile.am:301: error: GL_GENERATE_STDBOOL_H does not appear in
AM_CONDITIONAL
lib/Makefile.am:324: error: GL_GENERATE_STDDEF_H does not appear in
AM_CONDITIONAL
lib/Makefile.am:354: error: GL_GENERATE_STDINT_H does not appear in
AM_CONDITIONAL
lib/Makefile.am: installing './depcomp'
autoreconf: automake failed with exit status: 1
Re: error: required file 'config.h.in' not found
Hi Paul, On Sat, Nov 24, 2012 at 11:57 AM, Paul Eggert egg...@cs.ucla.edu wrote: This often means that you haven't run autoheader, so you might try running that, or running autoreconf (which runs autoheader). In my case, it was a compound problem with three factors: 1. I was using a bootstrap script with a bug 2. I was using some obsoleted code in configure.ac (CX_INIT/CX_EARLY) 3. The error message was not pointing me to something I could use for guidance (an automake problem) I brought the issue here because I was trying to use gnulib-tool to set everything up. Thank you! Regards, Bruce
error: required file 'config.h.in' not found
Hi, I cannot seem to find the solution. I'm not the only one: http://osdir.com/ml/freebsd-ports/2012-10/msg00065.html though some hits seem to mention: AUTOMAKE_ARGS = --add-missing in the Makefile.am. Unfortunately, I already had that in my Makefile.am. No joy. Does someone know the magic? Thank you! Regards, Bruce configure.ac:20: error: required file 'config.h.in' not found doc/Makefile.am:42: installing 'build-aux/texinfo.tex' lib/Makefile.am: installing 'build-aux/depcomp' autoreconf: automake failed with exit status: 1
Libtool library used but 'LIBTOOL' is undefined
automake is trying to tell me something, but I cannot make out exactly what. The literal meaning of the messages is pretty clear, but what they caution about are things that appear to me to be correct. autoreconf --force --install --verbose --symlink autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf --force autoreconf: running: /usr/bin/autoheader --force autoreconf: running: automake --add-missing --force-missing configure.ac:30: installing './compile' configure.ac:11: installing './config.guess' configure.ac:11: installing './config.sub' configure.ac:23: installing './install-sh' configure.ac:23: installing './missing' doc/Makefile.am:42: installing 'doc/texinfo.tex' lib/Makefile.am:31: error: Libtool library used but 'LIBTOOL' is undefined lib/Makefile.am:31: The usual way to define 'LIBTOOL' is to add 'LT_INIT' lib/Makefile.am:31: to 'configure.ac' and run 'aclocal' and 'autoconf' again. lib/Makefile.am:31: If 'LT_INIT' is in 'configure.ac', make sure lib/Makefile.am:31: its definition is in aclocal's search path. lib/Makefile.am: installing './depcomp' autoreconf: automake failed with exit status: 1 Yes, I see the ``If 'LT_INIT' is in 'configure.ac', make sure its definition is in aclocal's search path.'' stuff, but if I google the string, I just get advice to add LT_INIT to my configure.ac file. Pretty useless. If someone would just be kind enough to adjust the message so I can determine how to put the thing into the aclocal search path, I would be really happy. Thank you! Regards, Bruce P.S. it is *not* defined in the m4 subdirectory, which is created by the gnulib-tool script.
Re: [PATCH] printf: remove stupid restriction on %n
On 09/09/12 18:28, Paul Eggert wrote: Another option is (c) the ability to use %n in read-only format strings only ... but we wouldn't need to do step 3 (reject uses of %n in writable memory), which would be less work. You'd need to field issues about strange behavior that folks don't understand. Read the C11 spec doesn't seem to me to be a good answer. Error messages explaining where you've gone astray seem like they are worth the small amount of extra work.
Re: [PATCH] bootstrap: use a more consistent error reporting scheme.
On 07/06/12 06:11, Akim Demaille wrote:
One other tiny nit that is helpful in a die() function:
It isn't necessarily true that die always gets invoked
from the main process. If it gets invoked from a subprocess
for any of a variety of reasons, this:
+die() { warn_ $@; exit 1; }
won't work. I use this (more or less) as a standard template:
readonly progpid=$$
die() {
warn_ $@
kill -9 $progpid
exit 1
} 12
Re: parse-duration-tests: make it build
What happened to my GIT access?
$ git push
fatal: The remote end hung up unexpectedly
This should be obvious.
From 054ba400bcc664216ba988eb979f868665a5f98b Mon Sep 17 00:00:00 2001
From: Bruce Korb bk...@gnu.org
Date: Thu, 21 Jun 2012 07:49:16 -0700
Subject: [PATCH] testing: fix typo in here doc
* tests/test-parse-duration.sh: fix mal-formed here doc.
---
tests/test-parse-duration.sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/test-parse-duration.sh b/tests/test-parse-duration.sh
index 5398c3b..40a3101 100755
--- a/tests/test-parse-duration.sh
+++ b/tests/test-parse-duration.sh
@@ -57,7 +57,7 @@ cat ${tmpf} - _EOF_
1 Y 2 M 25 d 5h 6:7
1 Y 2 M 25 d 5h 6m 7
P 1-2-25 T 5:6:7
- _EOF_
+_EOF_
exec 3 ${tmpf}
while read line 3
--
1.7.7
Re: parse-duration-tests: make it build
On 06/21/12 08:16, Jim Meyering wrote:
Maybe just try again?
My push-ability is still disabled. Can this be fixed, please?
From d8ef24cb52c23fb136d52325e36af70dead06ebb Mon Sep 17 00:00:00 2001
From: Bruce Korb bk...@gnu.org
Date: Thu, 21 Jun 2012 09:20:27 -0700
Subject: [PATCH] testing: fix typo in here doc
* tests/test-parse-duration.sh: fix mal-formed here doc.
---
tests/test-parse-duration.sh | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/tests/test-parse-duration.sh b/tests/test-parse-duration.sh
index 5398c3b..6aeb225 100755
--- a/tests/test-parse-duration.sh
+++ b/tests/test-parse-duration.sh
@@ -50,14 +50,14 @@ trap 'rm -rf ${tmp}' EXIT
tmpf=${tmp}/tests.txt
cat ${tmpf} - _EOF_
- 1 Y 2 M 3 W 4 d 5 h 6 m 7 s
- P 00010225 T 05:06:07
- P 1Y2M3W4D T 5H6M7S
- 1 Y 2 M 25 D 5:6:7
- 1 Y 2 M 25 d 5h 6:7
- 1 Y 2 M 25 d 5h 6m 7
- P 1-2-25 T 5:6:7
- _EOF_
+ 1 Y 2 M 3 W 4 d 5 h 6 m 7 s
+ P 00010225 T 05:06:07
+ P 1Y2M3W4D T 5H6M7S
+ 1 Y 2 M 25 D 5:6:7
+ 1 Y 2 M 25 d 5h 6:7
+ 1 Y 2 M 25 d 5h 6m 7
+ P 1-2-25 T 5:6:7
+ _EOF_
exec 3 ${tmpf}
while read line 3
--
1.7.7
Re: parse-duration-tests: make it build
On 06/21/12 09:33, Jim Meyering wrote: Bruce Korb wrote: On 06/21/12 08:16, Jim Meyering wrote: Maybe just try again? My push-ability is still disabled. Can this be fixed, please? AFAICT, it's not disabled: https://savannah.gnu.org/project/memberlist.php?group=gnulib Ah. Somehow the source wound up being via the git:// protocol instead of ssh://. Oops. Thank you. Maybe you're having some sort of local network difficulty? If it's a problem with savannah, it's intermittent, since Paul just pushed a commit, and so have I. Re the change below, either remove the leading TABs (my preference) and s/-// or else you'll have to arrange not to trigger the leading-TAB-prohibiting syntax check rule. Shouldn't it be grandfathered? I very, _very_ strongly prefer the tab-indented here docs. It makes the scope of the command *much* clearer.
Re: parse-duration-tests: make it build
On 06/21/12 09:22, Bruce Korb wrote: On 06/21/12 08:16, Jim Meyering wrote: Maybe just try again? make[1]: Leaving directory `/old-home/gnu/proj/gnulib/t' make: *** No rule to make target `sc_maint'. Stop. Also, the way to bypass the test is fairly indecipherable from just looking at cfg.mk. Perhaps it would be best to ignore leading tabs in shell scripts the way they are ignored in make file fragments.
Re: parse-duration-tests: make it build
On 06/21/12 12:41, Bruno Haible wrote:
Your commit came without a ChangeLog entry. I added one for you:
Woops. Thanks you so much!
On 06/21/12 12:41, Bruno Haible wrote:
Or, even better in my opinion: All the trouble has been caused my the
desire to keep a shell script and a data table in the same file. Separate
them. Move the test data into a file of its own, say
tests/test-parse-duration-data.txt. Then you don't need a temporary dir,
you don't need a 'trap' command, just a
while read line ${srcdir}/test-parse-duration-data.txt
Except for the file being re-opened on each iteration,
that is a good idea. In general, though, when I use a here doc,
I use the strip-the-tabs form because it looks _much_ cleaner.
In this case, this:
while read line ; do
...
done ${srcdir}/test-parse-duration-data.txt
combined with the trap handling removal is a lot better.
Re: parse-duration test output
Sure. Thank you. I am away from where I can play with the stuff for a couple of days, so likely this weekend On Wed, Jun 20, 2012 at 2:22 PM, Bruno Haible br...@clisp.org wrote: Hi Bruce, $ ./gnulib-tool --test --with-tests parse-duration produces as part of the unit test output (on glibc/Linux with bash 4.2 and other platforms): ../../gltests/test-parse-duration.sh: line 68: warning: here-document at line 52 delimited by end-of-file (wanted `_EOF_') could not parse time: err 22 - Invalid argument PASS: test-parse-duration.sh Can you please fix this? Gnulib unit tests should normally not produce output when they pass. Bruno
LGPL-ing gnulib - was: new module: relpath
On 06/18/12 05:52, Eric Blake wrote: + realtarget = canonicalize_filename_mode (target, CAN_MISSING); Indeed, for this to be LGPL, we would have to change canonicalize_filename_mode() to have a looser license, and I'm not sure it is a wise idea to attempt that. Indeed, perhaps just blanket license gnulib as LGPL? It does seem like this several-times-a-year exercise of Oh, wait, we need this one LGPL-ed, too is getting a tad old. Maybe just me, but it seems like less bother to just get it over with
Re: [PATCH] parse-duration: Lessen the GPL
On 06/10/12 16:19, Bruno Haible wrote: Hi Bruce, Paul, Jim, Bruno, and Ralf as the set of all contributors besides yourself (although some of those contributions were trivial) before making this change. They were all trivial, actually. Well, I think 3-line comments as in the 2008-12-17 change [1] are copyrightable, because there are many different ways to formulate such a comment. copyrightable != trivial The work required to understand how to comment wasn't trivial. Anyway, trivial difference in semantics: But I agree to the proposed change to LGPL as well. This should be LGPLv2+, as it allows a painless license upgrade when the FSF releases a new version of the license. I've pushed this in your name: Thank you.
[PATCH] parse-duration: Lessen the GPL
This gets included by NTP and they need a more liberal license:
From d9adda99d471074850b3563fad18fd1837397ca8 Mon Sep 17 00:00:00 2001
From: Bruce Korb bk...@gnu.org
Date: Fri, 8 Jun 2012 13:17:05 -0700
Subject: [PATCH] parse-duration: Lessen the GPL
* lib/parse-duration.c: mark the license as Lesser
* lib/parse-duration.h: likewise
* modules/parse-duration: likewise
---
lib/parse-duration.c | 14 +++---
lib/parse-duration.h |8
modules/parse-duration |2 +-
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/lib/parse-duration.c b/lib/parse-duration.c
index e49060a..5d9e9e6 100644
--- a/lib/parse-duration.c
+++ b/lib/parse-duration.c
@@ -3,16 +3,16 @@
Written by Bruce Korb bk...@gnu.org, 2008.
This program is free software: you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 3 of the License, or
+ it under the terms of the GNU Lesser General Public License as published
+ by the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
+ GNU Lesser General Public License for more details.
- You should have received a copy of the GNU General Public License
+ You should have received a copy of the GNU Lesser General Public License
along with this program. If not, see http://www.gnu.org/licenses/. */
#include config.h
@@ -54,14 +54,14 @@ typedef enum {
#define TIME_MAX0x7FFF
/* Wrapper around strtoul that does not require a cast. */
-static unsigned long inline
+inline static unsigned long
str_const_to_ul (cch_t * str, cch_t ** ppz, int base)
{
return strtoul (str, (char **)ppz, base);
}
/* Wrapper around strtol that does not require a cast. */
-static long inline
+inline static long
str_const_to_l (cch_t * str, cch_t ** ppz, int base)
{
return strtol (str, (char **)ppz, base);
@@ -70,7 +70,7 @@ str_const_to_l (cch_t * str, cch_t ** ppz, int base)
/* Returns BASE + VAL * SCALE, interpreting BASE = BAD_TIME
with errno set as an error situation, and returning BAD_TIME
with errno set in an error situation. */
-static time_t inline
+inline static time_t
scale_n_add (time_t base, time_t val, int scale)
{
if (base == BAD_TIME)
diff --git a/lib/parse-duration.h b/lib/parse-duration.h
index caefb75..5961bc9 100644
--- a/lib/parse-duration.h
+++ b/lib/parse-duration.h
@@ -3,16 +3,16 @@
Written by Bruce Korb bk...@gnu.org, 2008.
This program is free software: you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 3 of the License, or
+ it under the terms of the GNU Lesser General Public License as published
+ by the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
+ GNU Lesser General Public License for more details.
- You should have received a copy of the GNU General Public License
+ You should have received a copy of the GNU Lesser General Public License
along with this program. If not, see http://www.gnu.org/licenses/. */
/*
diff --git a/modules/parse-duration b/modules/parse-duration
index e36c917..a0da1b3 100644
--- a/modules/parse-duration
+++ b/modules/parse-duration
@@ -17,7 +17,7 @@ Include:
parse-duration.h
License:
-GPL
+LGPLv2+
Maintainer:
Bruce Korb
--
1.7.7
Re: [PATCH] parse-duration: Lessen the GPL
On 06/08/12 13:38, Eric Blake wrote: modules/parse-duration |2 +- This hunk is sufficient, but only if we either have agreement from all non-trivial contributors on making the change to the license, or permission from the FSF. Based on 'git log', it looks like you need consent from Paul, Jim, Bruno, and Ralf as the set of all contributors besides yourself (although some of those contributions were trivial) before making this change. They were all trivial, actually. Essentially a few comment tweaks and copyright year twiddling. From 1328915340022b87babdf3b80736b05adbdcfa90 Mon Sep 17 00:00:00 2001 From: Bruce Korb bk...@gnu.org Date: Fri, 8 Jun 2012 14:10:35 -0700 Subject: [PATCH] parse-duration: Lessen the GPL * modules/parse-duration: mark the license as Lesser --- modules/parse-duration |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules/parse-duration b/modules/parse-duration index e36c917..e14f485 100644 --- a/modules/parse-duration +++ b/modules/parse-duration @@ -17,7 +17,7 @@ Include: parse-duration.h License: -GPL +LGPLv2 Maintainer: Bruce Korb -- 1.7.7
Re: restrictive umask vs gnupload
On 12/06/11 12:37, Jim Meyering wrote: I use a umask of 077. That is rather irregular Opinions, preferences, get over it! ;-) gnupload is responsible for delivering the files to GNU in a workable fashion regardless of your personal preferences. What it ought to really do is check for go+r on the files it is about to transmit. If not set, the bits should be set before transmission and reset afterward. That would be the excruciatingly correct way to do it. :)
Re: mktemp: not found
On 12/04/11 11:57, Jim Meyering wrote:
d=`unset TMPDIR; { mktemp -d -t -p $destdir_ $template_; } 2/dev/null` \
That should do the same without the cost of a sub-shell.
Or:
d=`
exec 2/dev/null
unset TMPDIR
mktemp -d -t -p $destdir_ $template_
`
as we discovered recently, there are some commands (builtin's, okay)
where the output goes to stderr before it gets redirected.
So get your fingers in the habit of not using overly long lines
and redirecting junk before the command in question. :)
Re: gengetopt, anyone?
On 10/01/11 16:16, Reuben Thomas wrote: I notice no-one mentioned argp. (I also notice one of autoopts's testimonials says that it (autoopts) is simpler than argp!). But from a quick look argp seems rather neat; it doesn't need a separate parser and code generator, and it's available in gnulib. Why aren't I using it? Because there are too many things it doesn't deal with? http://www.gnu.org/software/autogen/compare.html http://www.gnu.org/software/autogen/autoopts.html There are really two parts to option processing: 1. computing option state, derived from configuration files, environment variables and the command line options themselves, but also: 2. documenting them and ensuring consistency between all the various documents and what the code actually does. (You may not like man pages, but they are the standard way of conveying program usage) Only two do both.
Re: gengetopt, anyone?
On 09/27/11 06:49, Simon Josefsson wrote: Reuben Thomasr...@sc3d.org writes: Has anyone else any experience with it? I have used it in libidn, gsasl and a few other projects since well over 5 years. I have been quite happy with it. The biggest concern I have had is that the auto-generated --help screen is impossible to fine-tune and it doesn't look as good as I want it to. For Libidn, I have given up on using the auto-generated --help output and instead wrote a custom function for displaying it. For gsasl I still use the auto-generated screen, mostly due to the much larger amount of parameters. One of the things I want to go away is that it prints the project name and version as the first line of --help, I think there is no point in having that there (there is --version after all) and I would prefer a terse Usage:-line instead. I have also played with it, and tried to combine my autoopts strengths with Lorenzo, but he seemed pointedly uninterested. In the end, there is little gengetopt does that is not well covered by autoopts: http://www.gnu.org/software/autogen/compare.html and it is more easily covered in autoopts. WRT fair amount of work, I'd have to agree with Jim. It is an understatement. The problem being that since each program basically parses its own options (getopt() and getopt_long() being only very minor assists), and has non-standard-isms in the way they are handled. You'd have to go back to the generator engine and add a lot of exceptional handling code. Not worth it. BTW, current NTP code uses autoopts for handling its options and configuration files and multi-flavored man pages. Cheers - Bruce
