On Thu, 17 Oct 2019 at 10:25, Marc Feeley <feeley@iro.umontreal.ca> wrote:

> On Oct 17, 2019, at 9:17 AM, Adam <adam.mlmb@gmail.com> wrote:
>
> Hi Marc,
>
> Talked to Vyzo, and this question came up:
>
> In the C backend using GCC, Gambit supports cross-compliation (say to an ARM Mac OS or Android from some AMD Unix machine), right.
>
> How do you pull off cross-compilation relative to not having ./configure have a host to autodetect features on,
>
> Which considerations do I need to make for successful cross-compliation?
>
> Do I need a separate Gambit build for each destination platform (so I'd do the |compile-file| within the respective build), or can my default Gambit installation be tweaked to compile against multiple platforms?
>
> Thanks!

The configure script is a shell script that relies on basic tools (grep, sed, …) and the C compiler to detect the properties of the platform.  So when you compile a Scheme app to .c you should run the configure script first, and then compile the .c files of your app (and the files in lib/).

The .c files generated are *completely* independent of the platform they were compiled on.  You can compile a .scm file on linux 64 bit, and Windows 32 bit, and raspberry pi ARM and you will get the same .c file generated from gsc.

Marc

Hi Marc,

Three rounds of followup questions:

(a)
Wait, when I correlate what you wrote now with some memory of slides you made in the past, I understand this:

1. Scheme to C compilation, performed by |compile-file-to-target|, is (expectably) deterministic.

Is this step at all a function of ./configure arguments, will --enable-cplusplus affect generated C file contents, I guess not as that will only affect macros in gambit.h - so this step is (expectably) purely functional?

Interesting to note here is that |compile-file-to-target| has no direct nor indirect dependencies on Unix tools autodetected by ./configure (grep sed etc.).

2. C to binary compilation is a function of gambit.h, which is generated by ./configure . This means if you distribute Gambit-compiled C files for build at another machine, those need to be bundled with the ./configure script which will do the host autodetection at the build machine, and of course gambit.h.in which ./configure customizes, and of course the Gambit runtime .c files.

Correct?


(b)
GVM registers count is specific per target architecture.

I'd have thought that that count would be an input to |compile-file-to-target|. Are you saying for the C backend, it's not?

(So |compile-file-to-target|'s binary backends for AMD64 etc. will indeed have fixed GVM register counts, but for the C backend instead it's... deferred to the C compiler?)


(c)
And now to how this correlates with cross-platform C compilation:

So things like endianness, native integer bit width, GVM register count are normally autodetected by the ./configure script, for the respective host platform.

Say that I like to have GCC on one build machine output binaries for several platforms, such as the AMD64 host, an ARM64 Android Linux, and some more platform supported by GCC.

How do you recommend cross-platform builds to be made -

(Of course one way would be to simply transfer C files to machines of the respective architecture, and build there (./configure; gcc), though that's not crossplatform -)


Would you run ./configure on the build machine with particular arguments that force target architecture and then a path for the gambit.h output file that would be the "configuration file" for that host platform, something like "--force-arch=arm64 --generate-gambit.h-path=~/crossplatformbuilds/arm64_android/gambit.h"?

And then C compilation would be done with "-I~/crossplatformbuilds/arm64_android/" plus arguments to yet-again force target architecture?


Thoughts on how to do this best would be much appreciated. This email came out of discussing the topic with Vyzo re Gerbil, I asked him if Gerbil does crosscompilation and he said nope & unsure how do it in the underlying Gambit.

Adam