[CVS 2006-01-06]
The file localcharset.c asks for the preprocessor symbol
HAVE_DECL_GETC_UNLOCKED which doesn't get defined in the m4 files
listed in modules/localcharset.
Werner
___
bug-gnulib mailing list
bug-gnulib@gnu.org
Bruno Haible replied on 2006-01-09:
Paul Knowles wrote on 2005-12-15:
*** Problem #1
struct argp{
...
/* A vector of argp_children structures, terminated by a member with a 0
argp field, pointing to child argps should be parsed with this one. Any
conflicts are resolved in
Paul Eggert wrote:
Peter O'Gorman [EMAIL PROTECTED] writes:
getprogname(3), if it exists, can be used as well as other
alternatives (e.g. argv[0]).
Thanks, I wasn't aware of the BSD getprogname until now.
Me too.
How about this proposal?
* Change the progname module to use the BSD
Hi,
The use of autoreconf, introduced on 2004-09-18, causes
./gnulib-tool --create-testdir --dir=/dev/shm/testdir gettext
to fail:
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION
I'm committing this fix.
2006-01-07 Bruno Haible [EMAIL PROTECTED]
Hi,
I think it's time to get rid of __const. gnulib assumes an ANSI C compiler,
glibc does as well. The following glibc public header files already assume
an ANSI C compiler that groks 'const':
/usr/include/argp.h
/usr/include/assert.h
/usr/include/error.h
/usr/include/fstab.h
/usr/include/fts.h
Bruno Haible [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
How would build-aux/ be substituted into $auxdir? Should gnulib-tool
substitute 'build-aux/' in configure.ac:-statements to $auxdir?
Yes, it should. I'll prepare a patch for doing this.
That would solve this problem. I hope the
$ ./gnulib-tool --create-testdir --dir=testdir strtok_r
...
configure.ac:14: warning: gl_C_RESTRICT is m4_require'd but is not m4_defun'd
configure.ac:14: gl_C_RESTRICT is required by...
m4/strtok_r.m4:17: gl_PREREQ_STRTOK_R is expanded from...
m4/strtok_r.m4:12: gl_FUNC_STRTOK_R is expanded
Jim,
gnulib-tool --create-megatestdir --dir=/dev/shm/testdir --with-tests
shows this:
configure.ac:20: warning: gl_FUNC_FREE is m4_require'd but is not m4_defun'd
configure.ac:20: gl_FUNC_FREE is required by...
m4/readutmp.m4:55: gl_READUTMP is expanded from...
The reason is that m4/readutmp.m4
Bruno Haible [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
+ rmdir sys
Remove the directory only when it exists and is empty. (Some systems
create files in your directories without being asked for, e.g. .DS_Store
on MacOS X.)
How do I test for that in a portable way?
Let rmdir
Peter O'Gorman wrote:
Solaris seems to have a getexecname
Interesting. So this provides a fallback, like on glibc systems, for the
case when setprogname(argv[0]) has not been called.
I'd suggest the following instead of Paul's proposal, as it allows
the programmer to override the program
Jim Meyering wrote:
However, I'm reluctant to remove the AC_REQUIRE, since
that would make the code+.m4 combination depend silently on
having a particular implementation of free.
Yes, I understand. By looking at the source code, it's not immediately
clear which free() variant is meant.
Bruno Haible [EMAIL PROTECTED] wrote:
The reason is that m4/readutmp.m4 invokes gl_FUNC_FREE, but m4/free.m4 is not
part of this module or its dependencies.
Here is a fix. OK to commit?
Hi Bruno!
Thanks for working on this.
Adding the module dependency is fine.
However, I'm reluctant to
Ralf Wildenhues [EMAIL PROTECTED] writes:
Thanks for checking that. Can you please run the following
program on that platform and send us the output? If it outputs
preprocessor thinks BITSET_WORD_BITS = 64, then we have an
obvious fix to regex_internal.h. Thanks.
Yes
OK, thanks, I
Paul Eggert wrote:
This isn't as compatible as possible with BSD, as BSD setprogname
ignores its argument when the true program name is available from
the operating system.
Huh? My reading of the sources of FreeBSD
Werner LEMBERG wrote:
There isn't a file `modules/progreloc' which looks like a bug to me
since it depends on progname.
Yes, the relocatable stuff does not yet fit into a gnulib module.
The installation instructions ([1]) require some modification to
every Makefile.am and to every installable
There isn't a file `modules/progreloc' which looks like a bug to me
since it depends on progname.
Werner
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
On Tue, Jan 10, 2006 at 11:07:20PM +0900, Peter O'Gorman wrote:
char *
get_prog_name(void)
{
char * name;
if (prog_name)
name = prog_name;
else
{
#if defined(HAVE_GETPROGNAME)
#include stdlib.h
name = getprogname();
#elif
Bruno Haible [EMAIL PROTECTED] writes:
2006-01-08 Bruno Haible [EMAIL PROTECTED]
* modules/strtok_r: Depend on module restrict.
2006-01-08 Bruno Haible [EMAIL PROTECTED]
* m4/readutmp.m4 (gl_READUTMP): Don't require gl_FUNC_FREE. Use a
module dependency instead.
Bruno Haible [EMAIL PROTECTED] writes:
Paul Eggert wrote:
This isn't as compatible as possible with BSD, as BSD setprogname
ignores its argument when the true program name is available from
the operating system.
Huh? My reading of the sources of FreeBSD and NetBSD is just the
opposite:
Bruno Haible [EMAIL PROTECTED] writes:
Jim Meyering wrote:
How about if we leave the now-redundant
AC_REQUIRE in place for now?
Done. I committed only the other part.
Thanks. I mistakenly committed the whole change earlier, but undid
the mistake just now.
20 matches
Mail list logo