GNU bug report logs - #13479
Cross Compiling for ARM

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13479 in the body.
You can then email your comments to 13479 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ross Biro <ross.biro <at> mindspring.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Cross Compiling for ARM
Date: Thu, 17 Jan 2013 14:36:08 -0500

[Message part 1 (text/plain, inline)]

I just more or less successfully compiled emacs-24.2 for a Samsung
Chromebook.  I did it by using the chrooted build environment for
chromiumos.  In the process I learned a couple of things.

I used the configuration:

../emacs-24.2/configure  --build=x86_64-pc-linux-gnu
--host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi
--with-x-toolkit=no --with-xpm=no --with-jpeg=no --with-png=no
--with-gif=no --with-tiff=no  --without-xml2 --without-gnutls --without-x
--without-dbus --with-crt-dir=/build/arm-generic/usr/lib/

Obviously, I also had to CANNOT_DUMP=yes as well.

1) It doesn't look like emacs has a concept of a BUILDCC.  I like to set CC
to the cross compiler since that seems to be what most things need.
However make-docfile and test-distrib need to be built with the local
compiler.  Usually the path to the local compiler is stored in BUILDCC.  I
just changed the $(CC) to $(BUILDCC) in the makefile for those two file and
everything compiled ok.

2) The lisp and leim directories really want a local copy of emacs to
compile.  Since I didn't have one available in the chrooted environment, I
just used /bin/true.  Suboptimal, but it let the compile complete.  I
didn't see an obvious way to set the path to an external emacs, I just
edited the makefile.

3) Now, a real bug.  With an undumpped emacs,
window__resize_root_window_vertically is called before it's defined.  Even
putting if (initialzed) before the call didn't help.  I had to put  if (!EQ
(XSYMBOL (Qwindow_resize_root_window_vertically)->function, Qunbound))
before the two calls to  call2 (Qwindow_resize_root_window_vertically,  in
window.c.

Now, I'm going to try to and some more libraries and do some additional
testing.  If anyone has questions, email me directly.

    Ross

[Message part 2 (text/html, inline)]

Message #8 received at 13479 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ross Biro <ross.biro <at> mindspring.com>
Cc: 13479 <at> debbugs.gnu.org
Subject: Re: bug#13479: Cross Compiling for ARM
Date: Fri, 18 Jan 2013 09:26:49 -0500

> Obviously, I also had to CANNOT_DUMP=yes as well.

That's a problem that would need to be solved, of course, because there
are invariably more bugs in this mode of operation.

> 1) It doesn't look like emacs has a concept of a BUILDCC.  I like to set CC
> to the cross compiler since that seems to be what most things need.
> However make-docfile and test-distrib need to be built with the local
> compiler.  Usually the path to the local compiler is stored in BUILDCC.
> I just changed the $(CC) to $(BUILDCC) in the makefile for those two file and
> everything compiled ok.

We could incorporate this part of your changes, I think.

> 2) The lisp and leim directories really want a local copy of Emacs to
> compile.

Actually, any random local copy probably won't cut it, it needs to be
sufficiently uptodate.  In the worst case, it needs to be exactly the
version you're compiling.

What would need to happen is to more clearly separate the
src/bootstrap-emacs (which should be built with BUILDCC) from the
src/emacs (built with CC), so that you can run the src/bootstrap-emacs
to compile the lisp and leim subdirectories.

An alternative is of course to use an emulator to run src/emacs and/or
src/bootstrap-emacs.

