Re: Guile 1.8 success on `i386-apple-darwin9.6.0'

[Greg Troxel <gdt@ir.bbn.com>]

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


ludo@gnu.org (Ludovic Courtès) writes:

> Hi Greg,
>
> Greg Troxel <gdt@ir.bbn.com> writes:
>
>> I don't think that's true at all.  It could be that for running Linux on
>> arm pdas that's what most people do, but for the far more general case
>> there is normal cross compiling as autoconf has supported for years.
>>
>> I am working on a project that does cross builds of a lot of software;
>> none of it uses scratchbox.
>
> You may well have more experience than I have.

Or maybe just different...

I don't really understand the compiler.

>> I can certainly see the point of something like scratchbox, to ease the
>> process and work around software that has non-cross-clean build systems.
>> But I wouldn't say it's time to give up on the normal/traditional way.
>
> How would you handle this particular case in a "cross-clean" way?  The
> problem is that we need a Guile to compile the compiler.

Do we just need a (reasonable) guile, or do we need to run the target
just-built guile itself?  I saw some discussion about finding stack
offsets, and that's perhaps different.

I will use the terms 'host' and 'target' to describe the system one is
doing the build on, and the the system that the resulting guile runs on.
autoconf would call this 'build' and 'host'; 'host' refers to the
machine for which a compiler is built, and target to what the compiler
outputs.  But we aren't really building a compiler in that sense, maybe.

> I think it's not unusual to use just-built binaries to produce some
> intermediate source files, especially in the area of interpreters and
> compilers.  How do others handle it?

Yes, this is normal.  I'll point out that some of my experience comes
From the netbsd build system (to build the OS), and that experience
affects my opinions.  In NetBSD, basically all builds are cross, even if
host==target, in that the host toolchain is used to build the NetBSD
toolchain with the desired target, and then that is used to compile the
system.  One can build for other architectures, and from different host
platforms in the same way.

One of the things that has to be worked out to make a cross system
function is the notion of 'host tool', which is a program that is
compiled for the host.  An example from netbsd is the time zone
compiler, which shows up as nbzic in tools/bin.  There's only one such
binary even if you build for sparc64, i386, and alpha on an amd64 host.
There are three compilers, though; each runs on amd64 and produces
separate output.

> IIRC GCC stage N uses `xgcc' from stage N-1 in the non-cross case.  How
> does it work in the cross-compilation case?

There's a separate bootstrapping problem for compilers, which I think is
about building gcc with host cc, and then building gcc with gcc, so that
you get a gcc-compiled binary in the end.  With cross, I think you have
to build a gcc with target=host and then use that to build gcc with
target=target, but I'm not sure.


So, building guile probably needs either to build guile as a host tool

  if host != target, preferably in an objdir, and then that can be used.

  take a --with-guile that points to a working host guile, and people
  doing cross builds will have to build guile first.  This is not really
  all that differnet from having to build a cross gcc first, and would
  be ok with me (as a cross user - my system doesn't have guile, but if
  it worked that way it would be fine).  This can be the default
  behavior if autoconf's build and host (my host and target) differ.

I suppose the host=target case can use the same guile as the tool and
the output, because the compiler is additional to the interpreter.

If people use scratchbox, then the build is apparently not cross, even
if the gcc that is invoked is cross.  So this shouldn't hurt.

[-- Attachment #2: Type: application/pgp-signature, Size: 193 bytes --]