Hello Sylvain,
* Sylvain Beucler wrote on Sun, Oct 07, 2007 at 10:41:34PM CEST:
[...]
> However at that point the Gnulib include path is not set (the
> documentation recommends to do so in Makefile.am, not as early as
> configure.ac).
>
> Moreover, I can't find a way to specify $top_srcdir and $t
I think there is a very small typo in xmalloca.h:
/* xmalloca(N) is a checking safe variant of alloca(N). It allocates N bytes
- of memory allocated on the stack, that must be freed using freesa() before
+ of memory allocated on the stack, that must be freed using freea() before
the func
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff wrote:
>> There is a huge amount of redundancy in the m4 code across all
>> six modules (trunc*, round*) and perhaps others. Perhaps I
>> should write a common m4 macro that just takes a parameter or two
>> and avoids the redundancy. Bruno, do
Hi,
I'm cross-compiling an SDL application for i586-mingw32mscv. I
imported the alloca module from Gnulib, as a dependency of strcasestr.
When checking for SDL.h,
AC_CHECK_HEADERS(SDL.h SDL_rotozoom.h SDL_framerate.h SDL_image.h,
[], AC_MSG_ERROR([Could not find necessary SDL libs header
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> printf-frexp.c evokes a shadowing warning on at least a debian unstable
>> system, and now that coreutils uses it (via vasprintf-posix), it causes
>> the "make distcheck" build to fail:
>>
>> printf-frexp.c: In function 'printf_fre
Jim Meyering wrote:
> printf-frexp.c evokes a shadowing warning on at least a debian unstable
> system, and now that coreutils uses it (via vasprintf-posix), it causes
> the "make distcheck" build to fail:
>
> printf-frexp.c: In function 'printf_frexp':
> printf-frexp.c:65: error: declaration
Bruno Haible <[EMAIL PROTECTED]> wrote:
>> > "rm d" should fail at
>> > remove.c:1094 with "cannot remove 'd': Is a directory"
>> > but fails there with "cannot remove 'd': No such file or diectory"
>
> remove.c:1094 reads like this:
>
> error (0, errno, _("cannot remove %s"),
>
On Sun, 7 Oct 2007, Jim Meyering wrote:
Martin Koeppe <[EMAIL PROTECTED]> wrote:
The test tests/rm/dir-nonrecur shows IMO a real bug in coreutils,
however:
"rm d" should fail at
remove.c:1094 with "cannot remove 'd': Is a directory"
but fails there with "cannot remove 'd': No such file or
Hi Bruno,
printf-frexp.c evokes a shadowing warning on at least a debian unstable
system, and now that coreutils uses it (via vasprintf-posix), it causes
the "make distcheck" build to fail:
printf-frexp.c: In function 'printf_frexp':
printf-frexp.c:65: error: declaration of 'exp' shadows a gl
I noticed a new warning, when compiling with
gcc version 4.3.0 20071004 (experimental) (GCC)
xnanosleep.c:79: warning: assuming signed overflow does not occur
when assuming that (X + c) < X is always false
Here's what I've just pushed:
2007-10-07 Jim Meyering <[EMAIL PROTECTED]>
As proposed a week ago:
> Now I propose to change the documented meaning of "GPL" and "LGPL" in
> the modules files (to GPLv3+ and LGPLv3+, respectively)
Done:
2007-10-07 Bruno Haible <[EMAIL PROTECTED]>
* doc/gnulib-intro.texi (Copyright): Update the meaning of the license
abb
> > "rm d" should fail at
> > remove.c:1094 with "cannot remove 'd': Is a directory"
> > but fails there with "cannot remove 'd': No such file or diectory"
remove.c:1094 reads like this:
error (0, errno, _("cannot remove %s"),
quote (full_filename (filename)));
_
Hi Bruno,
Bruno Haible <[EMAIL PROTECTED]> writes:
> Therefore I would recommend to use the mem_cd_iconveh function from the
> 'striconveh' module, with FROMCODE = locale_charset() and TOCODE =
> "UTF-16BE" or "UTF-16LE" (or vice versa). Or mem_iconveh you don't
> want to reuse the conversion des
Simon Josefsson wrote:
> > lib/stdint.in.h
>
> modules/stdint says:
>
> License:
> LGPLv2+
>
> I need stdint in libidn.
Sure. It was a mistake due to the recent file renamings.
I have now done the change. Find attached the file list.
For the change, I noticed several variations of the "standa
On Oct 7, 2007, at 5:15 AM, Bruno Haible wrote:
Ben Pfaff noticed that, unlike floor() and ceil(), the function
trunc()
is not declared by default on glibc systems. (The difference is in
/usr/include/bits/mathcalls.h.)
This should fix it.
2007-10-06 Bruno Haible <[EMAIL PROTECTED]>
Martin Koeppe <[EMAIL PROTECTED]> wrote:
> The test tests/rm/dir-nonrecur shows IMO a real bug in coreutils,
> however:
> "rm d" should fail at
> remove.c:1094 with "cannot remove 'd': Is a directory"
> but fails there with "cannot remove 'd': No such file or diectory"
>
> If I remove the tra
Daniel Jacobowitz wrote:
> It's a bug in open that it doesn't recognize a nonexistant device for
> a different system?
It's an interoperability problem that people report.
FWIW, perl does the same thing in its win32/win32.c file:
DllExport int
win32_open(const char *path, int flag, ...)
{
Brian Dessent wrote:
> Eric Blake wrote:
> > This is because the msys shell is specially compiled with a hack that
> > alters command line arguments that look like filenames into their windows
> > equivalent, before invoking the child program. ...
>
> This is not true, the argument translation is
On Sat, 6 Oct 2007, Jim Meyering wrote:
Martin Koeppe <[EMAIL PROTECTED]> wrote:
The first 'Segmentation fault' with dd doesn't occur when I run just
the failing command in the src dir:
./dd cbs=4 ibs=4 conv=unblock,sync < dd-in > dd-out
dd-out looks fine there. So I don't currently know how t
Bruno Haible wrote:
> The precise circumstances are not clear to me. When I run, from an rxvt
> running the msys /bin/sh,
>
> $ H:/msys/local/bin/msgfmt.exe --statistics /dev/null
>
> it succeeds. When from this shell, I run "cmd" (the Microsoft command
> interpreter), and from there
Like Eri
20 matches
Mail list logo
