all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* windows build help
  2017-10-13 10:14               ` Andy Moreton
@ 2017-10-13 18:52                 ` Phillip Lord
  2017-10-13 19:36                   ` Óscar Fuentes
                                     ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Phillip Lord @ 2017-10-13 18:52 UTC (permalink / raw)
  To: Emacs-Devel devel



I was just reading 28601@debbugs.gnu.org. I have a slightly related
problem and wonder if anyone could help.

Currently, I am building the windows binaries for Emacs using an
out-of-source build with a directory structure like this:

git/emacs-26.0.50

build/emacs-26.0.50/x86_64
build/emacs-26.0.50/i686

install/emacs-26.0.50/x86_64
install/emacs-26.0.50/i686

This works nicely, but some of the process is manual. I wanted to script
everything up to and including the creation of the final zip files --
currently, the entire build takes about an hour or two.

But I do the x86_64 building using the MINGW64 shell
(i.e. C:\msys64\mingw64.exe) and the i686 using MINGW32
(i.e. C:\msys64\mingw64.exe). You might have thought I could just used
one -- the build for the i686 would just be cross compiling. But, this
doesn't work because I get this from ./configure:

checking for struct ifreq.ifr_addr.sa_len... no
checking whether gcc understands -MMD -MF... no
checking for long file names... yes
checking for X... no
checking whether Windows API headers are recent enough... no
configure: error: the Windows API headers are too old to support this build.

So, I cannot do both builds with a single command -- I have to come back
in the middle. I don't really understand the difference between the two
shells nor why I get this error.

Another solution would be to run both builds in parallel; this fails,
unfortunately, because the "out-of-source" build is not entirely out of
source -- the .elc files are created in-source. If I launch both a 64
and 32 bit build at the same time, they fight for whole compiles what,
until one or both crash.

It's not a major issue, but I'd quite like to start providing emacs-27
snapshots every couple of weeks. It's not going to happen, if it takes
too much effort.

Any thoughts welcome.

Phil



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
  2017-10-13 18:52                 ` windows build help Phillip Lord
@ 2017-10-13 19:36                   ` Óscar Fuentes
  2017-10-13 19:38                   ` Stephen Leake
  2017-10-13 19:47                   ` Noam Postavsky
  2 siblings, 0 replies; 15+ messages in thread
From: Óscar Fuentes @ 2017-10-13 19:36 UTC (permalink / raw)
  To: emacs-devel

phillip.lord@russet.org.uk (Phillip Lord) writes:

> So, I cannot do both builds with a single command -- I have to come back
> in the middle. I don't really understand the difference between the two
> shells nor why I get this error.

Look at the scripts that start each shell. They setup some environment
variables. Mimic that on your script and you should be fine.




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
  2017-10-13 18:52                 ` windows build help Phillip Lord
  2017-10-13 19:36                   ` Óscar Fuentes
@ 2017-10-13 19:38                   ` Stephen Leake
  2017-10-14 11:07                     ` Phillip Lord
  2017-10-13 19:47                   ` Noam Postavsky
  2 siblings, 1 reply; 15+ messages in thread
From: Stephen Leake @ 2017-10-13 19:38 UTC (permalink / raw)
  To: emacs-devel

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Another solution would be to run both builds in parallel; this fails,
> unfortunately, because the "out-of-source" build is not entirely out of
> source -- the .elc files are created in-source. If I launch both a 64
> and 32 bit build at the same time, they fight for whole compiles what,
> until one or both crash.

Have two source checkouts. then you could also build in-source, although
I doubt that makes much difference.


-- 
-- Stephe



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
  2017-10-13 18:52                 ` windows build help Phillip Lord
  2017-10-13 19:36                   ` Óscar Fuentes
  2017-10-13 19:38                   ` Stephen Leake
@ 2017-10-13 19:47                   ` Noam Postavsky
  2017-10-14 11:09                     ` Phillip Lord
  2 siblings, 1 reply; 15+ messages in thread
From: Noam Postavsky @ 2017-10-13 19:47 UTC (permalink / raw)
  To: Phillip Lord; +Cc: Emacs-Devel devel

On Fri, Oct 13, 2017 at 2:52 PM, Phillip Lord
<phillip.lord@russet.org.uk> wrote:

> But I do the x86_64 building using the MINGW64 shell
> (i.e. C:\msys64\mingw64.exe) and the i686 using MINGW32
> (i.e. C:\msys64\mingw64.exe). You might have thought I could just used
> one -- the build for the i686 would just be cross compiling.

AFAIK, emacs doesn't support cross compiling.

> So, I cannot do both builds with a single command -- I have to come back
> in the middle. I don't really understand the difference between the two
> shells nor why I get this error.

I think the only difference is PATH has /mingw32/bin or /mingw64/bin,
and MSYSTEM is MINGW32 or MINGW64

At least for me, after doing

PATH=/mingw32/bin:$PATH
MSYSTEM=MINGW32

in a mingw64 shell, doing ./configure succeeds and I end up with a 32bit emacs.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
@ 2017-10-14  8:16 Angelo Graziosi
  2017-10-14 11:16 ` Phillip Lord
  0 siblings, 1 reply; 15+ messages in thread
