bug#9192: Cross-compile for ARM

bug#9192: Cross-compile for ARM

[Toon Claes]

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


Regards,
Toon


-------------- FIRST RUN -------------------
system call: make
cd lib-src; make all                            \
          CC='arm-none-linux-gnueabi-gcc' CFLAGS='-DHAVE_STRERROR' CPPFLAGS='-D_BSD_SOURCE  ' \
          LDFLAGS='-L/home/toon/sandbox/os/Sync/imx31d/Archives -L/home/toon/sandbox/os/Sync/imx31d/Libs -Wl,-znocombreloc ' MAKE='make'
make[1]: Entering directory `/home/toon/sandbox/os/Build/imx31d/emacs-23.3/lib-src'
arm-none-linux-gnueabi-gcc -D_BSD_SOURCE -DHAVE_CONFIG_H -I. -I../src -I/home/toon/sandbox/os/Build/imx31d/emacs-23.3/lib-src -I/home/toon/sandbox/os/Build/imx31d/emacs-23.3/lib-src/../src -L/home/toon/sandbox/os/Sync/imx31d/Archives -L/home/toon/sandbox/os/Sync/imx31d/Libs -Wl,-znocombreloc  -D_BSD_SOURCE   -DHAVE_STRERROR -o test-distrib /home/toon/sandbox/os/Build/imx31d/emacs-23.3/lib-src/test-distrib.c
In file included from ../src/config.h:1075,
                 from /home/toon/sandbox/os/Build/imx31d/emacs-23.3/lib-src/test-distrib.c:23:
../src/m/arm.h:42:1: warning: "LIB_GCC" redefined
In file included from ../src/config.h:1074,
                 from /home/toon/sandbox/os/Build/imx31d/emacs-23.3/lib-src/test-distrib.c:23:
../src/s/gnu-linux.h:200:1: warning: this is the location of the previous definition
./test-distrib /home/toon/sandbox/os/Build/imx31d/emacs-23.3/lib-src/testfile
./test-distrib:2: no such file or directory: ^@^@^@؃^@^@\M-l^@^@^@^R^@^@^@^@^@^@\M-d\M-^C^@^@,^@^@^@^R^@^@^@Q^@^@^@\M-p\M-^C^@^@\M-h^@^@^@^R^@^@^@/^@^@^@\M-|\M-^C^@^@d^@^@^@^R^@^@^@h^@^@^@^H\M-^D^@^@d^@^@^@^R^@^@^@^A^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@__gmon_start__^@libc.so.6^@perror^@abort^@fprintf^@read^@strncmp^@open64^@strcmp^@stderr^@exit^@__libc_start_main^@close^@GLIBC_2.4^@^@^@^B^@^B^@^B^@^B^@^B^@^B^@^B^@^B^@^B^@^B^@^B^@^@^@^@^@^A^@^A^@^P^@^@^@^P^@^@^@^@^@^@^@^Tii^M^@^@^B^@n^@^@^@^@^@^@^@<\t^A^@^U^L^@^@(\n^A^@^T^F^@^@^T\t^A^@^V^A^@^@^X\t^A^@^V^B^@^@^\\t^A^@^V^C^@^@ \t^A^@^V^D^@^@$\t^A^@^V^E^@^@(\t^A^@^V^G^@^@,\t^A^@^V^H^@^@0\t^A^@^V\t^@^@4\t^A^@^V\n^@^@8\t^A^@^V^K^@^@^D\M-`-\M-e^D\M-PM\M-b2^@^@\M-k^DЍ\M-b^@\M-^@\M-=\M-h^D\M-`-\M-e^D\M-`\M-^_\M-e^N\M-`\M-^O\M-`^H\M-p\M->\M-ep\M-^E^@^@^@Ə\M-b^Hʌ\M-bp\M-u\M-<\M-e^@Ə\M-b^Hʌ\M-bh\M-u\M-<\M-e^@Ə\M-b^Hʌ\M-b`\M-u\M-<\M-e^@Ə\M-b^Hʌ\M-bX\M-u\M-<\M-e^@Ə\M-b^Hʌ\M-bP\M-u\M-<\M-e^@Ə\M-b^Hʌ\M-bH\M-u\M-<\M-e^@Ə\M-b^Hʌ\M-b@\M-u\M-<\M-e^@Ə\M-b^Hʌ\M-b8\M-u\M-<\M-e^@Ə\M-b^Hʌ\M-b0\M-u\M-<\M-e^@Ə\M-b^Hʌ\M-b(\M-u\M-<\M-e$\M-@\M-^_\M-e^@\M-0\M- \M-c^D^P\M-^]\M-d^M \M- \M-a^D -\M-e^D^@-\M-e^P^@\M-^_\M-e^P0\M-^_\M-e^D\M-@-\M-e\M-]\M-^?\M-^?\M-k\M-V\M-^?\M-^?\M-kІ^@^@t\M-^E^@^@Ԇ^@^@^@D-\M-i^X\M- \M-^_\M-e\n\M- \M-^O\M-`^T0\M-^_\M-e^C0\M-^Z\M-g^@^@S\M-c^@\M-^D\M-=^H3\M-^?/\M-a^@\M-^D\M-=謄^@^@4^@^@^@^P \M-^_\M-e^@0\M-R\M-e^@^@S\M-c^A0\M-^C^B^@0\M-B^E^^\M-^?/\M-a,\n^A^@^D\M-`-\M-e$^@\M-^_\M-e^D\M-PM\M-b^@0\M-^P\M-e^\ \M-^_\M-e^@^@S\M-c^B^@^@\n^@^@R\M-c^@^@^@\n2\M-^?/\M-a^DЍ\M-b^@\M-^@\M-=\M-h^\^H^A^@^@^@^@^@^M\M-@\M- \M-a^@\M-X-\M-i^D\M-0L\M-b^X\M-PM\M-b^X^@^K\M-e^\^P^K\M-e  ^K\M-e^@0\M- \M-c^P0^K\M-e^P0^[\M-e^C \M- \M-a^\0^[\M-e^C^P\M-^B\M-`  ^[\M-e^P0^[\M-e^B0c\M-`^X^@^[\M-e^C \M- \M-a\M-8\M-^?\M-^?\M-k^@0\M- \M-a^T0^K\M-e^T0^[\M-e^@^@S\M-c^B^@^@^Z^P0^[\M-e$0^K\M-e\n^@^@\M-j^T0^[\M-e^@^@S\M-c^B^@^@\M-*^T0^[\M-e$0^K\M-e^D^@^@\M-j^P0^[\M-e^T ^[\M-e^B0\M-^C\M-`^P0^K\M-e\M-b\M-^?\M-^?\M-j$0^[\M-e^C^@\M- \M-a^L\M-PK\M-b^@\M-(\M-^]\M-h^M\M-@\M- \M-a^@\M-X-\M-i^D\M-0L\M-b^P\M-PM\M-b^X^@^K\M-e^\^P^K\M-e^X0^[\M-e^B^@S\M-c\t^@^@\n^X1\M-^_\M-e^@ \M-^S\M-e^\0^[\M-e^@0\M-^S\M-e^B^@\M- \M-a^H^Q\M-^_\M-e^C \M- \M-a\M-\n\M-^?\M-^?\M-k^A^@\M- \M-c\M-^K\M-^?\M-^?\M-k^\0^[\M-e^D0\M-^C\M-b^@0\M-^S\M-e^C^@\M- \M-a^@^P\M- \M-c^?\M-^?\M-^?\M-k^@0\M- \M-a^P0^K\M-e^P0^[\M-e^@^@S\M-c^F^@^@\M-*^\0^[\M-e^D0\M-^C\M-b^@0\M-^S\M-e^C^@\M- \M-ar\M-^?\M-^?\M-k^A^@\M- \M-cy\M-^?\M-^?\M-k^P^@^[\M-e\M-,^P\M-^_\M-es \M- \M-c\M-,\M-^?\M-^?\M-k^@0\M- \M-as^@S\M-c^S^@^@^Z\M-^T^@\M-^_\M-e\M-^T^P\M-^_\M-ec\M-^?\M-^?\M-k^@0\M- \M-a^@^@S\M-c^M^@^@^Z^P^@^[\M-ex^P\M-^_\M-el \M- \M-c\M-^_\M-^?\M-^?\M-k^@0\M- \M-ak^@S\M-c^F^@^@^Z`^@\M-^_\M-ed^P\M-^_\M-ek \M- \M-cO\M-^?\M-^?\M-k^@0\M- \M-a^@^@S\M-c\n^@^@\n<0\M-^_\M-e^@ \M-^S\M-e^\0^[\M-e^D0\M-^C\M-b^@0\M-^S\M-e^B^@\M- \M-a8^P\M-^_\M-e^C \M- \M-aR\M-^?\M-^?\M-k^A^@\M- \M-cS\M-^?\M-^?\M-k^P^@^[\M-eW\M-^?\M-^?\M-k^@0\M- \M-c^C^@\M- \M-a^L\M-PK\M-b^@\M-(\M-^]\M-h(\n^A^@T\M-^G^@^@-\n^A^@H\t^A^@\M-<\t^A^@h\M-^G^@^@^^\M-^?/\M-a\M-pG-\M-iT\M- \M-^_\M-e\n\M- \M-^O\M-`^@\M-^P\M- \M-a^A\M-^@\M- \M-a^Bp\M- \M-a \M-^?\M-^?\M-k@ \M-^_\M-e^B^P\M-\n\M-`<0\M-^_\M-e^C0b\M-`Ca\M-0\M-a\M-p\M-^G\M-=^H^@@\M- \M-c^AP\M- \M-a\t^@\M- \M-a^H^P\M- \M-a^G \M- \M-a^O\M-`\M- \M-a^D\M-p\M-^U\M-d^A@\M-^D\M-b^D^@V\M-a\M-w\M-^?\M-^?^Z\M-p\M-^G\M-=\M-h$\M-^B^@^@^L\M-^?\M-^?\M-^?^P\M-^?\M-^?\M-^?^D\M-`-\M-e^D\M-PM\M-b^DЍ\M-b^@\M-^@\M-=\M-h^A^@^B^@Usage: %s testfile\n^@Data in file `%s
./test-distrib:18: command not found: Most
./test-distrib:19: command not found: have
./test-distrib:39: unmatched '
make[1]: *** [test-distrib] Error 127



-------------- SECOND RUN -------------------
arm-none-linux-gnueabi-gcc -c -D_BSD_SOURCE   -Demacs -DHAVE_CONFIG_H  -I. -I/home/toon/sandbox/os/Build/imx31d/emacs-23.3/src -D_BSD_SOURCE     -DHAVE_STRERROR -MMD -MF deps/prefix-args.d prefix-args.c
In file included from ./config.h:1075,
                 from prefix-args.c:46:
./m/arm.h:42:1: warning: "LIB_GCC" redefined
In file included from ./config.h:1074,
                 from prefix-args.c:46:
./s/gnu-linux.h:200:1: warning: this is the location of the previous definition
arm-none-linux-gnueabi-gcc -Demacs -DHAVE_CONFIG_H  -I. -I/home/toon/sandbox/os/Build/imx31d/emacs-23.3/src -D_BSD_SOURCE     -DHAVE_STRERROR -MMD -MF deps/.d -L/home/toon/sandbox/os/Sync/imx31d/Archives -L/home/toon/sandbox/os/Sync/imx31d/Libs -Wl,-znocombreloc  prefix-args.o -o prefix-args
arm-none-linux-gnueabi-gcc -nostdlib `./prefix-args -Xlinker  -z nocombreloc` -L/home/toon/sandbox/os/Sync/imx31d/Archives -L/home/toon/sandbox/os/Sync/imx31d/Libs -Wl,-znocombreloc  -o temacs pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o dispnew.o frame.o scroll.o xdisp.o menu.o  window.o charset.o coding.o category.o ccl.o character.o chartab.o cm.o term.o terminal.o xfaces.o    emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o font.o print.o lread.o syntax.o unexelf.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.o     terminfo.o lastfile.o   vm-limit.o  mktime.o       -lncurses   -lgcc_s -lm -lgcc -lc -lgcc /usr/lib/crtn.o -lgcc_s
zsh:1: exec format error: ./prefix-args
/home/toon/sandbox/os/Ref/imx31d/imx31-toolchain/Imx31/bin/../lib/gcc/arm-none-linux-gnueabi/4.1.2/../../../../arm-none-linux-gnueabi/bin/ld: /usr/lib/crt1.o: Relocations in generic ELF (EM: 3)
/home/toon/sandbox/os/Ref/imx31d/imx31-toolchain/Imx31/bin/../lib/gcc/arm-none-linux-gnueabi/4.1.2/../../../../arm-none-linux-gnueabi/bin/ld: /usr/lib/crt1.o: Relocations in generic ELF (EM: 3)
/home/toon/sandbox/os/Ref/imx31d/imx31-toolchain/Imx31/bin/../lib/gcc/arm-none-linux-gnueabi/4.1.2/../../../../arm-none-linux-gnueabi/bin/ld: /usr/lib/crt1.o: Relocations in generic ELF (EM: 3)
/usr/lib/crt1.o: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[1]: *** [temacs] Error 1
make[1]: Leaving directory `/home/toon/sandbox/os/Build/imx31d/emacs-23.3/src'
make: *** [src] Error 2

bug#9192: Cross-compile for ARM

[Andreas Schwab]

The emacs sources are not prepared for cross compilation.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#9192: Cross-compile for ARM

[Toon Claes]

So the question is:
Is it a 'feature' or is it a bug?

Toon.


On 28 Jul 2011, at 23:13, Andreas Schwab wrote:

> The emacs sources are not prepared for cross compilation.
> 
> Andreas.
> 
> -- 
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

bug#9192: Cross-compile for ARM

[Stefan Monnier]

> Is it a 'feature' or is it a bug?

It's not a feature, but it's not a bug we find very important to fix.
IOW I'd be happy to accept patches which make cross-compiling easier,
but I won't write them myself and I would only accept them if they're
clean enough.

This said, I do remember someone posting on this list about a similar
issue and making actual progress in this direction.  And if you want to
try it, here are some things I know will need to be solved:
- We build a few programs used only during compilation: prefix-args,
  make-docfile, probably a few more (can't remember test-distrub, but
  if we build such a thing, then it's most likely in the set as well).
  You'll have to change the Makefile to compile those for the host
  rather than for the target.
- The Elisp files in lisp and leim need to be compiled by Emacs, so the
  src/bootstrap-emacs should be built for the host rather than for
  the target.
- You'll either want to build without dumping (i.e. set CANNOT_DUMP), or
  you'll want to split the dump step since it needs to be run on the
  target (but in either case you can do the dump for src/bootstrap-emacs
  since that runs on the host).  Builds using CANNOT_DUMP tend to have
  various misfeatures because this is basically never used and hence
  doesn't get much/any testing.

Maybe the easiest way to approach the problem is to first do a normal
build on the host (which builds src/bootstrap-emacs and compiles all the
Elisp files), then "rm src/*.o", reconfigure for the target and compile
src/temacs (and maybe afterwards do the `dump' on the target).


        Stefan

bug#9192: Cross-compile for ARM

[Dan Nicolaescu]

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

>> Is it a 'feature' or is it a bug?


BTW, the trunk should be a bit better now than the 23.x release in terms
of building.

> It's not a feature, but it's not a bug we find very important to fix.
> IOW I'd be happy to accept patches which make cross-compiling easier,
> but I won't write them myself and I would only accept them if they're
> clean enough.
>
> This said, I do remember someone posting on this list about a similar
> issue and making actual progress in this direction.  And if you want to
> try it, here are some things I know will need to be solved:
> - We build a few programs used only during compilation: prefix-args,

prefix-args has been removed from the trunk.

>   make-docfile, probably a few more (can't remember test-distrub, but
>   if we build such a thing, then it's most likely in the set as well).

We should just remove test-distrib.c ASAP, it doesn't seem that useful anymore.

>   You'll have to change the Makefile to compile those for the host
>   rather than for the target.
> - The Elisp files in lisp and leim need to be compiled by Emacs, so the
>   src/bootstrap-emacs should be built for the host rather than for
>   the target.
> - You'll either want to build without dumping (i.e. set CANNOT_DUMP), or

"temacs" now runs as expected, it should work better than setting
CANNOT_DUMP.
It starts up a bit slower, but it is just as usable as a dumped emacs
after that.

>   you'll want to split the dump step since it needs to be run on the
>   target (but in either case you can do the dump for src/bootstrap-emacs
>   since that runs on the host).  Builds using CANNOT_DUMP tend to have
>   various misfeatures because this is basically never used and hence
>   doesn't get much/any testing.
>
> Maybe the easiest way to approach the problem is to first do a normal
> build on the host (which builds src/bootstrap-emacs and compiles all the
> Elisp files), then "rm src/*.o", reconfigure for the target and compile
> src/temacs (and maybe afterwards do the `dump' on the target).

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