cannot build on w32

cannot build on w32

[Sam Steingold]

this morning bzr pull.

$ ./configure.bat --no-debug --with-gcc --cflags
-IC:/gnu/gnuwin32/include --ldflags -LC:/gnu/gnuwin32/lib
--without-xpm
$ make bootstrap
gcc -I. -c  -mno-cygwin -mtune=pentium4 -O2
-IC:/gnu/gnuwin32/include -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc
-DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=500000 0 -o
oo-spd/i386/w32.o w32.c
w32.c: In function `check_windows_init_file':
w32.c:5659: error: conflicting types for 'globals'
globals.h:1700: error: previous declaration of 'globals' was here
w32.c:5659: error: parse error before '.' token
w32.c:5665: error: request for member `f_Vload_path' in something not
a structure or union
make[2]: *** [oo-spd/i386/w32.o] Error 1

-- 
Sam Steingold <http://sds.podval.org>

Re: cannot build on w32

[Tom Tromey]

>>>>> "Sam" == Sam Steingold <sds@gnu.org> writes:

Sam> w32.c: In function `check_windows_init_file':
Sam> w32.c:5659: error: conflicting types for 'globals'
Sam> globals.h:1700: error: previous declaration of 'globals' was here
Sam> w32.c:5659: error: parse error before '.' token
Sam> w32.c:5665: error: request for member `f_Vload_path' in something not
Sam> a structure or union

Sorry about that.  Could you try the appended?
If it works for you I will check it in.

Tom

=== modified file 'src/w32.c'
--- src/w32.c	2011-01-18 20:45:37 +0000
+++ src/w32.c	2011-01-19 15:22:40 +0000
@@ -5656,7 +5656,7 @@
 
   if (!noninteractive && !inhibit_window_system)
     {
-      extern Lisp_Object Vwindow_system, Vload_path, Qfile_exists_p;
+      extern Lisp_Object Vwindow_system, Qfile_exists_p;
       Lisp_Object objs[2];
       Lisp_Object full_load_path;
       Lisp_Object init_file;

Re: cannot build on w32

[Sam Steingold]

On Wed, Jan 19, 2011 at 10:18 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Sam" == Sam Steingold <sds@gnu.org> writes:
>
> Sam> w32.c: In function `check_windows_init_file':
> Sam> w32.c:5659: error: conflicting types for 'globals'
> Sam> globals.h:1700: error: previous declaration of 'globals' was here
> Sam> w32.c:5659: error: parse error before '.' token
> Sam> w32.c:5665: error: request for member `f_Vload_path' in something not
> Sam> a structure or union
>
> Sorry about that.  Could you try the appended?
> If it works for you I will check it in.

thanks, I already committed a slightly more radical fix :-)

however, I now get a more insurmountable problem:

"make bootstrap" dies with:

gcc -I. -c  -mno-cygwin -mtune=pentium4 -O2
-IC:/gnu/gnuwin32/include -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc
-DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o
oo-spd/i386/print.o print.c
print.c:53:21: ftoastr.h: No such file or directory
make[2]: *** [oo-spd/i386/print.o] Error 1

even though the above gcc command succeeds in src and lib/ftoastr.h is present.

-- 
Sam Steingold <http://sds.podval.org>

Re: cannot build on w32

[Sam Steingold]

On Wed, Jan 19, 2011 at 10:33 AM, Sam Steingold <sds@gnu.org> wrote:
> however, I now get a more insurmountable problem:
>
> "make bootstrap" dies with:
>
> gcc -I. -c  -mno-cygwin -mtune=pentium4 -O2
> -IC:/gnu/gnuwin32/include -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc
> -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o
> oo-spd/i386/print.o print.c
> print.c:53:21: ftoastr.h: No such file or directory
> make[2]: *** [oo-spd/i386/print.o] Error 1
>
> even though the above gcc command succeeds in src and lib/ftoastr.h is present.

I worked around this by adding -I../lib to CFLAGS in src/makefile
which is, obviously, not trt.


