From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7811 invoked by alias); 4 Oct 2009 15:38:48 -0000 Received: (qmail 7797 invoked by uid 22791); 4 Oct 2009 15:38:46 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.17.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 04 Oct 2009 15:38:42 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n94FcduA025941 for ; Sun, 4 Oct 2009 15:38:39 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n94FcdEE3252386 for ; Sun, 4 Oct 2009 17:38:39 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n94FcdZu006197 for ; Sun, 4 Oct 2009 17:38:39 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n94FccBP006189; Sun, 4 Oct 2009 17:38:38 +0200 Message-Id: <200910041538.n94FccBP006189@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Sun, 04 Oct 2009 17:38:38 +0200 Subject: Re: i370 port - constructing compile script To: mutazilah@gmail.com (Paul Edwards) Date: Sun, 04 Oct 2009 15:38:00 -0000 From: "Ulrich Weigand" Cc: iant@google.com (Ian Lance Taylor), gcc@gcc.gnu.org In-Reply-To: <01EDD002E9184163A5A91409025429D6@Paullaptop> from "Paul Edwards" at Oct 04, 2009 05:49:56 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-10/txt/msg00078.txt.bz2 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