From: Angelo Graziosi @ 2017-10-14  8:16 UTC (permalink / raw)
  To: emacs-devel

Phillip Lord wrote:

> But I do the x86_64 building using the MINGW64 shell
> (i.e. C:\msys64\mingw64.exe) and the i686 using MINGW32

in my script I added this:

  MSYSTEM="MINGW64"
  PATH="/mingw64/bin:$PATH"

Also this should work:

  MSYSTEM=MINGW64 PATH="/mingw64/bin:$PATH" ~/emacs-w64-build.sh

> the entire build takes about an hour or two

On which machine? Here (an Athlon X2, 10 years old), with 'make -j3', the build [1] takes about 35-40 minutes [2].

Ciao,
 Angelo.


-----
[1] From http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-master.tar.gz
[2] Download of [1], unpacking, build, and tar.xz creation.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
  2017-10-13 19:38                   ` Stephen Leake
@ 2017-10-14 11:07                     ` Phillip Lord
  2017-10-14 15:15                       ` Stephen Leake
  0 siblings, 1 reply; 15+ messages in thread
From: Phillip Lord @ 2017-10-14 11:07 UTC (permalink / raw)
  To: Stephen Leake; +Cc: emacs-devel

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>> Another solution would be to run both builds in parallel; this fails,
>> unfortunately, because the "out-of-source" build is not entirely out of
>> source -- the .elc files are created in-source. If I launch both a 64
>> and 32 bit build at the same time, they fight for whole compiles what,
>> until one or both crash.
>
> Have two source checkouts. then you could also build in-source, although
> I doubt that makes much difference.

I thought about that, but the reason against it is that it takes much
longer, because I have to build the elc twice.

Phil



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
  2017-10-13 19:47                   ` Noam Postavsky
@ 2017-10-14 11:09                     ` Phillip Lord
  0 siblings, 0 replies; 15+ messages in thread
From: Phillip Lord @ 2017-10-14 11:09 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: Emacs-Devel devel

Noam Postavsky <npostavs@users.sourceforge.net> writes:

> On Fri, Oct 13, 2017 at 2:52 PM, Phillip Lord
> <phillip.lord@russet.org.uk> wrote:
>
>> But I do the x86_64 building using the MINGW64 shell
>> (i.e. C:\msys64\mingw64.exe) and the i686 using MINGW32
>> (i.e. C:\msys64\mingw64.exe). You might have thought I could just used
>> one -- the build for the i686 would just be cross compiling.
>
> AFAIK, emacs doesn't support cross compiling.

I assumed that only GCC needed to do this (assuming that the emacs
produced can run on the current system).

>
>> So, I cannot do both builds with a single command -- I have to come back
>> in the middle. I don't really understand the difference between the two
>> shells nor why I get this error.
>
> I think the only difference is PATH has /mingw32/bin or /mingw64/bin,
> and MSYSTEM is MINGW32 or MINGW64
>
> At least for me, after doing
>
> PATH=/mingw32/bin:$PATH
> MSYSTEM=MINGW32
>
> in a mingw64 shell, doing ./configure succeeds and I end up with a
> 32bit emacs.

Yep, that's all you need. Thank you very much!

Phil



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
  2017-10-14  8:16 windows build help Angelo Graziosi
@ 2017-10-14 11:16 ` Phillip Lord
  0 siblings, 0 replies; 15+ messages in thread
From: Phillip Lord @ 2017-10-14 11:16 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: emacs-devel

Angelo Graziosi <angelo.g0@libero.it> writes:

> Phillip Lord wrote:
>
>> But I do the x86_64 building using the MINGW64 shell
>> (i.e. C:\msys64\mingw64.exe) and the i686 using MINGW32
>
> in my script I added this:
>
>   MSYSTEM="MINGW64"
>   PATH="/mingw64/bin:$PATH"
>
> Also this should work:
>
>   MSYSTEM=MINGW64 PATH="/mingw64/bin:$PATH" ~/emacs-w64-build.sh
>
>> the entire build takes about an hour or two
>
> On which machine? Here (an Athlon X2, 10 years old), with 'make -j3',
> the build [1] takes about 35-40 minutes [2].

