Building Emacs with GnuTLS on Windows

Building Emacs with GnuTLS on Windows

[Deniz Dogan]

I'm trying to figure out how to build Emacs on Windows with the latest trunk.

c:\repos\emacs-trunk\nt>configure.bat --without-png --without-jpeg
--without-gif --without-tiff --without-xpm --prefix=C:\emacs
--cflags="-IC:/gnutls/include" --lib=C:/gnutls/lib --lib=C:/gnutls/bin
 extrauserlibs:
 extrauserlibs: C:/gnutls/lib
Checking for 'cp'...
Checking for 'rm'...
Checking whether 'gcc' is available...
Checking whether gcc requires '-mno-cygwin'...
Checking whether W32 API headers are too old...

c:\repos\emacs-trunk\nt>gcc -IC:/gnutls/include -c junk.c
Using 'gcc'
Checking for libgnutls...
...GNUTLS header available, building with GNUTLS support.
Generating makefiles
        1 file(s) copied.
config.settings
gmake.defs
..\nt\makefile.w32-in
        1 file(s) copied.
config.settings
gmake.defs
..\admin\unidata\makefile.w32-in
        1 file(s) copied.
config.settings
gmake.defs
..\lib-src\makefile.w32-in
        1 file(s) copied.
config.settings
gmake.defs
..\lib\makefile.w32-in
        1 file(s) copied.
config.settings
gmake.defs
..\src\makefile.w32-in
        1 file(s) copied.
config.settings
gmake.defs
..\doc\emacs\makefile.w32-in
        1 file(s) copied.
config.settings
gmake.defs
..\doc\misc\makefile.w32-in
        1 file(s) copied.
config.settings
gmake.defs
..\doc\lispref\makefile.w32-in
        1 file(s) copied.
config.settings
gmake.defs
..\doc\lispintro\makefile.w32-in
        1 file(s) copied.
config.settings
gmake.defs
..\lisp\makefile.w32-in
        1 file(s) copied.
config.settings
gmake.defs
..\leim\makefile.w32-in
        1 file(s) copied.

Emacs successfully configured.
Run `make' to build, then run `make install' to install.
c:\repos\emacs-trunk\nt>make
makefile:161: *** separator saknas.  Stannar.

The last part means "separator missing. Stopping." This is the latest
commit in the log:

revno: 104031
committer: Eli Zaretskii <eliz@gnu.org>
branch nick: trunk
timestamp: Thu 2011-04-28 00:14:34 +0300
message:
  Support inttypes.h and strtoumax in non-MinGW builds on Windows.

   nt/inc/inttypes.h: New file.
   nt/config.nt (HAVE_DECL_STRTOULL, HAVE_DECL_STRTOUMAX)
   (HAVE_STRTOULL, HAVE_STRTOUMAX): New macros.

I'm reluctant to post this to emacs-devel as I'm not sure it's my
fault, but I get the feeling that the recent changes to the quoting
and GnuTLS for Windows introduced this problem.

-- 
Deniz Dogan

Re: Building Emacs with GnuTLS on Windows

[Eli Zaretskii]

> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
> Date: Wed, 27 Apr 2011 23:55:51 +0200
> 
> c:\repos\emacs-trunk\nt>make
> makefile:161: *** separator saknas.  Stannar.
> 
> The last part means "separator missing. Stopping."

Please show line 161 of that makefile.  Also, does it work if you
configure --without-gnutls?

> This is the latest commit in the log:
> 
> revno: 104031
> committer: Eli Zaretskii <eliz@gnu.org>
> branch nick: trunk
> timestamp: Thu 2011-04-28 00:14:34 +0300
> message:
>   Support inttypes.h and strtoumax in non-MinGW builds on Windows.

This commit didn't change any Makefile-related files, at least I don't
think so.

> I'm reluctant to post this to emacs-devel as I'm not sure it's my
> fault

Anyone could make a mistake, so posting to emacs-devel is still TRT.

