[gambit-list] Cross-compilation Q
adam.mlmb at gmail.com
Sat Oct 19 08:03:25 EDT 2019
On Thu, 17 Oct 2019 at 10:25, Marc Feeley <feeley at iro.umontreal.ca> wrote:
> > On Oct 17, 2019, at 9:17 AM, Adam <adam.mlmb at 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.
Three rounds of followup questions:
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
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
Interesting to note here is that |compile-file-to-target| has no direct nor
indirect dependencies on Unix tools autodetected by ./configure (grep sed
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.
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?)
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
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
And then C compilation would be done with
"-I~/crossplatformbuilds/arm64_android/" plus arguments to yet-again force
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list