bug#13479: Cross Compiling for ARM

bug#13479: Cross Compiling for ARM

[Ross Biro]

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

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

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

bug#13479: Cross Compiling for ARM

[Stefan Monnier]

> 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

bug#13479: Cross Compiling for ARM

[martin rudalics]

 > 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

bug#13479: Cross Compiling for ARM

[Ross Biro]

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

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@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
>

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

bug#13479: Cross Compiling for ARM

[Stefan Monnier]

>> 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

bug#13479: Cross Compiling for ARM

[martin rudalics]

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

> 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


[-- Attachment #2: resize_root_window_vertically.diff --]
[-- Type: text/plain, Size: 1181 bytes --]

=== 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 ();

bug#13479: Cross Compiling for ARM

[Ross Biro]

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

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@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 ();
>
>
>
>

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

bug#13479: Cross Compiling for ARM

[martin rudalics]

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

 > 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

[-- Attachment #2: resize_root_window_vertically.diff --]
[-- Type: text/plain, Size: 1171 bytes --]

=== 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 ();

bug#13479: Cross Compiling for ARM

[Jason Rumney]

Stefan Monnier <monnier@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.

bug#13479: Cross Compiling for ARM

[Stefan Kangas]

Ross Biro <ross.biro@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.

bug#13479: Cross Compiling for ARM

[Stefan Kangas]

Toon Claes <toon@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.

bug#13479: Cross Compiling for ARM

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> Toon Claes <toon@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.

bug#13479: Cross Compiling for ARM

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Toon Claes <toon@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.

bug#13479: Cross Compiling for ARM

[Toon Claes via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@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