Re: Building Emacs with GnuTLS on Windows

[Deniz Dogan]

2011/4/28 Eli Zaretskii <eliz@gnu.org>:
>> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
>> Date: Wed, 27 Apr 2011 23:55:51 +0200
>>
>> c:\repos\emacs-trunk\nt>make
>> makefile:161: *** separator saknas.  Stannar.
>>
>> The last part means "separator missing. Stopping."
>
> Please show line 161 of that makefile.  Also, does it work if you
> configure --without-gnutls?
>

Line 161:
error Unknown architecture type "$(PROCESSOR_ARCHITECTURE)"

I'm afraid it doesn't work even if I pass --without-gnutls.

>> This is the latest commit in the log:
>>
>> revno: 104031
>> committer: Eli Zaretskii <eliz@gnu.org>
>> branch nick: trunk
>> timestamp: Thu 2011-04-28 00:14:34 +0300
>> message:
>>   Support inttypes.h and strtoumax in non-MinGW builds on Windows.
>
> This commit didn't change any Makefile-related files, at least I don't
> think so.
>

I didn't mean that, I just wanted to make sure everyone knew what
version I was using.

Thanks,
Deniz Dogan

Re: Building Emacs with GnuTLS on Windows

[Deniz Dogan]

2011/4/28 Deniz Dogan <deniz.a.m.dogan@gmail.com>:
> I didn't mean that, I just wanted to make sure everyone knew what
> version I was using.
>

And for what it's worth, I just pulled in rev 104035 which has some
makefile changes but it still doesn't work.

Re: Building Emacs with GnuTLS on Windows

[Eli Zaretskii]

> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
> Date: Thu, 28 Apr 2011 09:09:50 +0200
> Cc: help-gnu-emacs@gnu.org
> 
> 2011/4/28 Eli Zaretskii <eliz@gnu.org>:
> >> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
> >> Date: Wed, 27 Apr 2011 23:55:51 +0200
> >>
> >> c:\repos\emacs-trunk\nt>make
> >> makefile:161: *** separator saknas.  Stannar.
> >>
> >> The last part means "separator missing. Stopping."
> >
> > Please show line 161 of that makefile.  Also, does it work if you
> > configure --without-gnutls?
> >
> 
> Line 161:
> error Unknown architecture type "$(PROCESSOR_ARCHITECTURE)"

Weird.  What does the command below display if you type it from the
shell prompt in the same window where you invoked `make':

   set PROCESSOR_ARCHITECTURE

(If your shell is a Unixy shell, use the corresponding Unix shell
format; the above is for cmd.exe.)

Also, what does "make --version" display?  Is it a GNU Make?

Re: Building Emacs with GnuTLS on Windows

[Deniz Dogan]

2011/4/28 Eli Zaretskii <eliz@gnu.org>:
>> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
>> Date: Thu, 28 Apr 2011 09:09:50 +0200
>> Cc: help-gnu-emacs@gnu.org
>>
>> 2011/4/28 Eli Zaretskii <eliz@gnu.org>:
>> >> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
>> >> Date: Wed, 27 Apr 2011 23:55:51 +0200
>> >>
>> >> c:\repos\emacs-trunk\nt>make
>> >> makefile:161: *** separator saknas.  Stannar.
>> >>
>> >> The last part means "separator missing. Stopping."
>> >
>> > Please show line 161 of that makefile.  Also, does it work if you
>> > configure --without-gnutls?
>> >
>>
>> Line 161:
>> error Unknown architecture type "$(PROCESSOR_ARCHITECTURE)"
>
> Weird.  What does the command below display if you type it from the
> shell prompt in the same window where you invoked `make':
>
>   set PROCESSOR_ARCHITECTURE
>

Actually, the problem has gone away now after pulling in the most
recent changes.

Anyways, in case you want to know:
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=AMD64 Family 16 Model 4 Stepping 3, AuthenticAMD
PROCESSOR_LEVEL=16
PROCESSOR_REVISION=0403

