> From: Bruno Haible
> Cc: bug-gnulib@gnu.org, tim.rueh...@gmx.de
> Date: Sat, 12 May 2018 20:40:46 +0200
>
> I don't want to revert the #if, i.e. prefer fseeko64 to _fseeki64, because
> the idea of mingw is to use the maximum of functions from the CRT DLLs.
>
> So I ended up adding the test for
Eli Zaretskii wrote:
> > Do you know how to distinguish the two, just by preprocessor defines,
> > without any autoconf test?
>
> AFAIK, it's tricky, because MinGW64 also defines __MINGW32__, and
> doesn't have any macro specific to it that is defined by the compiler
> itself. In Emacs we use thi
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org, tim.rueh...@gmx.de
> Date: Sat, 12 May 2018 17:13:21 +0200
>
> Eli Zaretskii wrote:
> > Would it be okay to use 'unsigned' instead of 'uint8_t' on all
> > platforms?
>
> Yes, this is a good idea. Done:
Thank you.
Eli Zaretskii wrote:
> Would it be okay to use 'unsigned' instead of 'uint8_t' on all
> platforms?
Yes, this is a good idea. Done:
2018-05-12 Bruno Haible
glob: Choose 'dirent_type' in a way that works better on mingw.
Reported and suggested by Eli Zaretskii .
* lib/g
> From: Bruno Haible
> Cc: Eli Zaretskii , Tim Rühsen
> Date: Sat, 12 May 2018 14:59:43 +0200
>
> The warning is harmless. But if some day the DT_* values get to get actually
> used, there is a bug here. I acknowledge there is a problem.
>
> However, 'typeof' works only GNU or GNU-compatible co
> From: Bruno Haible
> Cc: Tim Rühsen
> Date: Sat, 12 May 2018 14:31:59 +0200
>
> > This is because configure-time test for _fseeki64 succeeds, but the
> > prototype of _fseeki64 is not visible unless the condition
> >
> > _WIN32_WINNT >= 0x0600
> >
> > holds
>
> According to
> https://sou
> From: Bruno Haible
> Cc: Tim Rühsen
> Date: Sat, 12 May 2018 14:18:36 +0200
>
> >CC glob.lo
> > glob.c: In function 'glob_in_dir':
> > glob.c:1331:32: warning: case label value exceeds maximum value for
> > type
> > case DT_DIR: case DT_LNK: case DT
The warning is harmless. But if some day the DT_* values get to get actually
used, there is a bug here. I acknowledge there is a problem.
However, 'typeof' works only GNU or GNU-compatible compilers. Whereas d_type
exists on many platforms (Linux, macOS, FreeBSD, NetBSD, OpenBSD, Cygwin,
Android),
Eli Zaretskii wrote:
> While building the latest pretest of wget2 with mingw.org's MinGW, I
> saw this warning:
>
>CC fseeko.lo
> fseeko.c: In function 'fseeko':
> fseeko.c:37:18: warning: implicit declaration of function '_fseeki64'
> [-Wimplicit-function-declaration]
>
Eli Zaretskii wrote:
> Building the latest pretest of wget2 on MinGW produces the following
> warning:
>
>CC glob.lo
> glob.c: In function 'glob_in_dir':
> glob.c:1331:32: warning: case label value exceeds maximum value for type
> case DT_DIR: case DT_
On Wed, May 9, 2018 at 5:56 PM, Assaf Gordon wrote:
> This echoes back to Bruno's suggestion of runtime parsing of
> /proc/crypto - which adds more complexity.
>
That's very difficult, as entries will appear in /proc only after a module load
>
> For example if this change is endorsed by Redhat,
Eli Zaretskii wrote:
> }
> #define close nonintr_close
>
> IMO, it should use #undef before redefining 'close'.
Yup. The file lib/pipe-filter-aux.h already contains this fix, but
lib/spawn-pipe.c doesn't.
2018-05-12 Bruno Haible
execute, spawn-pipe: Avoid warning about redefinin
Eli Zaretskii wrote:
> While building the latest pretest of wget2, I saw that the Gnulib's
> detection of nanosleep fails to detect its presence in mingw.org's
> MinGW runtime. The test program used for that fails for unrelated
> reason: it uses SIGALRM, which is unavailable on MS-Windows.
>
> I'
> From: Bruno Haible
> Cc: Tim Rühsen
> Date: Sat, 12 May 2018 10:44:54 +0200
>
> Hi Eli,
>
> > The problem described below was found when building the latest pretest
> > of wget2 with mingw.org's MinGW system headers and libraries.
>
> Oh, there are still people who use the (old) mingw.org sy
Hi Eli,
> The problem described below was found when building the latest pretest
> of wget2 with mingw.org's MinGW system headers and libraries.
Oh, there are still people who use the (old) mingw.org system?
I thought everyone by now had switched to mingw-w64. This (newer) mingw
does not exhibit
While building the latest pretest of wget2, I saw that the Gnulib's
detection of nanosleep fails to detect its presence in mingw.org's
MinGW runtime. The test program used for that fails for unrelated
reason: it uses SIGALRM, which is unavailable on MS-Windows.
I'm guessing that SIGALRM is used t
Building the latest pretest of wget2 on MinGW produces the following
warning:
CC glob.lo
glob.c: In function 'glob_in_dir':
glob.c:1331:32: warning: case label value exceeds maximum value for type
case DT_DIR: case DT_LNK: case DT_UNKNOWN: break;
While building the latest pretest of wget2 with mingw.org's MinGW, I
saw this warning:
CC fseeko.lo
fseeko.c: In function 'fseeko':
fseeko.c:37:18: warning: implicit declaration of function '_fseeki64'
[-Wimplicit-function-declaration]
# define fseeko _fseeki64
While building the latest pretest of wget2, I see this warning:
CC spawn-pipe.lo
spawn-pipe.c:75:0: warning: "close" redefined
#define close nonintr_close
In file included from spawn-pipe.h:23:0,
from spawn-pipe.c:27:
./unistd.h:758:0: note:
The problem described below was found when building the latest pretest
of wget2 with mingw.org's MinGW system headers and libraries.
Compilation of utimens.c fails thusly:
In file included from ./sys/stat.h:47:0,
from ./fcntl.h:58,
from utimens.c:2
20 matches
Mail list logo
