"Gabor Z. Papp" <[EMAIL PROTECTED]> wrote:
...
> Tried to compile coreutils 6.0 from alpha.gnu, and here is the result.
...
> gcc -std=gnu99 -g -O2 -Wl,--as-needed -o dd dd.o ../lib/libcoreutils.a
> ../lib/libcoreutils.a
> ../lib/libcoreutils.a(gettime.o): In function `gettime':
> /home/gzp/sr
Jim Meyering <[EMAIL PROTECTED]> wrote:
> "Gabor Z. Papp" <[EMAIL PROTECTED]> wrote:
> ...
>> Tried to compile coreutils 6.0 from alpha.gnu, and here is the result.
> ...
>> gcc -std=gnu99 -g -O2 -Wl,--as-needed -o dd dd.o ../lib/libcoreutils.a
>> ../lib/libcoreutils.a
>> ../lib/libcoreutils.
Hi,
On NetBSD 3.0/x86, coreutils fail to compile like this:
if gcc -std=gnu99 -DHAVE_CONFIG_H -DLIBDIR=\"/home/bruno/gnu/lib\" -I. -I. -I..
-I.. -I. -I/home/bruno/gnu/include -g -O2 -MT mountlist.o -MD -MP -MF
".deps/mountlist.Tpo" -c -o mountlist.o mountlist.c; then mv -f
".deps/mountlis
Hi,
Internationalization of packages that use bison parsers needs a macro
from bison: m4/bison-i18n.m4. gettext has up to now taken it directly
from bison, but gnulib makes for a better distribution mechanism
(with automatic updates). I propose to add it as a module.
=== modu
Hi,
Are there no comments regarding
http://lists.gnu.org/archive/html/bug-gnulib/2006-07/msg00333.html ?
This is code that should fix a problem also in glibc.
Bruno
The module strstr is internationalized, fine. But there are some cases
where it's overkill and the classical and faster byte-per-byte string
traversal can be used instead. I propose to add a new module c-strstr
in the same philosophy as c-ctype, c-strcase, c-strcasestr.
===
Thanks; I installed that patch into gnulib too, since I'm working on
getting coreutils to use gnulib-tool.
For gnulib readers, here's the just-installed patch:
http://lists.gnu.org/archive/html/bug-coreutils/2006-08/msg00141.html
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Thanks; I installed that patch into gnulib too,
Thanks.
> since I'm working on getting coreutils to use gnulib-tool.
Great!
Thanks, that looks nice, but some quibbles about the comments:
> /* The functions defined in this file assume the "C" locale and a character
>set without diacritics (ASCII-US or EBCDIC-US or something like that).
>Even if the "C" locale on a particular system is an extension of the ASCII
>
Good idea, thanks. Two minor points:
> if test -n "$BISON_LOCALEDIR"; then
> USER_LINGUAS="${LINGUAS-%UNSET%}"
> if test -n "$USER_LINGUAS"; then
What is the significance of the %UNSET% here? I.e., why is an unset
LINGUAS treated as nonempty? Maybe a comment would help?
>
Bruno Haible <[EMAIL PROTECTED]> writes:
> 2006-08-18 Bruno Haible <[EMAIL PROTECTED]>
>
> Add support for NetBSD 3.0.
> * m4/ls-mntd-fs.m4 (gl_LIST_MOUNTED_FILE_SYSTEMS): Also check for
> sys/statvfs.h. When getmntinfo was found, check its declaration and
> set either MO
Paul Eggert wrote:
> > /* The functions defined in this file assume the "C" locale and a character
> >set without diacritics (ASCII-US or EBCDIC-US or something like that).
> >Even if the "C" locale on a particular system is an extension of the
> > ASCII
> >character set (like on BeOS,
Bruno Haible <[EMAIL PROTECTED]> writes:
> The "nearly an ASCII extension" assumption is so ubiquitous, think of
> (c >= '0') tests and similar. You really find it's worth mentioning?
Digits are a very special case, because the C standard (C89
onward) guarantees that they are in order and contigu
Paul Eggert wrote:
> Good idea, thanks. Two minor points:
>
> > if test -n "$BISON_LOCALEDIR"; then
> > USER_LINGUAS="${LINGUAS-%UNSET%}"
> > if test -n "$USER_LINGUAS"; then
>
> What is the significance of the %UNSET% here? I.e., why is an unset
> LINGUAS treated as nonempty?
Bruno Haible <[EMAIL PROTECTED]> writes:
> Therefore most of our "c-*" modules should better be called
> "ascii-*" or "unibyte-*".
But both ASCII and other unibyte locales might say that some bytes are
encoding errors. So none of these names are exactly right. I guess
c-* is as good a name as a
15 matches
Mail list logo
