From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26008 invoked by alias); 4 Oct 2009 22:51:38 -0000 Received: (qmail 25998 invoked by uid 22791); 4 Oct 2009 22:51:37 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-px0-f191.google.com (HELO mail-px0-f191.google.com) (209.85.216.191) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 04 Oct 2009 22:51:32 +0000 Received: by pxi29 with SMTP id 29so2510667pxi.14 for ; Sun, 04 Oct 2009 15:51:31 -0700 (PDT) Received: by 10.115.101.15 with SMTP id d15mr7719052wam.200.1254696687828; Sun, 04 Oct 2009 15:51:27 -0700 (PDT) Received: from Paullaptop (124-170-16-182.dyn.iinet.net.au [124.170.16.182]) by mx.google.com with ESMTPS id 21sm2244287pzk.11.2009.10.04.15.51.24 (version=SSLv3 cipher=RC4-MD5); Sun, 04 Oct 2009 15:51:25 -0700 (PDT) Message-ID: <6267ADE5641548FC8E063BC3A087AEC2@Paullaptop> From: "Paul Edwards" To: "Ulrich Weigand" Cc: "Ian Lance Taylor" , References: <200910041538.n94FccBP006189@d12av02.megacenter.de.ibm.com> In-Reply-To: <200910041538.n94FccBP006189@d12av02.megacenter.de.ibm.com> Subject: Re: i370 port - constructing compile script Date: Sun, 04 Oct 2009 22:51:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original 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/msg00083.txt.bz2 > 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. Thanks for the explanation Ulrich. I was previously under the impression (my interpretation of the documentation) that I just needed to do one configure, and it would do both of the steps you mentioned. > 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. Would you be able to give me the two suggested configure commands so that I can find out the answer to the above, one way or another? Perhaps if that bit fails I will need to replace the cross-compiler and cross-linker with normal gcc during the configure process, and only give it access to some C90 libraries. It so happens that I have a full suite of those, but even if I didn't, I could create a dummy printf etc so that it would at least link. Or does the configure process attempt to run the executables as well? No mind - as I said, I have the full suite for a configure to work. But it won't be able to correctly determine the stack direction if it does that. So that is the sort of thing I would need some intrusive code (out of my 20 lines quota!) to force it to 0 (unknown stack direction). Thanks. Paul.