The majority of the time is the elc compilation. So, the first build
takes a long time, second much (much) less.

There is also quite a lot of baggage on top of this. After the zip files
have been build, I have to unzip them, so I check they run cleanly. This
takes around 5 minutes per zip. For Emacs-26, I'm making four zips. Then
the uploads. I normally do it over two days.

Phil




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
  2017-10-14 11:07                     ` Phillip Lord
@ 2017-10-14 15:15                       ` Stephen Leake
  2017-10-14 15:26                         ` Phillip Lord
                                           ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Stephen Leake @ 2017-10-14 15:15 UTC (permalink / raw)
  To: emacs-devel

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> phillip.lord@russet.org.uk (Phillip Lord) writes:
>>
>>> Another solution would be to run both builds in parallel; this fails,
>>> unfortunately, because the "out-of-source" build is not entirely out of
>>> source -- the .elc files are created in-source. If I launch both a 64
>>> and 32 bit build at the same time, they fight for whole compiles what,
>>> until one or both crash.
>>
>> Have two source checkouts. then you could also build in-source, although
>> I doubt that makes much difference.
>
> I thought about that, but the reason against it is that it takes much
> longer, because I have to build the elc twice.

Hmm. You are implying that the elc built for 32 bit emacs are identical
to the elc built for 64 bit emacs. 

Is that true? I would have guessed that most objects are either
32 bit or 64 bit; elisp manual 3.1 says the integer range depends on the
machine, and pointers should also.

If they are the same, then you should be able to write a script that
does:

1) parallel make to build elc using 32 bit
2) parallel make to build everything else, both 32 bit and 64 bit.

-- 
-- Stephe



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
  2017-10-14 15:15                       ` Stephen Leake
@ 2017-10-14 15:26                         ` Phillip Lord
  2017-10-14 15:31                         ` Eli Zaretskii
  2017-10-14 23:04                         ` Paul Eggert
  2 siblings, 0 replies; 15+ messages in thread
From: Phillip Lord @ 2017-10-14 15:26 UTC (permalink / raw)
  To: Stephen Leake; +Cc: emacs-devel

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>>
>>> phillip.lord@russet.org.uk (Phillip Lord) writes:
>>>
>>>> Another solution would be to run both builds in parallel; this fails,
>>>> unfortunately, because the "out-of-source" build is not entirely out of
>>>> source -- the .elc files are created in-source. If I launch both a 64
>>>> and 32 bit build at the same time, they fight for whole compiles what,
>>>> until one or both crash.
>>>
>>> Have two source checkouts. then you could also build in-source, although
>>> I doubt that makes much difference.
>>
>> I thought about that, but the reason against it is that it takes much
>> longer, because I have to build the elc twice.
>
> Hmm. You are implying that the elc built for 32 bit emacs are identical
> to the elc built for 64 bit emacs. 
>
> Is that true? I would have guessed that most objects are either
> 32 bit or 64 bit; elisp manual 3.1 says the integer range depends on the
> machine, and pointers should also.

Yes, I believe that they are. In fact, the source tar-ball includes the
ELC files, when it's possible to build from source on many different
platforms.

I use to build both 32 and 64 totally form source (i.e. without ELC),
but haven't done for I think all of Emacs-25.


> If they are the same, then you should be able to write a script that
> does:
>
> 1) parallel make to build elc using 32 bit
> 2) parallel make to build everything else, both 32 bit and 64 bit.

I have this now, thanks to comments in this thread. I do, parallel build
of 64 bit, then parallel build of 32 bit. The ELC build happens during
the 64, although it could happen either way.

Phil



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
  2017-10-14 15:15                       ` Stephen Leake
  2017-10-14 15:26                         ` Phillip Lord
@ 2017-10-14 15:31                         ` Eli Zaretskii
  2017-10-14 23:04                         ` Paul Eggert
  2 siblings, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2017-10-14 15:31 UTC (permalink / raw)
  To: Stephen Leake; +Cc: emacs-devel

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Sat, 14 Oct 2017 10:15:41 -0500
> 
> Hmm. You are implying that the elc built for 32 bit emacs are identical
> to the elc built for 64 bit emacs. 
> 
> Is that true?

Yes.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
  2017-10-14 15:15                       ` Stephen Leake
  2017-10-14 15:26                         ` Phillip Lord
  2017-10-14 15:31                         ` Eli Zaretskii