> (If your shell is a Unixy shell, use the corresponding Unix shell
> format; the above is for cmd.exe.)
>
> Also, what does "make --version" display?  Is it a GNU Make?
>

Yes, I was using GNU Make.

-- 
Deniz Dogan

Re: Building Emacs with GnuTLS on Windows

[Eli Zaretskii]

> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
> Date: Thu, 28 Apr 2011 20:40:03 +0200
> Cc: help-gnu-emacs@gnu.org
> 
> >> Line 161:
> >> error Unknown architecture type "$(PROCESSOR_ARCHITECTURE)"
> >
> > Weird.  What does the command below display if you type it from the
> > shell prompt in the same window where you invoked `make':
> >
> >   set PROCESSOR_ARCHITECTURE
> >
> 
> Actually, the problem has gone away now after pulling in the most
> recent changes.
> 
> Anyways, in case you want to know:
> PROCESSOR_ARCHITECTURE=AMD64

How could it have gone, if AMD64 is not covered by nt/gmake.defs?  I
don't see any changes committed lately that could have fixed that.

Can you add an $(info) line or something similar to nt/makefile to see
what value of PROCESSOR_ARCHITECTURE does Make see?

Re: Building Emacs with GnuTLS on Windows

[Eli Zaretskii]

> Date: Thu, 28 Apr 2011 23:22:01 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
> > Date: Thu, 28 Apr 2011 20:40:03 +0200
> > Cc: help-gnu-emacs@gnu.org
> > 
> > >> Line 161:
> > >> error Unknown architecture type "$(PROCESSOR_ARCHITECTURE)"
> > >
> > > Weird.  What does the command below display if you type it from the
> > > shell prompt in the same window where you invoked `make':
> > >
> > >   set PROCESSOR_ARCHITECTURE
> > >
> > 
> > Actually, the problem has gone away now after pulling in the most
> > recent changes.
> > 
> > Anyways, in case you want to know:
> > PROCESSOR_ARCHITECTURE=AMD64
> 
> How could it have gone, if AMD64 is not covered by nt/gmake.defs?  I
> don't see any changes committed lately that could have fixed that.

This MSDN page:

  http://msdn.microsoft.com/en-us/library/aa384274(v=vs.85).aspx

gives a clue: when a 32-process runs on 64-bit Windows, Windows
"fixes" its environment such that PROCESSOR_ARCHITECTURE gets the
value "x86" expected by 32-bit Windows processes.

So the question now becomes: how come GNU Make, which is supposed to
be a 32-bit executable, got a value that is not x86?  What did you do
differently at those previous attempts to build Emacs?

Re: Building Emacs with GnuTLS on Windows

[Deniz Dogan]

