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.weig...@de.ibm.com
