I installed the following to sync with changes I'm about to install
into coreutils. Basically this removes some unnecessary differences
between sha1 and md5, mostly by moving Bruno's recent md5 improvements
into sha1.
2006-01-11 Paul Eggert <[EMAIL PROTECTED]>
* md5.c: Fix commentary t
Bruno Haible <[EMAIL PROTECTED]> writes:
> Is -zignore fully portable? If you find only a single platform where
> -zignore's functionality does not exist, then you need to go back to the
> explicit list of potential dependencies.
No, because the link will still work even if we link to all the
lib
Simon Josefsson <[EMAIL PROTECTED]> writes:
> Is there a clean fix?
How about something like this?
#if UCHAR_MAX == 255
# define uchar_in_range(c) true
#else
# define uchar_in_range(c) ((c) <= 255)
#endif
and then use uchar_in_range in the rest of your code.
__
* Paul Eggert wrote on Wed, Jan 11, 2006 at 07:28:55PM CET:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>
> > And if I know anything about how autotools-using build systems
> > expect link flags and libraries, then you're not supposed to put
> > `-lrt' in LDFLAGS, but in LIBS.
>
> Yes, that's
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
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
Bruno Haible <[EMAIL PROTECTED]> writes:
> It is not so easy.
> ...
> d) Don't try to emulate the BSD API at all. Use function names like
>set_program_name()
>get_program_name()
>get_program_base_name() or get_program_short_name().
> ...
> My vote is therefore for d).
Me
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Similarly, `-zignore' is linker dependent.
Yes. If some linkers need some other option to do that, we'll need to
add it to lib-ignore.m4. But in the meantime the existing code should
produce working executables, even with those linkers, since it doe
Bruno Haible <[EMAIL PROTECTED]> writes:
> The problem is brought in by the fact that we build a single libgnulib or
> libcoreutils for all executables of a package, and if a single function
> in this library needs, say, high-resolution timers, the libgnulib or
> libcoreutils has "-lrt" in its lin
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
* Bruno Haible wrote on Wed, Jan 11, 2006 at 01:44:27PM CET:
> 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
* Bruno Haible wrote on Wed, Jan 11, 2006 at 05:20:48PM CET:
> 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 hav
Bruno Haible <[EMAIL PROTECTED]> writes:
> 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
* Bruno Haible wrote on Wed, Jan 11, 2006 at 01:56:51PM CET:
> 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 `is
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?
>
> I committed this patch.
Works fine, thanks!
However, I'm wondering whether:
AC_CONFIG
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi Simon and Paul,
>
> The func_create_megatestdir part of this patch
>
> 2004-09-18 Simon Josefsson <[EMAIL PROTECTED]>
> and Paul Eggert <[EMAIL PROTECTED]>
>
> * gnulib-tool: Replace various ad-hoc automake/autoconf/aclocal
>
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
Installed. 2006-01-11 Simon Josefsson <[EMAIL PROTECTED]>
* stdint_.h (SIZE_MAX): Add missing (.
--- stdint_.h 09 Jan 2006 14:49:23 +0100 1.10
+++ stdint_.h 11 Jan 2006 18:11:10 +0100
@@ -245,7 +245,7 @@
#define SIG_ATOMIC_MAX 127
#ifndef SIZE_MAX /* SIZE_MAX may also
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 -
Hi Bruno,
* Bruno Haible wrote on Wed, Jan 11, 2006 at 01:48:02PM CET:
> *** gnulib-tool.bak 2006-01-07 19:41:07.0 +0100
> --- gnulib-tool 2006-01-08 13:30:35.0 +0100
> ***
> *** 35,40
> --- 35,46
> #;;
> #esac
>
> + # You can set AUTOMAKEP
> > 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.
> >
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
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 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:
$ gnulib-tool --create-testdir --dir=testdir mathl
...
executing autoreconf --force --install
lib/Makefile.am:28: noinst_HEADERS must be set with `=' before using `+='
autoreconf: automake failed with exit status: 1
Should the module description use EXTRA_DIST instead of noinst_HEADERS?
Well, noin
Hi Simon and Paul,
The func_create_megatestdir part of this patch
2004-09-18 Simon Josefsson <[EMAIL PROTECTED]>
and Paul Eggert <[EMAIL PROTECTED]>
* gnulib-tool: Replace various ad-hoc automake/autoconf/aclocal
calls with autoreconf. Define GL_LIB.
has the effect
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_import, func_create_testdir): Replace
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/
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
$ ./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 gl_LOCK and gl_ARG
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 archive members specified" erro
31 matches
Mail list logo