@ 2017-10-14 23:04                         ` Paul Eggert
  2017-10-16  1:53                           ` Richard Stallman
  2 siblings, 1 reply; 15+ messages in thread
From: Paul Eggert @ 2017-10-14 23:04 UTC (permalink / raw)
  To: Stephen Leake, emacs-devel

Stephen Leake wrote:
> You are implying that the elc built for 32 bit emacs are identical
> to the elc built for 64 bit emacs.

Although one can write Elisp code that compiles to different .elc files 
depending whether the compiling Emacs is built for a 32 or 64 bit machine, such 
Elisp code is unportable and the GNU Emacs source code does not do that, as far 
as I know. (It might be nice if we routinely tested for such portability bugs.)



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
  2017-10-14 23:04                         ` Paul Eggert
@ 2017-10-16  1:53                           ` Richard Stallman
  2017-10-16  6:49                             ` Paul Eggert
  0 siblings, 1 reply; 15+ messages in thread
From: Richard Stallman @ 2017-10-16  1:53 UTC (permalink / raw)
  To: Paul Eggert; +Cc: stephen_leake, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Although one can write Elisp code that compiles to different .elc files 
  > depending whether the compiling Emacs is built for a 32 or 64 bit machine, 

Just for curiosity's sake, would anyone like to tell me what circumstances
this happens in?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
  2017-10-16  1:53                           ` Richard Stallman
@ 2017-10-16  6:49                             ` Paul Eggert
  2017-10-16 13:54                               ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Paul Eggert @ 2017-10-16  6:49 UTC (permalink / raw)
  To: rms; +Cc: stephen_leake, emacs-devel

>    > one can write Elisp code that compiles to different .elc files
>    > depending whether the compiling Emacs is built for a 32 or 64 bit machine,
> 
> Just for curiosity's sake, would anyone like to tell me what circumstances
> this happens in?

For example, given this source code:

(defconst x (* 32768 32768))

On a 64-bit machine, byte-compiling generates an .elc file containing this:

(defconst x 1073741824)

On a 32-bit machine, byte-compiling the same source code generates an .elc file 
containing this instead:

(defconst x 0)

due to multiplication overflow in this Emacs's integers, which use 30-bit two's 
complement. Each .elc file is correct for the Emacs it is built with, but 
incorrect for the other Emacs.

GNU Emacs source code should not do this sort of thing, since the .elc files 
distributed in its tarballs are supposed to be portable.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: windows build help
  2017-10-16  6:49                             ` Paul Eggert
@ 2017-10-16 13:54                               ` Stefan Monnier
  0 siblings, 0 replies; 15+ messages in thread
From: Stefan Monnier @ 2017-10-16 13:54 UTC (permalink / raw)
  To: emacs-devel

> (defconst x (* 32768 32768))

Indeed.  This one is arguably undesirable.
But there are more direct ones, where you can't similarly argue that
it's a limitation in Elisp:

    (defconst foo-build-system (eval-when-compile system-configuration))


-- Stefan




^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2017-10-16 13:54 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-14  8:16 windows build help Angelo Graziosi
2017-10-14 11:16 ` Phillip Lord
  -- strict thread matches above, loose matches on Subject: below --
2017-09-25 20:02 bug#28601: 26.0.50; configure: error: Emacs does not support 'x86_64-pc-msys' systems Vincent Belaïche
2017-09-27 18:36 ` Glenn Morris
2017-09-27 19:07   ` Vincent Belaïche
2017-09-27 21:37     ` Glenn Morris
2017-09-28 13:10       ` Andy Moreton
2017-09-29  9:37         ` Eli Zaretskii
2017-10-12 23:06           ` Noam Postavsky
2017-10-13  6:41             ` Eli Zaretskii
2017-10-13 10:14               ` Andy Moreton
2017-10-13 18:52                 ` windows build help Phillip Lord
2017-10-13 19:36                   ` Óscar Fuentes
2017-10-13 19:38                   ` Stephen Leake
2017-10-14 11:07                     ` Phillip Lord
2017-10-14 15:15                       ` Stephen Leake
2017-10-14 15:26                         ` Phillip Lord
2017-10-14 15:31                         ` Eli Zaretskii
2017-10-14 23:04                         ` Paul Eggert
2017-10-16  1:53                           ` Richard Stallman
2017-10-16  6:49                             ` Paul Eggert
2017-10-16 13:54                               ` Stefan Monnier
2017-10-13 19:47                   ` Noam Postavsky
2017-10-14 11:09                     ` Phillip Lord

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.