Eric Blake wrote:
> > Why not use this instead?
> >
> > #define c_isalpha(c) (((unsigned int) (c) | ('a' - 'A')) - 'a' <= 'z' -
> > 'a')
>
> This is a slick definition, but it is different than what c-ctype.h
> provided, and that definition was not guarded. Bruno, would you accept
> the following
- unlike the automake-provided build tools but exactly like
texinfo.tex - the tool is GPL but its use as build tool does not
infect your source with GPL.
2005-12-02 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_import): Accept GPLed build tool modules when
--lgpl i
Simon Josefsson wrote:
> > * modules/csharpcomp: Depend on it.
> > * modules/javacomp: Depend on it.
>
> These two patches were forgotten, apparently.
Oops, fixed. Sorry, I'm constantly in a hurry these days.
> I'm now using csharpcomp to build the Libidn C# port.
>
> How does javacomp re
Simon Josefsson wrote:
> Shouldn't csharpcomp-script and javacomp-script also invoke
> AC_CONFIG_FILES on the scripts? I need to do that manually now, and
> gnulib-tool didn't tell me about it.
>
> I can't come up with a simple patch -- the AC_CONFIG_FILES statement
> would have to include the dir
Simon Josefsson wrote:
> > - automake's support uses only gcj, ignoring the "javac" and "jikes"
> > commands.
>
> Right.
>
> > - It completely ignores CLASSPATH issues.
>
> Which, automake or javacomp?
I meant, automake.
> I'd like to support javac and jikes.
javacomp supports it.
> Does java
Stepan Kasal wrote on 2005-10-25:
> would the following patch be welcome?
>
> 2005-10-24 Stepan Kasal <[EMAIL PROTECTED]>
>
> * c-stack.c, copy-file.c, execute.c, fatal-signal.c, findprog.c,
> getlogin_r.c, getlogin_r.h, pagealign_alloc.c, pipe.c, pipe.h,
> progreloc.c
Peter Fales wrote on 2005-11-22:
> The error message occurs while building gnulib/lib (as part of
> findutils-4.2.26):
>
> $ make
> make all-am
> make[1]: Entering directory
> build/output/expmake/build/gnucoresrc/build/findutils/gnulib/lib'
> /opt/exp/gnu/bin/gcc -DHAVE_CONFIG_H -I. -I. -I../..
Paul Eggert wrote on 2005-11-18:
> I prefer putting type qualifiers like "const" after the types they
> modify, as that's more consistent. ...
>
> Not everyone agrees with this style, but I suspect this is often
> because they haven't thought through the consistency issues.
While I know that "cha
Georg Schwarz wrote:
> > findutils 4.2.27 does not compile on IRIX 5.3:
>
> [...]
>
> > cfe: Error: ./mbchar.h: 157: Cannot open file wchar.h for #include
>
> [...]
>
> > IRIX 5.3 does not have wchar.h.
That was a bug in gnulib before 2005-09-26. Now, I believe everything is
fine in gnulib: wchar.
Simon Josefsson wrote on 2005-10-25:
> I'm using gnulib-tool --lgpl in some projects. All of the *-tests
> modules that I wrote recently are GPL. There isn't really a need for
> these self tests to be available under LGPL, but gnulib-tool complain
> because I used --lgpl. I think it would be fin
Simon,
Yoann Vandoorselaere wrote on 2005-10-25:
> As you point out above, the untested netinet/in.h and sys/socket.h
> change might lead to compilation warnings/failure on some systems. It
> would be a good idea to check this specific change on OpenBSD 3.4 for
> example.
I now checked the curren
Mark D. Baushke wrote on 2005-12-30:
> For what it may be worth, the CVS project has a
> forked copy of the GNULIB bison.m4 which uses
> bison-missing until such time as automake-1.10 is
> released when it will no longer be an issue.
Which macro is used, depends on whether the generated .c file is
Albert Chin wrote on 2005-11-26:
> It's not necessarily safe to assume a system variable/function/header,
> if available to the C compiler, is available to the C++ compiler. This
> is even in the case the same vendor provides the C and C++ compiler.
> For example:
> 1. On Tru64 UNIX 5.1, is avai
Karl Berry wrote on 2006-01-05:
> Is it a problem in practice, ie, what are these non-Unix linkers?
MacOS X (a Unix!), Woe32, emx+gcc (a Unix as well). Maybe others.
> Are you thinking that set_program_name will set something other than
> program_name?
It already does. See progname.c.
Bruno
Dave Love wrote on 2006-01-04:
> Gnulib routines call `error', and on a non-glibc system that's likely
> to use an uninitialized `program_name' since the variable is
> initialized in progname.c, and that's not required. Users probably
> won't find out about it until `error' gets called at some sta
Simon Josefsson wrote on 2005-12-17:
> The sys_socket module below will create a sys/socket.h file, primarily
> for mingw32, but it could be extended for other systems or missing
> sys/socket.h features in the future.
>
> This would solve the problem of accessing sys/socket.h stuff in
> applicatio
Paul Eggert wrote on 2006-01-06:
> Perhaps we could change progname.h so that 'program_name' is a
> function that returns the program name, instead of being a global
> variable.
Ouch. When things go wrong, this leads to intriguing compiler errors like
"cannot call program_name as a function" or "a
t; Config-files:
> >> lib/csharpcomp.sh
> >
> > I don't think this is needed.
>
> Generating the AC_CONFIG_FILES statements like a good thing. How
> could that be achieved without a Config-files: statement?
A line in the 'configure.ac:' section is suf
quot; more consistent with "gnulib-tool --create-testdir".
Bruno
2006-01-07 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_import): Add an AC_PROG_RANLIB dependency to
gl_EARLY.
*** gnulib-tool.bak 2005-12-02 14:37:34.0 +0100
--
Dave Love wrote on 2006-01-05:
> why can't it be initialized to null in error.c?
There are other modules using program_name than error.c. For example,
argmatch, argp-help and xerror. Consequently,
- If you have an application that uses 'argp' but not 'error',
program_name would not be define
James Youngman wrote on 2006-01-05:
> My problem is that we have changed the interface without making it
> impossible for the user to use the new interface wrongly. I would
> prefer an arrangement which results in a compilation or link failure
> if the user (i.e. software maintainer) fails to init
Paul Eggert wrote on 2006-01-05:
> > (If the interface to it was just set_program_name, it could be private.)
>
> Yes, that would be a better convention. This will require revamping
> pretty much everybody that uses program_name, but I think it's worth
> the pain. What do others think?
GNU gett
Paul Eggert wrote on 2005-11-15:
> I'd like Bruno's opinion on all this before installing into gnulib.
>
> 2005-11-14 Paul Eggert <[EMAIL PROTECTED]>
>
> * lib/stdint_.h (intmax_t) [defined intmax_t]: Do not declare.
> (uintmax_t) [defined uintmax_t]: Do not declare.
> (SIZE_M
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 favor of this argp, or early ar
I committed this fix now.
> 2005-10-16 Bruno Haible <[EMAIL PROTECTED]>
>
> * m4/stdint.m4 (gl_STDINT_H): Also test for .
> * lib/stdint_.h: On Linux libc4 and libc5, include
> and don't define _STDI
Mark D. Baushke wrote on 2005-11-15:
> it would be more portable to use this:
>
> #ifndef SIZE_MAX
> # define SIZE_MAX ((size_t)-1)
> #endif
>
> because ((size_t)-1) will work even if size_t is narrower than int.
Yes. As explained on 2005-07-11, I prefer to write this as
((size_t)~
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 do the test, and ignore a poss
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.
Bruno
___
bug-gnulib mailing list
bu
Simon Josefsson wrote:
> > - sys/socket.h is currently included. It is not needed on OpenBSD 3.4.
> > But it is needed for 'socklen_t' to be defined portably, I think - look
> > at socklen.m4.
>
> Strictly, I don't believe it is needed -- arpa/inet.h must provide a
> prototype for inet_ntop and
The module 'strnlen' has a strnlen.h include file. But it is not mentioned
in the module description. I'm committing this fix.
2006-01-09 Bruno Haible <[EMAIL PROTECTED]>
* modules/strnlen (Include): Use strnlen.h.
*** modules/strnlen 11 Aug 2005 09
OK as 0 now. Sorry for the extremely long delay.
Bruno
2006-01-09 Bruno Haible <[EMAIL PROTECTED]>
* sysexit_.h (EX_OK): New macro.
Suggested by Martin Lambers <[EMAIL PROTECTED]>.
*** lib/sysexit_.h 14 May 2005 06:03:58 - 1.2
--- lib/sys
Mark D. Baushke wrote:
> I have no problems with either
> ((size_t)~(size_t)0) or ((size_t)-1) being used.
> However, the previous definition in stdint_.h of
> '#define SIZE_MAX (~(size_t)0)' seemed wrong to me.
Yes, it was wrong. Thank you for noticing the problem.
I changed it to ((size_t)~(size
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
Hi Paul,
This commit
2002-12-31 Paul Eggert <[EMAIL PROTECTED]>
* memcoll.m4 (gl_MEMCOLL): Require AC_FUNC_MEMCMP.
causes a gnulib-tool error:
$ ./gnulib-tool --create-testdir --dir=testdir memcoll
Module list with included dependencies:
memcoll
File list:
lib/memcoll.c
lib/mem
Simon,
On MacOS X with GNU libiconv module, the iconvme module exhibits a build
failure:
Making all in lib
make all-am
gcc -DHAVE_CONFIG_H -I. -I../../../megatestdir/iconvme/lib -I.. -g -O2 -c
../../../megatestdir/iconvme/lib/iconvme.c
../../../megatestdir/iconvme/lib/iconvme.c: In function
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 P
Werner LEMBERG wrote:
> 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.
I committed this fix:
2006-01-10 Bruno Haible <[EMAIL PROTECTED]>
* localcharset
Werner Lemberg wrote:
> During compilation with gcc 3.3.3 I get
>
> localcharset.c:110: warning: function declaration isn't a prototype
OK, should now be fixed in gnulib CVS:
2006-01-10 Bruno Haible <[EMAIL PROTECTED]>
* localcharset.c: Update from GNU gettext.
Hi,
./gnulib-tool --create-testdir --dir=/dev/shm/testdir --with-tests gettext
gives an error:
configure.ac: AM_GNU_GETTEXT used but SUBDIRS not defined
autoreconf: automake failed with exit status: 1
I'm committing this fix.
2006-01-07 Bruno Haible <[EMAIL PROTECTED]>
*
pose this patch.
2006-01-07 Bruno Haible <[EMAIL PROTECTED]>
* argp.h (__const): Remove macro. Use const instead.
* argp-fmtstream.h (__const): Likewise.
* glob_.h (__const): Remove macro.
* glob-libc.h: Use const instead of __const.
*** argp.h.bak 2005-07-
anded from...
The reason is that m4/strtok_r.m4 invokes gl_C_RESTRICT, but m4/restrict.m4 is
not part of this module or its dependencies.
Here is a fix. OK to commit?
2006-01-08 Bruno Haible <[EMAIL PROTECTED]>
* modules/strtok_r: Depend on module restrict.
*** modules/strtok_r
he 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?
2006-01-08 Bruno Haible <[EMAIL PROTECTED]>
* m4/readutmp.m4 (gl_READUTMP): Don't require gl_FUNC_FREE. Use a
module depend
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 na
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.
> Th
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
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/getprogname.c?rev=
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 installabl
This patch makes gnulib-tool generated packages work on MacOS X, even when
no object files is needed in the library. We already have a 'dummy' module
for this case. Now gnulib-tool makes use of it.
2006-01-08 Bruno Haible <[EMAIL PROTECTED]>
Avoid "ar: no arch
$ ./gnulib-tool --create-testdir --dir=testdir argp lock
...
configure.ac:36: warning: gl_ARGP was called before gl_LOCK
m4/lock.m4:224: gl_LOCK is expanded from...
I'm committing this fix.
2006-01-08 Bruno Haible <[EMAIL PROTECTED]>
Ensure automatic ordering between
The argp module has warnings on Linux/glibc:
gcc -DHAVE_CONFIG_H -I. -I/packages/megatestdir/argp/lib -I.. -g -O2 -c
/packages/megatestdir/argp/lib/argp-parse.c
/packages/megatestdir/argp/lib/argp-parse.c: In function `argp_default_parser':
/packages/megatestdir/argp/lib/argp-parse.c:112: war
The 'filenamecat' module has warnings on Linux/glibc:
gcc -DHAVE_CONFIG_H -I. -I/packages/megatestdir/filenamecat/lib -I.. -g -O2
-c /packages/megatestdir/filenamecat/lib/filenamecat.c
/packages/megatestdir/filenamecat/lib/filenamecat.c: In function
`file_name_concat':
/packages/megatestdir/
Simon Josefsson wrote:
> How would build-aux/ be substituted into $auxdir? Should gnulib-tool
> substitute 'build-aux/' in configure.ac:-statements to $auxdir?
I committed this patch.
2006-01-11 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_impor
s the effect of nearly doubling the executing time of
"gnulib-tool --create-megatestdir --dir=/dev/shm/testdir".
4 hours vs. ca. 7 or 8 hours of CPU time - it matters. I'm reverting to
simple autoconf and automake calls for the toplevel directory.
2006-01-08 Brun
DERS?
Well, noinst_HEADERS explains more precisely the purpose of the files. So
I'm changing gnulib-tool:
2006-01-08 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_emit_lib_Makefile_am, func_emit_tests_Makefile_am):
Initialize also noinst_HEADERS to empty.
*** gnulib
The des_setkey function still collides with the one on MacOS X:
gcc -DHAVE_CONFIG_H -I. -I../../../megatestdir/gc-des/lib -I.. -g -O2 -c
../../../megatestdir/gc-des/lib/gc-gnulib.c
In file included from ../../../megatestdir/gc-des/lib/gc-gnulib.c:65:
../../../megatestdir/gc-des/lib/des.h:62:
Paul Eggert wrote:
> I thought this module might be useful for people trying to build
> executables on systems like Solaris where the "-lrt" option causes the
> executable to dynamically link to rt, even if the executable does not
> need any of the rt routines.
The problem is brought in by the fac
The base64 module has a warning on Linux/glibc:
gcc -DHAVE_CONFIG_H -I. -I/packages/megatestdir/base64/lib -I.. -g -O2 -c
/packages/megatestdir/base64/lib/base64.c
/packages/megatestdir/base64/lib/base64.c: In function `isbase64':
/packages/megatestdir/base64/lib/base64.c:284: warning: compar
> > How about this proposal?
> >
> > * Change the progname module to use the BSD getprogname naming
> > convention. No sense reinventing the wheel. That way, programs can
> > simply use the system-defined functions on BSD.
> >
> > * Rewrite the other gnulib code to use the new convention.
> >
Ralf Wildenhues wrote:
> It would be nice if you could make the $AUTO* variables overridable on a
> case by case basis. Tools are named differently at places, e.g.,
> autoconf25.
Will this work for the situation that you have in mind?
Bruno
*** gnulib-tool.orig 11 Jan 2006 13:03:25 -
Simon Josefsson wrote:
> AC_CONFIG_FILES([csharpcomp.sh:build-aux/csharpcomp.sh.in])
>
> is the best default. It seem to cause csharpcomp.sh to end up in the
> top-level directory. I don't like this.
libtool does the same.
Bruno
___
bug-gnulib mai
Simon Josefsson wrote:
> bool
> isbase64 (char ch)
> {
> return to_uchar (ch) <= 255 && 0 <= b64[to_uchar (ch)];
> }
> ...
> Presumably the warning is because gcc believe an unsigned char cannot
> be larger than 255, but we didn't want to assume that since I don't
> think C89 guarantee it. Corre
Simon Josefsson wrote:
> Is it really safe to avoid to regenerate in sub-directories?
Yes, since they have been generated through func_create_testdir.
> I think this should be considered a autoreconf bug and reported
> though. ... If so, perhaps autoreconf should have a --no-recursion or
> simila
Paul Eggert wrote:
> If a package like that defines several programs,
> only some of which call clock_gettime, then the maintainer will have
> to do something like this (this is an extract from
> coreutils/src/Makefile.am):
>
> pr_LDADD = $(LDADD) $(LIB_CLOCK_GETTIME)
> shred_LDADD = $(LDADD) $(LIB
Hi,
gnulib is a portability library, and "ldd" is not portable. So I'm adding
the following module 'ldd'.
2006-01-12 Bruno Haible <[EMAIL PROTECTED]>
* modules/ldd: New file.
* m4/ldd.m4: New file.
* build-aux/ldd.sh.in: New file.
Paul Eggert wrote:
> + [for gl_ldd in \
> + ldd \
> + 'chatr' \
> + 'dump -H' \
> + 'elfdump -Dl' \
> + 'odump -Dl' \
> + 'otool -L' \
> + :; do
> + gl_ldd_output0=`($gl_ldd conftest$ac_exeext) 2>/dev/nu
Ralf Wildenhues wrote:
> > AC_CHECK_TOOL([OBJDUMP], [objdump], [:])
>
> This will conflict with libtool-set $OBJDUMP in packages that use
> libtool. Libtool currently uses
> AC_CHECK_TOOL([OBJDUMP], [objdump], [false])
OK, I'm changing ldd.m4 to use the same.
> This is not portable to packag
Ralf Wildenhues wrote:
> > The LDDPROG can also be used outside the shell wrapper, by other macros
> > or Makefile commands, where LC_ALL=C is not necessarily guaranteed. But
> > it will probably not hurt if I put LC_ALL=C before any LDDPROG value.
>
> Yes, good argument. I think it would be even
[redirected to bug-libtool, from bug-gnulib]
Ralf Wildenhues wrote:
> > The fact that a libtool created "program" is not actually a program but a
> > script, is a problem of libtool. Fix that, then we can also use
> > "gdb program" instead of the surprising syntax "libtool gdb program".
>
> Two co
Simon Josefsson wrote:
> I installed this patch:
>
> Index: modules/socklen
> ===
> RCS file: /sources/gnulib/gnulib/modules/socklen,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -p -r1.2 -r1.3
> --- modules/socklen
Simon Josefsson wrote:
> >> +#include
> >>
> >> License:
> >> unlimited
> >
> > Then 'socklen' should also have a dependency on 'sys_socket'.
>
> I'm not sure. It gets ugly if no modules can assume sys/socket.h
> without depending on sys_socket?
That's the point of the sys_socket module.
If y
Paul Eggert wrote:
> Stepping back from things a bit, I discovered a way to simplify
> lib-ignore so that it no longer needs to use ldd. Instead, it merely
> uses the '-z ignore' option if this works.
All the better.
One more question about this macro: What is the difference between
-Xlinker and
Simon Josefsson wrote:
> My problem is getting
> AC_SEARCH_LIBS to find functions in the mingw32 libraries. It seems a
> __stdcall is required in the prototype to make it link correctly.
The prototype with __stdcall must be contained in a public include file,
no? (, included by your substitute.)
Simon Josefsson wrote:
> This fixes the socklen M4 test. It more or less duplicate the
> sys_socket module but I don't see any other way around it.
Duplication of code always leads to maintenance problems. Not sometimes.
Always. (I tried it often enough ;-))
Already in this patch it is not clear
Simon Josefsson wrote:
> AC_SEARCH_LIBS(gethostbyname, [inet nsl])
> ...
> if test "$ac_cv_search_gethostbyname" = "no"; then
> save_LIBS="$LIBS"
> LIBS="$LIBS -lwsock32"
> AC_MSG_CHECKING([whether we need -lwsock32])
> AC_LINK_IFELSE([
> AC_LANG_PROGRAM([[
> #include
Wh
Sergey Poznyakoff wrote:
> Shouldn't `--avoid' work with `--extract-dependencies'? I propose the
> following patch:
Thanks for the suggestion, but I don't think it fits well:
- The --extract-* modes are all intended as low-level facilities, just
reading the contents of the module description.
-
Karl Berry wrote:
> It seems gnulib changes have been made to argp-fmtstream.h,
> localcharset.c, previously synced from libc and gettext-runtime
> respectively. Should I comment out the sync ?
Yes please.
Bruno
___
bug-gnulib mailing list
bug-gnuli
security problem...
Bruno
2006-01-22 Bruno Haible <[EMAIL PROTECTED]>
* vasnprintf.c (VASNPRINTF): In the computation of the size of the
temporary buffer for sprintf, take into account the precision also
for 'd', 'i', 'u', 'o', &#
[For the automake people: The problem is that a Makefile.am snippet like
TESTS = test-lock
check_PROGRAMS = test-lock
test_LOCK_LDFLAGS = -lmyspeciallib
when cross-compiling to mingw on a Unix system with 'wine', will cause
"make check" to build 'test-lock', rather than 'test-lock.
Simon Josefsson wrote:
> 2006-01-19 Simon Josefsson <[EMAIL PROTECTED]>
>
> + * modules/lock-tests, modules/tls-tests: Use check_PROGRAMS
> + instead of noinst_PROGRAMS to be able to remove test_*_SOURCES.
> +
Thanks, I have applied the uncontroversial part of it, not the $(EXEEXT),
whi
Simon Josefsson wrote:
> +#if !defined(SHUT_WR) && defined (SD_SEND)
> +# define SHUT_WR 1
> +#endif
> +#if !defined(SHUT_RDWR) && defined (SD_BOTH)
> +# define SHUT_RDWR 2
> +#endif
Is SD_SEND == 1 and SD_BOTH == 2 ?
Bruno
___
bug-gnulib mailing lis
Paul Eggert wrote:
> I don't see any technical reason to prefer the parentheses.
While I agree that there are no technical reason to put the parentheses,
I wouldn't be religious on the issue, because the majority of the C
programmers does it the other way. The same argument as for "const char *":
Ralf Wildenhues wrote:
> > check_PROGRAMS = test-lock$(EXEEXT)
> >
> > TESTS = test-lock
> ...
> What about @substituted@ values?
TESTS = @substituted@
You could treat it like @substituted@ in check_PROGRAMS, namely
- assume that $(EXEEXT) is contained in the substituted value,
- warn if EXTR
Ralf Corsepius wrote:
> Due to lack of a mingw toolchain, I can't tell you exactly what goes
> wrong for you.
>
> 3 likely candidates:
> * The cross gcc doesn't produce *.exe's (This would be a gcc bug).
> * You are not correctly invoking configure.
> * Makefile bug somewhere.
Is there need to hyp
rs
> typedef bool _Bool;
> ^
>
> Patch below fixes this.
Thanks, I've applied an equivalent of your patch. Sorry for the extremely
long delay.
Bruno
2006-01-24 Bruno Haible <[EMAIL PROTECTED]>
* stdbool_.h (_Bool) [__cplusplus]: Don't define if
Jim Meyering wrote:
> you must admit the
> parentheses in `#if defined (SYM)' add next to nothing in readability,
> and actually detract as soon as you end up adding another layer of
> parentheses:
>
> #if (defined (S1) || defined (S2)) && defined (S3)
I agree with this. If this were the only pi
Mark D. Baushke wrote:
> on a Solaris 9 system
> I have run into problems when /bin/sh is used.
>
> ...
>
> I am getting these two errors:
>
> sed: -e expression #1, char 2: unterminated `s' command
> ../gnulib/gnulib-tool: .*^I,,: not found
> sed: -e expression #1, char 2: unterminated `s' command
27;m therefore applying the following minimal-change, punish-only-the-
broken-ones, patch.
Bruno
2006-01-24 Bruno Haible <[EMAIL PROTECTED]>
* stdbool_.h (_Bool) [HP-UX cc, AIX cc,xlc] : Define as 'signed char'
to avoid problems with the built-in _Bool type.
R
Paul Eggert wrote on 2005-11-26:
> Here is a proposed patch,
> which I've installed into coreutils (but not gnulib).
Thanks for the patch, and I'm sorry for the long delay in looking at it.
Two points that I don't understand:
> /* BeOS already #defines false 0, true 1. We use the same
> - d
Paul Eggert wrote:
> While looking into an old Bison bug report for IRIX
Where can I find the report, please?
Bruno
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Simon Josefsson wrote:
> Unless there is a simple concrete solution to this, I'm inclined to
> install the patch below and document that people using this module
> will have to call WSAStartup manually,
I don't know the simple concrete solution either :-), so I would do like
you say.
> +#define W
Paul Eggert wrote:
> (__strndup): Revert to K&R-style function dfns, the glibc style.
Huh? We know the problems of K&R-style function definitions: arguments
of type 'float', 'short' and 'char' are implicitly promoted, leading to
a clash with the function prototype. Empty argument lists allow
./gnulib/gnulib-tool: -: not found
I'm trying this patch. Does it work for you?
2006-01-25 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_import): Use "trap :" instead of "trap -" to get
rid of a trap command. For Solaris sh.
Reporte
A gnulib testdir with modules fts and quotearg fails to compile on IRIX 6.5
with CC="cc -O":
cc -O -DHAVE_CONFIG_H -I. -I. -I.. -g -c fts.c
"fts.c", line 244: error(1241): declaration may not appear after executable
statement in block
size_t maxarglen = fts_maxargle
"enum" in C was
introduced for exactly this kind of symbolic values,
- Regarding the stdbool and stdint modules, I prefer an approach that
doesn't break unrelated platforms. We have already invested some effort
in these modules. I'm not interested in retesting
The obstack module does not compile on MacOS X:
Making all in lib
make all-am
gcc -DHAVE_CONFIG_H -I. -I../../../megatestdir/obstack/lib -I.. -g -O2 -c
../../../megatestdir/obstack/lib/exitfail.c
gcc -DHAVE_CONFIG_H -I. -I../../../megatestdir/obstack/lib -I.. -g -O2 -c
../../../megatest
Hi,
Building the module 'fts-lgpl' on Linux/glibc fails like this:
gcc -DHAVE_CONFIG_H -I. -I/packages/megatestdir/fts-lgpl/lib -I.. -g -O2 -c
/packages/megatestdir/fts-lgpl/lib/fts.c
/packages/megatestdir/fts-lgpl/lib/fts.c:75:20: lstat.h: No such file or
directory
The reason is that the
Eric Blake wrote:
> Remember this thread, which patched the same bug in install-sh?
> http://lists.gnu.org/archive/html/bug-autoconf/2005-11/msg0.html
Thanks for this pointer. It is regrettable that no doc was added to
the autoconf manual about this pitfall.
> Wouldn't "trap ''" be better tha
Hi Jim,
> Regarding the second patch, I see no explanation for why it
> makes such a fundamental change (not appending `.'?).
Actually the end of that function was a bit incomplete. It should probably
look like this:
/* FILE refers to a symbolic link and the name ends with a slash.
Ca
Mark D. Baushke wrote:
> > I'm trying this patch. Does it work for you?
>
> Yes.
Thanks. I've committed the fix.
> | If argument is absent, all
> | trap(s) n are reset to their original values.
This explains how "trap" without arguments works, not how "trap 0 1 2 3 15"
work
Paul Eggert wrote:
> The difference can be seen with this script:
>
> trap : 2
> sleep 5
> sleep 10
>
> If you execute this with "bash -x", and interrupt the "sleep 5" with
> Control-C, you'll see that the "sleep 10" is executed with "trap :",
> whereas it would not be executed with "trap -".
Oh,
Paul Eggert wrote:
> How about this change? It reflects what's currently installed into
> coreutils (I merged your changes). I've tested this with GCC 2.95 and
> it works the way you like there.
Thanks,
> The basic idea is to make bool an
> enum type when using GCC, but to fall back on signed c
1 - 100 of 14386 matches
Mail list logo