BTW, retrying "make bootstrap" is very frustrating (it's a quadratic process!)


-- 
Sam Steingold <http://sds.podval.org>

Re: cannot build on w32

[Eli Zaretskii]

> Date: Wed, 19 Jan 2011 10:53:28 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> On Wed, Jan 19, 2011 at 10:33 AM, Sam Steingold <sds@gnu.org> wrote:
> > however, I now get a more insurmountable problem:
> >
> > "make bootstrap" dies with:
> >
> > gcc -I. -c  -mno-cygwin -mtune=pentium4 -O2
> > -IC:/gnu/gnuwin32/include -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc
> > -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o
> > oo-spd/i386/print.o print.c
> > print.c:53:21: ftoastr.h: No such file or directory
> > make[2]: *** [oo-spd/i386/print.o] Error 1
> >
> > even though the above gcc command succeeds in src and lib/ftoastr.h is present.
> 
> I worked around this by adding -I../lib to CFLAGS in src/makefile
> which is, obviously, not trt.

The w32 build is currently broken, since addition of files from gnulib
and the change of directory structure that involved were not accounted
for in the Windows makefiles.  If you can fix that the right way,
please do; if not, someone else will in a few days.

> BTW, retrying "make bootstrap" is very frustrating (it's a quadratic process!)

You shouldn't need to say "make bootstrap" after the the first such
command fails.  Just "make" should do.  (But I only tried that on
GNU/Linux, so perhaps there's some bug in the Windows build procedure
that breaks this.)

Re: cannot build on w32

[Sam Steingold]

On Wed, Jan 19, 2011 at 11:03 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> BTW, retrying "make bootstrap" is very frustrating (it's a quadratic process!)
>
> You shouldn't need to say "make bootstrap" after the the first such
> command fails.  Just "make" should do.  (But I only tried that on
> GNU/Linux, so perhaps there's some bug in the Windows build procedure
> that breaks this.)

$ make
[Please ignore a syntax error on the next line - it is intentional]
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
Using /bin/sh as shell.

Essential Lisp files seem to be missing.  You should either
do `make bootstrap' or create `lisp/abbrev.elc' somehow.

make: *** [maybe-bootstrap-SH] Error 255


-- 
Sam Steingold <http://sds.podval.org>

Re: cannot build on w32

[Eli Zaretskii]

> Date: Wed, 19 Jan 2011 11:14:22 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Essential Lisp files seem to be missing.  You should either
> do `make bootstrap' or create `lisp/abbrev.elc' somehow.
> 
> make: *** [maybe-bootstrap-SH] Error 255

What happens once you do have lisp/abbrev.elc?

Re: cannot build on w32

[Sam Steingold]

Aha!
the problem is that now emacs uses some gnulib modules and their
building and use are not integrated into the emacs w32 build system
(configure.bat &c). e.gl., there is no makefile.w32-in in src/lib.

fwiw, I use gnulib modules in clisp on both windows and unix and I use
the same autoconf-created configure files on unix and windows alike
identically.
(except that I to "./configure CC='gcc -mno-cygwin'" on win32).
this saves me an extra effort of maintaining a separate build system on windows.


On Wed, Jan 19, 2011 at 10:53 AM, Sam Steingold <sds@gnu.org> wrote:
> On Wed, Jan 19, 2011 at 10:33 AM, Sam Steingold <sds@gnu.org> wrote:
>> however, I now get a more insurmountable problem:
>>
>> "make bootstrap" dies with:
>>
>> gcc -I. -c  -mno-cygwin -mtune=pentium4 -O2
>> -IC:/gnu/gnuwin32/include -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc
>> -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o
>> oo-spd/i386/print.o print.c
>> print.c:53:21: ftoastr.h: No such file or directory
>> make[2]: *** [oo-spd/i386/print.o] Error 1
>>
>> even though the above gcc command succeeds in src and lib/ftoastr.h is present.
>
> I worked around this by adding -I../lib to CFLAGS in src/makefile
> which is, obviously, not trt.
>
>
> BTW, retrying "make bootstrap" is very frustrating (it's a quadratic process!)
>
>
> --
> Sam Steingold <http://sds.podval.org>
>



-- 
Sam Steingold <http://sds.podval.org>

Re: cannot build on w32

[Eli Zaretskii]

> Date: Wed, 19 Jan 2011 11:05:26 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> fwiw, I use gnulib modules in clisp on both windows and unix and I use
> the same autoconf-created configure files on unix and windows alike
> identically.
> (except that I to "./configure CC='gcc -mno-cygwin'" on win32).
> this saves me an extra effort of maintaining a separate build system on windows.

Sorry, requiring Emacs users on Windows install Cygwin just to build
Emacs is out of question.  (And for building on a single platform,
autoconf is overkill anyway, IMO.)

Re: cannot build on w32

[Sam Steingold]

On Wed, Jan 19, 2011 at 11:09 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 19 Jan 2011 11:05:26 -0500
>> From: Sam Steingold <sds@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>> fwiw, I use gnulib modules in clisp on both windows and unix and I use
>> the same autoconf-created configure files on unix and windows alike
>> identically.
>> (except that I to "./configure CC='gcc -mno-cygwin'" on win32).
>> this saves me an extra effort of maintaining a separate build system on windows.
>
> Sorry, requiring Emacs users on Windows install Cygwin just to build
> Emacs is out of question.

1. you don't need cygwin, just mingw.
2. people who _build_ emacs themselves usually already have cygwin

> (And for building on a single platform, autoconf is overkill anyway, IMO.)

that's what autoconf is for: so that you do not have to have a
separate build systems for various platforms.
it is weird to use autoconf for some platforms but not others.

-- 
Sam Steingold <http://sds.podval.org>

Re: cannot build on w32

[Eli Zaretskii]

> Date: Wed, 19 Jan 2011 11:16:52 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > Sorry, requiring Emacs users on Windows install Cygwin just to build
> > Emacs is out of question.
> 
> 1. you don't need cygwin, just mingw.

You mean, MSYS?  That's Cygwin in disguise, and buggy.

> 2. people who _build_ emacs themselves usually already have cygwin

Not all of them do.  I don't, for example.

> > (And for building on a single platform, autoconf is overkill anyway, IMO.)
> 
> that's what autoconf is for: so that you do not have to have a
> separate build systems for various platforms.

As the recent bugs with introducing gnulib show, autoconf is not a
panacea: when used on a platform that's radically different from the
one where a change was tested, using autoconf does not promise
success.

Anyway, let's not beat a dead horse.  The Windows build support might
have needed a lot of work when it was originally done, but lately it
only requires minimal efforts.  This case is a very rare exception,
and it broke other platforms, not only Windows.  So I would certainly
not draw any radical conclusions from it.

Re: cannot build on w32

[Sam Steingold]

On Wed, Jan 19, 2011 at 11:39 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 19 Jan 2011 11:16:52 -0500
>> From: Sam Steingold <sds@gnu.org>
>
>> 2. people who _build_ emacs themselves usually already have cygwin
> Not all of them do.  I don't, for example.

yes, and rms does not use browsers. so? :-)

>> > (And for building on a single platform, autoconf is overkill anyway, IMO.)
>>
>> that's what autoconf is for: so that you do not have to have a
>> separate build systems for various platforms.
>
> As the recent bugs with introducing gnulib show, autoconf is not a
> panacea: when used on a platform that's radically different from the
> one where a change was tested, using autoconf does not promise
> success.

I think you got it exactly wrong.
autoconf - when used on _all_ platforms - is the solution.
the _problem_ is that it is not used on on some platforms (win32) and
this is why emacs does not build on windows now.
if autoconf were used on windows, emacs would have built ootb.

at any rate, you are the maintainer of emacs on window, and this
decision is up to you.
since you are dead set against using unix tools (cygwin et al), we
will be stuck with configure.bat for the foreseeable future.
I am not complaining, of course...
-- 
Sam Steingold <http://sds.podval.org>

Re: cannot build on w32

[Jan Djärv]

Sam Steingold skrev 2011-01-19 18.36:

> I think you got it exactly wrong.
> autoconf - when used on _all_ platforms - is the solution.
> the _problem_ is that it is not used on on some platforms (win32) and
> this is why emacs does not build on windows now.
> if autoconf were used on windows, emacs would have built ootb.

OSX uses autoconf and doesn't build right now...

	Jan D.

Re: cannot build on w32

[Sam Steingold]

On Wed, Jan 19, 2011 at 2:01 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Sam Steingold skrev 2011-01-19 18.36:
>
>> I think you got it exactly wrong.
>> autoconf - when used on _all_ platforms - is the solution.
>> the _problem_ is that it is not used on some platforms (win32) and
>> this is why emacs does not build on windows now.
>> if autoconf were used on windows, emacs would have built ootb.
>
> OSX uses autoconf and doesn't build right now...

it's not enough to have a magic bullet - you also have to know how to use it :-)
(in this particular case - switching to gnulib is a non-trivial step,
so some breakage is nigh inevitable).

PS. Don't get me wrong: I am no expert in (and no fan of!) autoconf
(and cygwin - hi, Eli!).
It's merely a useful tool which made the pain of supporting clisp on
windows tolerable.

-- 
Sam Steingold <http://sds.podval.org>

Re: cannot build on w32

[Eli Zaretskii]

> Date: Thu, 20 Jan 2011 10:17:55 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> > OSX uses autoconf and doesn't build right now...
> 
> it's not enough to have a magic bullet - you also have to know how to use it :-)
> (in this particular case - switching to gnulib is a non-trivial step,
> so some breakage is nigh inevitable).

Exactly my point: with such a non-trivial step, the fact that the w32
build is broken does not mean we should conclude that the Windows port
cannot be reasonably maintained without using autoconf.

Re: cannot build on w32

[Sam Steingold]

On Thu, Jan 20, 2011 at 10:27 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 20 Jan 2011 10:17:55 -0500
>> From: Sam Steingold <sds@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>>
>> > OSX uses autoconf and doesn't build right now...
>>
>> it's not enough to have a magic bullet - you also have to know how to use it :-)
>> (in this particular case - switching to gnulib is a non-trivial step,
>> so some breakage is nigh inevitable).
>
> Exactly my point: with such a non-trivial step, the fact that the w32
> build is broken does not mean we should conclude that the Windows port
> cannot be reasonably maintained without using autoconf.

Agreed.
However, it is a very good point in time to revisit the option of
using autoconf on windows.

-- 
Sam Steingold <http://sds.podval.org>

Re: cannot build on w32

[Richard Stallman]

    yes, and rms does not use browsers. so? :-)

That is not quite accurate -- the situation is complicated.
Explaining it would be a digression so I won't.
I just don't want the incorrect info to circulate.

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: cannot build on w32

[Sam Steingold]

On Thu, Jan 20, 2011 at 9:12 AM, Richard Stallman <rms@gnu.org> wrote:
>    yes, and rms does not use browsers. so? :-)
>
> That is not quite accurate -- the situation is complicated.

the statement is accurate enough  to illustrate my point.
The fact that a few important individuals shun certain mainstream
technologies should not mean that those technologies should not be
relied upon by others.


-- 
Sam Steingold <http://sds.podval.org>

Re: cannot build on w32

[Eli Zaretskii]

> Date: Thu, 20 Jan 2011 09:50:40 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> 
> The fact that a few important individuals shun certain mainstream
> technologies should not mean that those technologies should not be
> relied upon by others.

Cygwin is not technology, let alone a leading one.

Re: cannot build on w32

[Richard Stallman]

    The fact that a few important individuals shun certain mainstream
    technologies

I do not shun browsers.  I do use them, but only in certain situations.

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: cannot build on w32

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry, requiring Emacs users on Windows install Cygwin just to build
> Emacs is out of question.  (And for building on a single platform,
> autoconf is overkill anyway, IMO.)

What about MSYS? Nowadays installing mingw+MSYS may be faster than
installing mingw and the required utilities (cp etc). Apparently there
is a nifty installer that brings to you a working gcc and MSYS with just
a command:

http://mingw.org/wiki/Getting_Started

Re: cannot build on w32

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: Sam Steingold <sds@gnu.org>,  tromey@redhat.com,  emacs-devel@gnu.org
> Date: Wed, 19 Jan 2011 17:21:37 +0100
> 
> What about MSYS? Nowadays installing mingw+MSYS may be faster than
> installing mingw and the required utilities (cp etc). Apparently there
> is a nifty installer that brings to you a working gcc and MSYS with just
> a command:
> 
> http://mingw.org/wiki/Getting_Started

I won't touch MSYS with a 3-mile stick.  It's a fork of Cygwin, and
adds its own bugs and idiosyncrasies.  We've been through this more
than once.

Re: cannot build on w32

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> What about MSYS? Nowadays installing mingw+MSYS may be faster than
>> installing mingw and the required utilities (cp etc). Apparently there
>> is a nifty installer that brings to you a working gcc and MSYS with just
>> a command:
>> 
>> http://mingw.org/wiki/Getting_Started
>
> I won't touch MSYS with a 3-mile stick.  It's a fork of Cygwin, and
> adds its own bugs and idiosyncrasies.  We've been through this more
> than once.

Although MSYS is not perfect, it works fine on my experience for its
purpose: running configure scripts and makefiles. It is not something
you add to your PATH. Just open a terminal window, configure&&make,
done.

Obviously some changes are required for building native Windows
executables with Emacs' scripts and makefiles, but looking at past
experience with other projects, that is simpler than maintaining a
parallel system.

No, I'm not volunteering. I know nothing about autoconf. Some time ago I
volunteered to create a new build system based on CMake, at least for
replacing the Windows one, and it was dismissed as unnecessary.

Re: cannot build on w32

[Andreas Schwab]

Tom Tromey <tromey@redhat.com> writes:

> @@ -5656,7 +5656,7 @@
>  
>    if (!noninteractive && !inhibit_window_system)
>      {
> -      extern Lisp_Object Vwindow_system, Vload_path, Qfile_exists_p;
> +      extern Lisp_Object Vwindow_system, Qfile_exists_p;

External declarations should never occur at the block level, only in
headers.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: cannot build on w32

[Tom Tromey]

>>>>> "Andreas" == Andreas Schwab <schwab@linux-m68k.org> writes:

Andreas> External declarations should never occur at the block level, only in
Andreas> headers.

I agree, but I don't plan to fix that universally in Emacs.  I wasn't
sure that this was the rule in Emacs, so I tried to make the minimal
change needed for my project.

Tom