bug#13479: closed (Cross Compiling for ARM)

[GNU bug Tracking System]

Your message dated Wed, 10 Jan 2024 03:56:41 -0800
with message-id 
<CADwFkmm39DoDvikkPzt+Z=-NERsbYi7dJ+beN+dW-t-ZtZYZ=g@mail.gmail.com>
and subject line Re: bug#13479: Cross Compiling for ARM
has caused the debbugs.gnu.org bug report #13479,
regarding Cross Compiling for ARM
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
13479: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13479
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: Cross Compiling for ARM Date: Thu, 17 Jan 2013 14:36:08 -0500

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

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#13479: Cross Compiling for ARM
>
>
>
>
> Date: 
>
> Wed, 10 Jan 2024 03:56:41 -0800
>
>
>
>
> 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.
>
>
> --- End Message ---