windows build failure

windows build failure

[Sean Sieger]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

In file included from w32.c:33:0:
../nt/inc/sys/time.h:41:62: error: conflicting types for 'restrict'
../nt/inc/sys/time.h:41:35: note: previous definition of 'restrict' was here
make[3]: *** [oo-spd/i386/w32.o] Error 1
make[3]: Leaving directory `c:/trunk/src'
make[2]: *** [bootstrap-temacs-CMD] Error 2
make[2]: Leaving directory `c:/trunk/src'
make[1]: *** [bootstrap-temacs] Error 2
make[1]: Leaving directory `c:/trunk/src'
make: *** [bootstrap-gmake] Error 2

[-- Attachment #2: Type: text/html, Size: 618 bytes --]

Re: windows build failure

[Eli Zaretskii]

> Date: Sun, 26 May 2013 16:29:36 -0400
> From: Sean Sieger <sean.sieger@gmail.com>
> 
> In file included from w32.c:33:0:
> ../nt/inc/sys/time.h:41:62: error: conflicting types for 'restrict'
> ../nt/inc/sys/time.h:41:35: note: previous definition of 'restrict' was here
> make[3]: *** [oo-spd/i386/w32.o] Error 1
> make[3]: Leaving directory `c:/trunk/src'
> make[2]: *** [bootstrap-temacs-CMD] Error 2
> make[2]: Leaving directory `c:/trunk/src'
> make[1]: *** [bootstrap-temacs] Error 2
> make[1]: Leaving directory `c:/trunk/src'
> make: *** [bootstrap-gmake] Error 2

Is this with today's bzr?  If so, what version of GCC is this, and
what does the macro-expanded nt/inc/sys/time.h look like?

I don't get this error.  Emacs builds for me on 2 different machines
with 2 different GCC versions.

Btw, I urge you to switch to the Posix build method, described in
nt/INSTALL.MSYS.

Re: windows build failure

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Btw, I urge you to switch to the Posix build method, described in
> nt/INSTALL.MSYS.

Eli, do you have on mind to deprecate the Windows makefiles on a near
future? (~1 year or so).

That would imply deprecating the support for MSVC as well, right?

Re: windows build failure

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 27 May 2013 20:07:34 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Btw, I urge you to switch to the Posix build method, described in
> > nt/INSTALL.MSYS.
> 
> Eli, do you have on mind to deprecate the Windows makefiles on a near
> future? (~1 year or so).

They are already deprecated, I announced that when I merged the Posix
build changes into the trunk, see

  http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00387.html

Perhaps you were asking whether makefile.w32-in files will be deleted.
I don't plan to do that, I think we better let them bitrot into
oblivion.  That would allow people to migrate in their own time.

> That would imply deprecating the support for MSVC as well, right?

Yes.  With at least 3 different distributions of GCC for Windows,
there doesn't seem to be a compelling reason to keep the MSVC support
alive, especially since doing so requires non-trivial efforts with
every new MSVC release.

What I'd like to do next in this department is make sure Emacs can be
built as a 64-bit executable using MinGW64 and the new Posix build
procedure.  People who have MinGW64 installed are encouraged to try
that and report any problems they have.

Thanks.

Re: windows build failure

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

Thanks for the detailed explanation. I'll migrate my build to MSYS/MinGW
then.

windows build failure

[Sean Sieger]

