Re: i370 port - constructing compile script

["Ulrich Weigand" <uweigand@de.ibm.com>]

Paul Edwards wrote:

> I'm not sure whether to call MVS a target or host.

Maybe it helps to take a step back and look at how the process
of initially getting a compiler for a system B built, starting
on an existing system A, usually works.

Each of the following steps can be identified by three systems:
- the "build" system (where the compiler build process runs)
- the "host" system (where the resulting compiler will run)
- the "target" system (where executables built by that compiler run)

Using this terminology, we need the following four stages:
(In your case, A would be "Linux on Intel", and B would be "MVS".)

1. build == A, host == A, target == A

This is the compiler you start out with, a native compiler for the A
system.  (You already have that, you do not need to rebuild it.)

2. build == A, host == A, target == B

This is a cross-compiler for B, running on A, which is itself built
on A using the compiler from 1.

3. build == A, host == B, target == B

This is a native B compiler, but it is *built* on A, using the A->B
cross-compiler from 2.  (This way of building a compiler is sometimes
refered to as a "Canadian cross".)

4. build == B, host == B, target == B

This step is optional, but using the native B compiler from 3., you
could now rebuild the compiler once again, this time on B itself.
At this point, B is fully supported and able to bootstrap its compiler
without any assistance from another system.


As there is nothing to do for step 1, and step 4 is optional, the
interesting parts are steps 2 and 3.  These are two separate build steps,
targeting different host systems to run the resulting compiler on.

As the properties of the host system (e.g. does it have "fork"
or "getrusage" or whatever) are detected at build time during
the "configure" step, you need to have a separate configure run
for step 2 and step 3.  Note that configure works but attempting
to compile and/or link small test programs.

In step 2, configure will use the host A compiler (from step 1) to
do these trial compiles.  The host A compiler will use the host A
header files and libaries, and thus configure will detect properties
of system A (which is correct, as in step 2, "host" == A).

In step 3, configure will use the A->B cross-compiler (from step 2)
to do the trial compiles.  This compiler, if built correctly, will
use host *B* header files and libraries from its sysroot, and thus
configure will detect properties of system *B* (which again is correct,
as in step 3, "host" == B).


From the symptoms you describe, it would appear that you're picking
up bad configure results in step 3.  Depending on what exactly you
do, this might be either because you don't actually re-run configure
but attempt to use the configure results from step 2 (that certainly
cannot work), or else your step 2 cross-compiler was itself built
incorrectly in some form so it doesn't properly pick up headers
from its sysroot, or else the headers in the sysroot are simply
incorrect ...  You should investigate the various log files left by
configure to figure out what's going on.

Note that one problem might be that your step 2 cross-compiler
cannot actually link executables as it is missing the cross-linker
required to do so.  I *think* the core GCC (C-only) configure
process should be able to handle this, but I might be mistaken
here.


I'm not sure if this helps, but I hope this might have at least
clarified a bit some of the terminology being used ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com