> 3) Now, a real bug.  With an undumpped emacs,
> window__resize_root_window_vertically is called before it's defined.  Even
> putting if (initialzed) before the call didn't help.  I had to put  if (!EQ
> (XSYMBOL (Qwindow_resize_root_window_vertically)->function, Qunbound))
> before the two calls to  call2 (Qwindow_resize_root_window_vertically,  in
> window.c.

Most/all calls to Elisp from C should protect themselves with calls to
Ffboundp or similar, indeed.  Martin, could you take care of that?


        Stefan

Message #11 received at 13479 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Ross Biro <ross.biro <at> mindspring.com>, 13479 <at> debbugs.gnu.org
Subject: Re: bug#13479: Cross Compiling for ARM
Date: Fri, 18 Jan 2013 18:55:07 +0100

> Most/all calls to Elisp from C should protect themselves with calls to
> Ffboundp or similar, indeed.  Martin, could you take care of that?

I'm not sure.  If most/all calls should be protected we'd better provide
call_[1-4]_safe function for this purpose.  But I haven't the slightest
idea of what might happen when some of these functions don't get called.

martin

Message #14 received at 13479 <at> debbugs.gnu.org (full text, mbox):

From: Ross Biro <ross.biro <at> mindspring.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 13479 <at> debbugs.gnu.org
Subject: Re: bug#13479: Cross Compiling for ARM
Date: Fri, 18 Jan 2013 17:09:36 -0500

[Message part 1 (text/plain, inline)]

I haven't investigated.  But because protecting those calls by if
(initialized) and even moving the lisp->C binding for
window_root_window_resize_vertically to after initialization didn't help, I
suspect the issue might be deeper than just protecting C calls to lisp.  I
really don't know how to follow up though.

    Ross


On Fri, Jan 18, 2013 at 12:55 PM, martin rudalics <rudalics <at> gmx.at> wrote:

> > Most/all calls to Elisp from C should protect themselves with calls to
> > Ffboundp or similar, indeed.  Martin, could you take care of that?
>
> I'm not sure.  If most/all calls should be protected we'd better provide
> call_[1-4]_safe function for this purpose.  But I haven't the slightest
> idea of what might happen when some of these functions don't get called.
>
> martin
>

[Message part 2 (text/html, inline)]

Message #17 received at 13479 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Ross Biro <ross.biro <at> mindspring.com>, 13479 <at> debbugs.gnu.org
Subject: Re: bug#13479: Cross Compiling for ARM
Date: Fri, 18 Jan 2013 20:18:31 -0500

>> Most/all calls to Elisp from C should protect themselves with calls to
>> Ffboundp or similar, indeed.  Martin, could you take care of that?
> I'm not sure.  If most/all calls should be protected we'd better provide
> call_[1-4]_safe function for this purpose.

Could be, but I suspect that when the function is not defined, we might
actually want to do something else rather than not do anything at all,
so maybe just call_safe is not quite sufficient.

> But I haven't the slightest idea of what might happen when some of
> these functions don't get called.

These calls come from your "rewrite" of the window.c code, AFAIK, so
I think you're the person who'd best know what needs to happen when
window.el is not yet loaded,


        Stefan

Message #20 received at 13479 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ross Biro <ross.biro <at> mindspring.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 13479 <at> debbugs.gnu.org
Subject: Re: bug#13479: Cross Compiling for ARM
Date: Sat, 19 Jan 2013 11:11:31 +0100

[Message part 1 (text/plain, inline)]

> I haven't investigated.  But because protecting those calls by if
> (initialized) and even moving the lisp->C binding for
> window_root_window_resize_vertically to after initialization didn't help, I
> suspect the issue might be deeper than just protecting C calls to lisp.  I
> really don't know how to follow up though.

If Lisp hasn't been called yet, the root window cannot have
been split yet.  So in the case at hand the following patch
sould work.  Can you please try it?

Thanks, martin

[resize_root_window_vertically.diff (text/plain, inline)]

=== modified file 'src/window.c'
--- src/window.c	2013-01-11 23:08:55 +0000
+++ src/window.c	2013-01-19 09:54:07 +0000
@@ -4207,8 +4207,15 @@
 
   root = FRAME_ROOT_WINDOW (f);
   r = XWINDOW (root);
-  value = call2 (Qwindow_resize_root_window_vertically,
-		 root, make_number (- delta));
+  if (WINDOW_LIVE_P (root))
+    {
+      wset_new_total (r, make_number (XFASTINT (r->total_lines) - delta));
+      value = make_number (- delta);
+    }
+  else
+    value = call2 (Qwindow_resize_root_window_vertically,
+		   root, make_number (- delta));
+
   if (INTEGERP (value) && window_resize_check (r, 0))
     {
       block_input ();
@@ -4245,8 +4252,15 @@
     {
       root = FRAME_ROOT_WINDOW (f);
       r = XWINDOW (root);
-      value = call2 (Qwindow_resize_root_window_vertically,
-		     root, make_number (size - 1));
+      if (WINDOW_LIVE_P (root))
+	{
+	  wset_new_total (r, make_number (XFASTINT (r->total_lines) + size - 1));
+	  value = make_number (size - 1);
+	}
+      else
+	value = call2 (Qwindow_resize_root_window_vertically,
+		       root, make_number (size - 1));
+
       if (INTEGERP (value) && window_resize_check (r, 0))
 	{
 	  block_input ();

Message #23 received at 13479 <at> debbugs.gnu.org (full text, mbox):

From: Ross Biro <ross.biro <at> mindspring.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 13479 <at> debbugs.gnu.org
Subject: Re: bug#13479: Cross Compiling for ARM
Date: Tue, 22 Jan 2013 22:49:12 -0500

[Message part 1 (text/plain, inline)]

I don't have a wset_new_total.  Is that a new function?  I'm using mostly
stock 24.2.

    Ross


On Sat, Jan 19, 2013 at 5:11 AM, martin rudalics <rudalics <at> gmx.at> wrote:

> I haven't investigated.  But because protecting those calls by if
>> (initialized) and even moving the lisp->C binding for
>> window_root_window_resize_**vertically to after initialization didn't
>> help, I
>> suspect the issue might be deeper than just protecting C calls to lisp.  I
>> really don't know how to follow up though.
>>
>
> If Lisp hasn't been called yet, the root window cannot have
> been split yet.  So in the case at hand the following patch
> sould work.  Can you please try it?
>
> Thanks, martin
>
>
> === modified file 'src/window.c'
> --- src/window.c        2013-01-11 23:08:55 +0000
> +++ src/window.c        2013-01-19 09:54:07 +0000
> @@ -4207,8 +4207,15 @@
>
>    root = FRAME_ROOT_WINDOW (f);
>    r = XWINDOW (root);
> -  value = call2 (Qwindow_resize_root_window_vertically,
> -                root, make_number (- delta));
> +  if (WINDOW_LIVE_P (root))
> +    {
> +      wset_new_total (r, make_number (XFASTINT (r->total_lines) - delta));
> +      value = make_number (- delta);
> +    }
> +  else
> +    value = call2 (Qwindow_resize_root_window_vertically,
> +                  root, make_number (- delta));
> +
>    if (INTEGERP (value) && window_resize_check (r, 0))
>      {
>        block_input ();
> @@ -4245,8 +4252,15 @@
>      {
>        root = FRAME_ROOT_WINDOW (f);
>        r = XWINDOW (root);
> -      value = call2 (Qwindow_resize_root_window_vertically,
> -                    root, make_number (size - 1));
> +      if (WINDOW_LIVE_P (root))
> +       {
> +         wset_new_total (r, make_number (XFASTINT (r->total_lines) + size
> - 1));
> +         value = make_number (size - 1);
> +       }
> +      else
> +       value = call2 (Qwindow_resize_root_window_vertically,
> +                      root, make_number (size - 1));
> +
>        if (INTEGERP (value) && window_resize_check (r, 0))
>         {
>           block_input ();
>
>
>
>

[Message part 2 (text/html, inline)]

Message #26 received at 13479 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ross Biro <ross.biro <at> mindspring.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 13479 <at> debbugs.gnu.org
Subject: Re: bug#13479: Cross Compiling for ARM
Date: Wed, 23 Jan 2013 08:31:24 +0100

[Message part 1 (text/plain, inline)]

> I don't have a wset_new_total.  Is that a new function?  I'm using mostly
> stock 24.2.

These are setter functions whose purpose I forgot.  I attach a manually
and untested reconstruction of the original assignments.

martin

[resize_root_window_vertically.diff (text/plain, inline)]

=== modified file 'src/window.c'
--- src/window.c	2013-01-11 23:08:55 +0000
+++ src/window.c	2013-01-19 09:54:07 +0000
@@ -4207,8 +4207,15 @@
 
   root = FRAME_ROOT_WINDOW (f);
   r = XWINDOW (root);
-  value = call2 (Qwindow_resize_root_window_vertically,
-		 root, make_number (- delta));
+  if (WINDOW_LIVE_P (root))
+    {
+      r->new_total = make_number (XFASTINT (r->total_lines) - delta);
+      value = make_number (- delta);
+    }
+  else
+    value = call2 (Qwindow_resize_root_window_vertically,
+		   root, make_number (- delta));
+
   if (INTEGERP (value) && window_resize_check (r, 0))
     {
       block_input ();
@@ -4245,8 +4252,15 @@
     {
       root = FRAME_ROOT_WINDOW (f);
       r = XWINDOW (root);
-      value = call2 (Qwindow_resize_root_window_vertically,
-		     root, make_number (size - 1));
+      if (WINDOW_LIVE_P (root))
+	{
+	  r->new_total = make_number (XFASTINT (r->total_lines) + size - 1);
+	  value = make_number (size - 1);
+	}
+      else
+	value = call2 (Qwindow_resize_root_window_vertically,
+		       root, make_number (size - 1));
+
       if (INTEGERP (value) && window_resize_check (r, 0))
 	{
 	  block_input ();

Message #29 received at 13479 <at> debbugs.gnu.org (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Ross Biro <ross.biro <at> mindspring.com>, 13479 <at> debbugs.gnu.org
Subject: Re: bug#13479: Cross Compiling for ARM
Date: Thu, 24 Jan 2013 12:42:26 +0800

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Obviously, I also had to CANNOT_DUMP=yes as well.
>
> That's a problem that would need to be solved, of course, because there
> are invariably more bugs in this mode of operation.
>
>> 1) ... However make-docfile and test-distrib need to be built with
>> the local compiler...
>
> We could incorporate this part of your changes, I think.
>
>> 2) The lisp and leim directories really want a local copy of Emacs to
>> compile.
>
> ...
> An alternative is of course to use an emulator to run src/emacs and/or
> src/bootstrap-emacs.

Using an emulator would allow dumping as well, and could also be used
for make-docfile and test-distrib.

I think gcc has similar cross-compilation bootstrapping issues which
have been solved in the makefiles, so that is probably a good example to
follow if making cross-compilation work is something someone wants to
seriously fix.

Message #34 received at 13479 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Ross Biro <ross.biro <at> mindspring.com>
Cc: 13479 <at> debbugs.gnu.org
Subject: Re: bug#13479: Cross Compiling for ARM
Date: Wed, 10 Jan 2024 03:11:14 -0800

Ross Biro <ross.biro <at> mindspring.com> writes:

> I just more or less successfully compiled emacs-24.2 for a Samsung Chromebook.  I did it by using the chrooted build
> environment for chromiumos.  In the process I learned a couple of things.
>
> I used the configuration:
>
> ../emacs-24.2/configure  --build=x86_64-pc-linux-gnu --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi -
> -with-x-toolkit=no --with-xpm=no --with-jpeg=no --with-png=no --with-gif=no --with-tiff=no  --without-xml2 --without-gnutls -
> -without-x --without-dbus --with-crt-dir=/build/arm-generic/usr/lib/
>
> Obviously, I also had to CANNOT_DUMP=yes as well.
>
> 1) It doesn't look like emacs has a concept of a BUILDCC.  I like to set CC to the cross compiler since that seems to be what most
> things need.  However make-docfile and test-distrib need to be built with the local compiler.  Usually the path to the local compiler
> is stored in BUILDCC.  I just changed the $(CC) to $(BUILDCC) in the makefile for those two file and everything compiled ok.
>
> 2) The lisp and leim directories really want a local copy of emacs to compile.  Since I didn't have one available in the chrooted
> environment, I just used /bin/true.  Suboptimal, but it let the compile complete.  I didn't see an obvious way to set the path to an
> external emacs, I just edited the makefile.
>
> 3) Now, a real bug.  With an undumpped emacs, window__resize_root_window_vertically is called before it's defined.  Even
> putting if (initialzed) before the call didn't help.  I had to put  if (!EQ (XSYMBOL
> (Qwindow_resize_root_window_vertically)->function, Qunbound)) before the two calls to  call2
> (Qwindow_resize_root_window_vertically,  in window.c.
>
> Now, I'm going to try to and some more libraries and do some additional testing.  If anyone has questions, email me directly.
>
>     Ross

That was 10 years ago.  I'm therefore reaching out to ask if this bug is
still relevant, or if it has since been fixed?

If I don't hear back from you within a couple of months, Ill just assume
that this has been fixed and close this bug.

Thanks in advance.

Message #37 received at 13479 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Toon Claes <toon <at> iotcl.net>
Cc: 9192 <at> debbugs.gnu.org, 13479 <at> debbugs.gnu.org
Subject: Re: bug#13479: Cross Compiling for ARM
Date: Wed, 10 Jan 2024 03:11:36 -0800

Toon Claes <toon <at> iotcl.net> writes:

> I was trying to cross-compile emacs for ARM (don't ask me why).
> But got an error during 'make' (see output below FIRST RUN).
>
> So it's for sure 'test-distrub' was build for ARM, while it is trying to run on i686.
>
> On the second run (just, ran 'make again), I got a similar error on 'prefix-args'.
> But for some reason the 'test-distrub' error is gone (probably because 'make' thinks it is already finished.
>
> So I have to compile them with the host compiler (i686).
> But I'm not sure how to implement this properly.
>
>
> Also I would like to get rid of the warning: "LIB_GCC" redefined

That was 12 years ago.  I'm therefore reaching out to ask if this bug is
still relevant, or if it has since been fixed?

If I don't hear back from you within a couple of months, Ill just assume
that this has been fixed and close this bug.

Thanks in advance.

Message #42 received at 13479 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Toon Claes <toon <at> iotcl.net>, 9192 <at> debbugs.gnu.org, 13479 <at> debbugs.gnu.org
Subject: Re: bug#13479: Cross Compiling for ARM
Date: Wed, 10 Jan 2024 19:44:00 +0800

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Toon Claes <toon <at> iotcl.net> writes:
>
>> I was trying to cross-compile emacs for ARM (don't ask me why).
>> But got an error during 'make' (see output below FIRST RUN).
>>
>> So it's for sure 'test-distrub' was build for ARM, while it is trying to run on i686.
>>
>> On the second run (just, ran 'make again), I got a similar error on 'prefix-args'.
>> But for some reason the 'test-distrub' error is gone (probably because 'make' thinks it is already finished.
>>
>> So I have to compile them with the host compiler (i686).
>> But I'm not sure how to implement this properly.
>>
>>
>> Also I would like to get rid of the warning: "LIB_GCC" redefined
>
> That was 12 years ago.  I'm therefore reaching out to ask if this bug is
> still relevant, or if it has since been fixed?
>
> If I don't hear back from you within a couple of months, Ill just assume
> that this has been fixed and close this bug.

The Android port is routinely cross-compiled for ARM systems, so despite
its using a different build procedure from the rest of our builds, no
code except dumping should remain that prevents cross-compiling Emacs.

The OP's requirements have also been satisified by the Android port,
which is supposed to support Chromebooks.

Message #47 received at 13479-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Toon Claes <toon <at> iotcl.net>, 13479-done <at> debbugs.gnu.org,
 9192-done <at> debbugs.gnu.org
Subject: Re: bug#13479: Cross Compiling for ARM
Date: Wed, 10 Jan 2024 03:56:41 -0800

Po Lu <luangruo <at> yahoo.com> writes:

> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> Toon Claes <toon <at> iotcl.net> writes:
>>
>>> I was trying to cross-compile emacs for ARM (don't ask me why).
>>> But got an error during 'make' (see output below FIRST RUN).
>>>
>>> So it's for sure 'test-distrub' was build for ARM, while it is trying to run on i686.
>>>
>>> On the second run (just, ran 'make again), I got a similar error on 'prefix-args'.
>>> But for some reason the 'test-distrub' error is gone (probably because 'make' thinks it is already finished.
>>>
>>> So I have to compile them with the host compiler (i686).
>>> But I'm not sure how to implement this properly.
>>>
>>>
>>> Also I would like to get rid of the warning: "LIB_GCC" redefined
>>
>> That was 12 years ago.  I'm therefore reaching out to ask if this bug is
>> still relevant, or if it has since been fixed?
>>
>> If I don't hear back from you within a couple of months, Ill just assume
>> that this has been fixed and close this bug.
>
> The Android port is routinely cross-compiled for ARM systems, so despite
> its using a different build procedure from the rest of our builds, no
> code except dumping should remain that prevents cross-compiling Emacs.
>
> The OP's requirements have also been satisified by the Android port,
> which is supposed to support Chromebooks.

Thanks, I'm therefore closing this bug report.

If this conclusion is incorrect and this is still an issue, please reply
to this email (use "Reply to all" in your email client) and we can
reopen the bug report.

Message #55 received at 13479-done <at> debbugs.gnu.org (full text, mbox):

From: Toon Claes <toon <at> iotcl.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Po Lu <luangruo <at> yahoo.com>, Toon Claes <toon <at> iotcl.net>,
 9192-done <at> debbugs.gnu.org, 13479-done <at> debbugs.gnu.org
Subject: Re: bug#13479: Cross Compiling for ARM
Date: Wed, 10 Jan 2024 14:10:36 +0100

Stefan Kangas <stefankangas <at> gmail.com> writes:

>>> That was 12 years ago.  I'm therefore reaching out to ask if this bug is
>>> still relevant, or if it has since been fixed?

I don't know if the issue still exists, and I have no way to test it.
But I also assume it is no longer an issue, and agree to close this
issue.

Thanks for cleaning up this old bug report.

--
Toon

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.