[-- Attachment #1: Type: text/plain, Size: 175 bytes --]

On Monday, May 27, 2013, Eli Zaretskii wrote:

Btw, I urge you to switch to the Posix build method, described in
> nt/INSTALL.MSYS.
>

Will do.  Thank you for your time, Eli.

[-- Attachment #2: Type: text/html, Size: 372 bytes --]

Re: windows build failure

[Eli Zaretskii]

> Date: Tue, 28 May 2013 14:19:34 -0400
> From: Sean Sieger <sean.sieger@gmail.com>
> 
> Btw, I urge you to switch to the Posix build method, described in
> > nt/INSTALL.MSYS.
> >
> 
> Will do.  Thank you for your time, Eli.

I'd still like to know what broke your build.  Can you answer my
questions nonetheless, please?

Re: windows build failure

[rzl24ozi]

Sean Sieger <sean.sieger@gmail.com> writes:
> In file included from w32.c:33:0:
> ../nt/inc/sys/time.h:41:62: error: conflicting types for 'restrict'
> ../nt/inc/sys/time.h:41:35: note: previous definition of 'restrict'
> was here
> make[3]: *** [oo-spd/i386/w32.o] Error 1
    :

When I try to build with non-Posix build method (run configure.bat and
make bootstrap under nt/ directory), got same error.

gcc version is TDM-GCC 4.7.1 32bit (http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/tdm-gcc-4.7.1-2.exe/download).

It looks like that 'restrict' in the prototype of gettimeofday() is
considered as variable name.

Macro-expanded nt/inc/sys/time.h look like as below.

	:
# 33 "w32.c" 2
# 1 "../nt/inc/sys/time.h" 1
# 16 "../nt/inc/sys/time.h"
struct timeval
{
  long tv_sec;
  long tv_usec;
};
# 31 "../nt/inc/sys/time.h"
struct timezone
{
  int tz_minuteswest;
  int tz_dsttime;
};





int gettimeofday (struct timeval *restrict, struct timezone *restrict);




struct itimerval
{
  struct timeval it_interval;
  struct timeval it_value;
};

int getitimer (int, struct itimerval *);
int setitimer (int, struct itimerval *, struct itimerval *);
# 34 "w32.c" 2
	:

Re: windows build failure

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Date: Wed, 29 May 2013 22:15:58 +0900
> 
> Sean Sieger <sean.sieger@gmail.com> writes:
> > In file included from w32.c:33:0:
> > ../nt/inc/sys/time.h:41:62: error: conflicting types for 'restrict'
> > ../nt/inc/sys/time.h:41:35: note: previous definition of 'restrict'
> > was here
> > make[3]: *** [oo-spd/i386/w32.o] Error 1
>     :
> 
> When I try to build with non-Posix build method (run configure.bat and
> make bootstrap under nt/ directory), got same error.
> 
> gcc version is TDM-GCC 4.7.1 32bit (http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/tdm-gcc-4.7.1-2.exe/download).

I built that version with GCC 4.7.2 from mingw.org, and didn't get the
problem.

> It looks like that 'restrict' in the prototype of gettimeofday() is
> considered as variable name.

That part is clear from the error message.  What is less clear is why
does that happen.  'restrict' is a keyword in C, so unless the
compiler has a bug, I don't understand why it barfs.  Maybe I'm
missing something here.

If you type this:

  cpp -dM < nul | fgrep restrict

what do you see?

Re: windows build failure

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> When I try to build with non-Posix build method (run configure.bat and
>> make bootstrap under nt/ directory), got same error.
>> 
>> gcc version is TDM-GCC 4.7.1 32bit (http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/tdm-gcc-4.7.1-2.exe/download).
>
> I built that version with GCC 4.7.2 from mingw.org, and didn't get the
> problem.

Two days ago I tried the autotools-based build method with a fresh MSYS
install + MinGW-w64 4.7.2 (32 bits) and it complained with redefinitions
of some time-related functions. Then tried with MinGW's gcc 4.6.? and it
worked fine.

Maybe TDM is using the MinGW-w64 headers?

BTW, I had to install msys-coreutils-ext package with mingw-get for
avoiding hundreds of messages about non-existing chown executable while
on `make install'.

Apart from that and ignoring the big fat MSYS dependency, using the
autotools build on Windows was smooth enough. Thank you.

Re: windows build failure

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 29 May 2013 17:50:02 +0200
> 
> Two days ago I tried the autotools-based build method with a fresh MSYS
> install + MinGW-w64 4.7.2 (32 bits) and it complained with redefinitions
> of some time-related functions. Then tried with MinGW's gcc 4.6.? and it
> worked fine.

Please always report any such problems.  Otherwise, we stand no chance
of cleaning up the MSYS build with all the available toolchains.

> Maybe TDM is using the MinGW-w64 headers?

Maybe.  But the problem reported here was not with time functions, it
was with 'restrict' keyword that somehow is not interpreted as a
keyword.

> BTW, I had to install msys-coreutils-ext package with mingw-get for
> avoiding hundreds of messages about non-existing chown executable while
> on `make install'.

Yes, all the MSYS packages on the "Base" page should be installed in
full, to have a fully functional MSYS installation.

> Apart from that and ignoring the big fat MSYS dependency, using the
> autotools build on Windows was smooth enough. Thank you.

Thanks for trying it.

Re: windows build failure

[Paul Eggert]

On 05/29/13 08:21, Eli Zaretskii wrote:
> 'restrict' is a keyword in C, so unless the
> compiler has a bug

... or unless the compiler is operating in pre-C99 mode,
which is the default even with GCC 4.8.0.  The 'restrict'
keyword was introduced in C99.  'configure'
should be figuring this out, and adding the option
-std=gnu11 or whatever, but evidently this isn't working
for your correspondents.  Possibly the .h file is
being configured as if C99 were supported, but the compiler
itself is running in pre-C99 mode.

Re: windows build failure

[Eli Zaretskii]

> Date: Wed, 29 May 2013 10:02:40 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 05/29/13 08:21, Eli Zaretskii wrote:
> > 'restrict' is a keyword in C, so unless the
> > compiler has a bug
> 
> ... or unless the compiler is operating in pre-C99 mode,
> which is the default even with GCC 4.8.0.  The 'restrict'
> keyword was introduced in C99.  'configure'
> should be figuring this out, and adding the option
> -std=gnu11 or whatever, but evidently this isn't working
> for your correspondents.  Possibly the .h file is
> being configured as if C99 were supported, but the compiler
> itself is running in pre-C99 mode.

What could cause such a discrepancy, when the configure script runs
the same compiler that is used in compilation?

Also, I see that the configure script puts -std=gnu99 on the GCC
command line, which should fix this, right?

Re: windows build failure

[Paul Eggert]

On 05/29/13 10:20, Eli Zaretskii wrote:
> the configure script puts -std=gnu99 on the GCC
> command line, which should fix this, right?

Yes, that's the idea.  Possibly the appropriate
'make' variable is not being used in a makefile.in
somewhere, though; that might explain the problem.
Or perhaps someone is invoking 'make' by hand and
is overriding CC or CFLAGS, and is forgetting to
include -std=gnu99 in the right spot.

Re: windows build failure

[Eli Zaretskii]

> Date: Wed, 29 May 2013 11:55:26 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 05/29/13 10:20, Eli Zaretskii wrote:
> > the configure script puts -std=gnu99 on the GCC
> > command line, which should fix this, right?
> 
> Yes, that's the idea.  Possibly the appropriate
> 'make' variable is not being used in a makefile.in
> somewhere, though; that might explain the problem.
> Or perhaps someone is invoking 'make' by hand and
> is overriding CC or CFLAGS, and is forgetting to
> include -std=gnu99 in the right spot.

If we do this somewhere (e.g., in nt/config.nt):

 #define restrict __restrict

would this solve the problem even when -std=gnu99 is not in use?

Re: windows build failure

[Paul Eggert]

On 05/29/13 13:28, Eli Zaretskii wrote:
> If we do this somewhere (e.g., in nt/config.nt):
> 
>  #define restrict __restrict
> 
> would this solve the problem even when -std=gnu99 is not in use?

It might, yes.  But it's probably better not to.

If 'configure' is using different CFLAGS than 'make' is using,
there are likely other screwups, some of which could well cause
subtle runtime failures.  It could well be a good thing that
the messed-up build is failing so reliably.

Re: windows build failure

[Eli Zaretskii]

> Date: Wed, 29 May 2013 14:27:28 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 05/29/13 13:28, Eli Zaretskii wrote:
> > If we do this somewhere (e.g., in nt/config.nt):
> > 
> >  #define restrict __restrict
> > 
> > would this solve the problem even when -std=gnu99 is not in use?
> 
> It might, yes.  But it's probably better not to.
> 
> If 'configure' is using different CFLAGS than 'make' is using,
> there are likely other screwups, some of which could well cause
> subtle runtime failures.  It could well be a good thing that
> the messed-up build is failing so reliably.

This problem was reported for the build that does not use the Posix
configure script, but the old Windows makefile.w32-in files.  Those do
not probe the compiler like the configure script does, and they use
-std=gnu99 only in the non-optimized build.

So I think using __restrict is the right cure for that situation, and
it should be good enough, since that way of building is deprecated.

Thanks.

Re: windows build failure

[rzl24ozi]

Óscar Fuentes <ofv@wanadoo.es> writes:
> Maybe TDM is using the MinGW-w64 headers?

TDM (32bit) is not using MinGW64 headers. TDM64 is using it.

Eli Zaretskii <eliz@gnu.org> writes:
> If you type this:
>
>   cpp -dM < nul | fgrep restrict
>
> what do you see?

I see no output.

I write:
> When I try to build with non-Posix build method (run configure.bat and
> make bootstrap under nt/ directory), got same error.

"-std=gnu99" is not used when configured by nt/configure.bat.

When I try make bootstrap CC="gcc -std=gnu99", it seems that this problem
is solved.

Re: windows build failure

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Date: Thu, 30 May 2013 08:35:23 +0900
> 
> > When I try to build with non-Posix build method (run configure.bat and
> > make bootstrap under nt/ directory), got same error.
> 
> "-std=gnu99" is not used when configured by nt/configure.bat.
> 
> When I try make bootstrap CC="gcc -std=gnu99", it seems that this problem
> is solved.

If you edit this line in nt/config.nt:

#undef restrict

to say this instead:

#define restrict __restrict

and then re-configure and rebuild, does the problem go away even
without using -std=gnu99?

Re: windows build failure

[rzl24ozi]

Eli Zaretskii <eliz@gnu.org> writes:
> If you edit this line in nt/config.nt:
>
> #undef restrict
>
> to say this instead:
>
> #define restrict __restrict
>
> and then re-configure and rebuild, does the problem go away even
> without using -std=gnu99?

I try it but still got error because w32.c include config.h after sys/time.h.

Re: windows build failure

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Cc: emacs-devel@gnu.org
> Date: Fri, 31 May 2013 04:38:20 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > If you edit this line in nt/config.nt:
> >
> > #undef restrict
> >
> > to say this instead:
> >
> > #define restrict __restrict
> >
> > and then re-configure and rebuild, does the problem go away even
> > without using -std=gnu99?
> 
> I try it but still got error because w32.c include config.h after sys/time.h.

Right, I forgot about that.

Please try with the latest trunk.

MinGW64 (32bit) build with posix configure (Re: windows build failure)

[rzl24ozi]

Eli Zaretskii <eliz@gnu.org> writes:
> Please try with the latest trunk.

I tried to build with nt/configure.bat and got no error.
Thanks.

I also tried to build with posix configure and it worked well.

Then, I changed gcc to MinGW64 gcc (32bit).
I got some time-related errors that seems to be mentioned in http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00661.html

It seems that some tests of configure which use sys/time.h and time.h
failed because time.h is included after sys/time.h (nt/inc/sys/time.h)
in conftest.
time.h should be included before nt/inc/sys/time.h when using MinGW64,
as commented in w32.c.

Re: MinGW64 (32bit) build with posix configure (Re: windows build failure)

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Cc: emacs-devel@gnu.org
> Date: Sat, 01 Jun 2013 03:00:09 +0900
> 
> Then, I changed gcc to MinGW64 gcc (32bit).
> I got some time-related errors that seems to be mentioned in http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00661.html

There are no error messages in that URL, only a vague reference to
"some" errors.  Could you please show the full messages with the
command lines that triggered them?  Please submit a bug report with
those details, as I would like to try to fix that.  I don't have
MinGW64 installed, so I depend on others to try that and report
problems.

> It seems that some tests of configure which use sys/time.h and time.h
> failed because time.h is included after sys/time.h (nt/inc/sys/time.h)
> in conftest.
> time.h should be included before nt/inc/sys/time.h when using MinGW64,
> as commented in w32.c.

Thanks for the heads-up, but I need to see the messages to decide what
is the best way of solving those problems.

Re: MinGW64 (32bit) build with posix configure (Re: windows build failure)

[rzl24ozi]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: rzl24ozi@gmail.com
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 01 Jun 2013 03:00:09 +0900
>> 
>> Then, I changed gcc to MinGW64 gcc (32bit).
>> I got some time-related errors that seems to be mentioned in
>> http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00661.html
>
> There are no error messages in that URL, only a vague reference to
> "some" errors.  Could you please show the full messages with the
> command lines that triggered them?  Please submit a bug report with
> those details, as I would like to try to fix that.  I don't have
> MinGW64 installed, so I depend on others to try that and report
> problems.

make.log and config.log for the reference are attached to this mail.

I don't know well how to submit a bug report. Use M-x report-emacs-bug ?


[-- Attachment #2: make.log.gz --]
[-- Type: application/octet-stream, Size: 1860 bytes --]

[-- Attachment #3: config.log.gz --]
[-- Type: application/octet-stream, Size: 49225 bytes --]

Re: MinGW64 (32bit) build with posix configure (Re: windows build failure)

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Cc: emacs-devel@gnu.org
> Date: Sat, 01 Jun 2013 09:52:56 +0900
> 
> make.log and config.log for the reference are attached to this mail.

Thanks, that clearly identifies the problem.  Please try again with
the latest trunk.

> I don't know well how to submit a bug report. Use M-x report-emacs-bug ?

Yes, exactly.

Re: MinGW64 (32bit) build with posix configure (Re: windows build failure)

[rzl24ozi]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: rzl24ozi@gmail.com
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 01 Jun 2013 09:52:56 +0900
>> 
>> make.log and config.log for the reference are attached to this mail.
>
> Thanks, that clearly identifies the problem.  Please try again with
> the latest trunk.

I tried but got another error...

>> I don't know well how to submit a bug report. Use M-x report-emacs-bug ?
>
> Yes, exactly.

I'll send a bug report. Thanks.

Re: windows build failure

[cg]

On 5/28/2013 12:36 AM, Eli Zaretskii wrote:
>> Date: Sun, 26 May 2013 16:29:36 -0400
>> From: Sean Sieger <sean.sieger@gmail.com>
>>
>> In file included from w32.c:33:0:
>> ../nt/inc/sys/time.h:41:62: error: conflicting types for 'restrict'
>> ../nt/inc/sys/time.h:41:35: note: previous definition of 'restrict' was here
>> make[3]: *** [oo-spd/i386/w32.o] Error 1
>> make[3]: Leaving directory `c:/trunk/src'
>> make[2]: *** [bootstrap-temacs-CMD] Error 2
>> make[2]: Leaving directory `c:/trunk/src'
>> make[1]: *** [bootstrap-temacs] Error 2
>> make[1]: Leaving directory `c:/trunk/src'
>> make: *** [bootstrap-gmake] Error 2
>
> Is this with today's bzr?  If so, what version of GCC is this, and
> what does the macro-expanded nt/inc/sys/time.h look like?
>
> I don't get this error.  Emacs builds for me on 2 different machines
> with 2 different GCC versions.
>

I got this compile error too, gcc version is 4.6.0 downloaded from
sourceforge.net.

The problem is gettimeofday (in time.h) has two arguments with
the same name 'restrict':

int gettimeofday (struct timeval *restrict, struct timezone *restrict);

just rename one of them, the error will be gone:

int gettimeofday (struct timeval *restrict, struct timezone *restrict2);

I don't know what C spec says about it.
--
cg

Re: windows build failure

[Eli Zaretskii]

> From: cg <chengang31@gmail.com>
> Date: Thu, 30 May 2013 00:06:56 +0800
> 
> The problem is gettimeofday (in time.h) has two arguments with
> the same name 'restrict':
> 
> int gettimeofday (struct timeval *restrict, struct timezone *restrict);

'restrict' is a keyword, not a variable.  Like 'static' or 'volatile'.