From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13693 invoked by alias); 23 Oct 2009 14:15:06 -0000 Received: (qmail 13625 invoked by uid 22791); 23 Oct 2009 14:15:03 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pw0-f57.google.com (HELO mail-pw0-f57.google.com) (209.85.160.57) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Oct 2009 14:14:58 +0000 Received: by pwi18 with SMTP id 18so2901774pwi.16 for ; Fri, 23 Oct 2009 07:14:56 -0700 (PDT) Received: by 10.114.164.28 with SMTP id m28mr8516739wae.221.1256307296580; Fri, 23 Oct 2009 07:14:56 -0700 (PDT) Received: from Paullaptop (203-214-142-52.perm.iinet.net.au [203.214.142.52]) by mx.google.com with ESMTPS id 21sm1665072pxi.0.2009.10.23.07.14.54 (version=SSLv3 cipher=RC4-MD5); Fri, 23 Oct 2009 07:14:55 -0700 (PDT) Message-ID: From: "Paul Edwards" To: "Ulrich Weigand" Cc: "Ulrich Weigand" , References: <200910221803.n9MI33he012461@d12av02.megacenter.de.ibm.com> In-Reply-To: <200910221803.n9MI33he012461@d12av02.megacenter.de.ibm.com> Subject: Re: i370 port - constructing compile script Date: Fri, 23 Oct 2009 14:36: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/msg00464.txt.bz2 > As to the pex-unix.c, you certainly should provide a MVS-specific > version of the PEX callbacks. They are selected in configure.ac: > > # Figure out which version of pexecute to use. > case "${host}" in > *-*-mingw* | *-*-winnt*) pexecute=pex-win32.o ;; > *-*-msdosdjgpp*) pexecute=pex-djgpp.o ;; > *-*-msdos*) pexecute=pex-msdos.o ;; > *-*-os2-emx*) pexecute=pex-os2.o ;; > *) pexecute=pex-unix.o ;; > esac > > Your MVS version might be just a dummy that always fails. > Even better would be a version that actually works; in this > case all the "single-exectuable" hacks would become superfluous. > > Note that e.g. pex-msdos.c implements the required callbacks > solely in terms of the C99 "system" routine. If you at least > have this facility available on MVS, you might be able to just > use the msdos version? I tried using the MSDOS version and it had non-C90 compile errors. But provding a dummy pex-mvs is fine. >> Finally, even with this in place, the build process stopped at >> the next roadblock. The file "genmodes.c" couldn't be >> compiled. I was surprised to see that it was being compiled >> with i370-mvspdp-gcc. The genmodes "needs" to be run on >> Unix still. It's only the source code that IT generates that >> needs to be cross-compiled. > > If this happens, then something went very wrong during configure. > Did you make sure to use the proper build / host / target flags? > In particular, the --build= configure argument must be present > and refer to the build architecture. This is used to determine > which architecture to build the generator programs for. Ok, perhaps this error was because when I hit errors in intl, which I've never used before, I just went to the gcc directory and did a make. Regardless, I added a stack of touch xxx.o in the intl directory after the failure of the first make, which allowed me to do a second make, and then it was satisfied with the intl directory and moved on to the gcc directory, where it did in fact invoke the correct gcc rather than the cross-compiler. The next thing I hit was that genmodes didn't compile because there were conflicts between the strsignal function in the Linux include files and the system.h. Looking at the system.h, it was including things in because it thought that the prototypes didn't exist. Which would have been true for the cross-compiler, but isn't true for a native gcc. How are those two different things meant to be reconciled? Thanks. Paul.