2011/4/28 Eli Zaretskii <eliz@gnu.org>:
>> Date: Thu, 28 Apr 2011 23:22:01 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>>
>> > From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
>> > Date: Thu, 28 Apr 2011 20:40:03 +0200
>> > Cc: help-gnu-emacs@gnu.org
>> >
>> > >> Line 161:
>> > >> error Unknown architecture type "$(PROCESSOR_ARCHITECTURE)"
>> > >
>> > > Weird.  What does the command below display if you type it from the
>> > > shell prompt in the same window where you invoked `make':
>> > >
>> > >   set PROCESSOR_ARCHITECTURE
>> > >
>> >
>> > Actually, the problem has gone away now after pulling in the most
>> > recent changes.
>> >
>> > Anyways, in case you want to know:
>> > PROCESSOR_ARCHITECTURE=AMD64
>>
>> How could it have gone, if AMD64 is not covered by nt/gmake.defs?  I
>> don't see any changes committed lately that could have fixed that.
>
> This MSDN page:
>
>  http://msdn.microsoft.com/en-us/library/aa384274(v=vs.85).aspx
>
> gives a clue: when a 32-process runs on 64-bit Windows, Windows
> "fixes" its environment such that PROCESSOR_ARCHITECTURE gets the
> value "x86" expected by 32-bit Windows processes.
>
> So the question now becomes: how come GNU Make, which is supposed to
> be a 32-bit executable, got a value that is not x86?  What did you do
> differently at those previous attempts to build Emacs?
>

I didn't think that PROCESSOR_ARCHITECTURE would change after
configuring/making, so the results I got last time were from a "clean"
cmd.exe.  Sorry about that.  The "real" value is x86.

However, I'm having even more problems.  This time, when I bootstrap I get this:

c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe:
cannot find -lC:/gnutls/lib
c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe:
cannot find -lC:/gnutls/bin
collect2: ld returned 1 exit status
make[2]: *** [oo-spd/i386/temacs.exe] Fel 1
make[2]: Leaving directory `c:/repos/emacs-trunk/src'
make[1]: *** [bootstrap-temacs] Fel 2
make[1]: Leaving directory `c:/repos/emacs-trunk/src'
make: *** [bootstrap-gmake] Fel 2


Any ideas?

-- 
Deniz Dogan

Re: Building Emacs with GnuTLS on Windows

[Eli Zaretskii]

> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
> Date: Fri, 29 Apr 2011 10:10:19 +0200
> Cc: help-gnu-emacs@gnu.org
> 
> I didn't think that PROCESSOR_ARCHITECTURE would change after
> configuring/making, so the results I got last time were from a "clean"
> cmd.exe.  Sorry about that.  The "real" value is x86.

Sorry, I still don't understand.  PROCESSOR_ARCHITECTURE doesn't
change after configuring/making, it's just that make.exe, as a 32-bit
application running on a 64-bit Windows, should see the x86 value in
that environment variable.  Windows itself takes care of that when it
constructs the environment passed to make.exe.  And since Make
automatically converts all the environment variables into Make
variables available in the Makefile, the test before line 161 should
have succeeded to detect your architecture as "x86".  Which part of
this didn't work, and why?

And what does "a clean cmd.exe" mean, anyway?

In sum, I'm still unsure how that problem happened to you and what
solved it.  I need to determine whether there's some general problem
in the Windows configury that rears its ugly head on a 64-bit Windows,
or maybe it was due to some one-time local cockpit error on your side.
Please help me understand which one is it.  If it's your local error,
please explain what did you do differently during the botched
bootstrap.  Maybe you need to try a clean bootstrap again in a fresh
tree, to reproduce the problem?

If you do succeed in reproducing it, please don't update from the
repository until we understand the reason(s), because new changes can
obscure the original problem.

TIA

> However, I'm having even more problems.  This time, when I bootstrap I get this:
> 
> c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe:
> cannot find -lC:/gnutls/lib
> c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe:
> cannot find -lC:/gnutls/bin

That's because your configure arguments are incorrect:

> c:\repos\emacs-trunk\nt>configure.bat --without-png --without-jpeg
> --without-gif --without-tiff --without-xpm --prefix=C:\emacs
> --cflags="-IC:/gnutls/include" --lib=C:/gnutls/lib --lib=C:/gnutls/bin
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The --lib switch tells the compiler the _names_of_the_libraries_ it
needs to link in, not the directory where to find those libraries.
You need to use

   --ldflags=-LC:/gnutls/lib --ldflags=-LC:/gnutls/bin

instead (note: upper-case "L").  I believe the Windows configury
already knows the names of the gnutls libraries in those directories,
so you don't need to use the --lib switches in this case.

Btw, why do you make your life harder by installing support libraries
outside the main MinGW include/, lib/ and bin/ directories?  That just
doesn't make any sense: once you have these libraries installed, they
should be available to any build of any program you compile with
MinGW, without any futzing with the -I or -L compiler switches.
Install them in the standard places, and you will never again need to
use these tricksy --cflags, --ldflags etc. switches, ever.