From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20915 invoked by alias); 4 Oct 2009 06:04:49 -0000 Received: (qmail 20907 invoked by uid 22791); 4 Oct 2009 06:04:48 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 04 Oct 2009 06:04:44 +0000 Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id n9464fSr016745 for ; Sat, 3 Oct 2009 23:04:42 -0700 Received: from yxe26 (yxe26.prod.google.com [10.190.2.26]) by wpaz13.hot.corp.google.com with ESMTP id n9464bZD003017 for ; Sat, 3 Oct 2009 23:04:37 -0700 Received: by yxe26 with SMTP id 26so2319036yxe.20 for ; Sat, 03 Oct 2009 23:04:37 -0700 (PDT) Received: by 10.150.56.37 with SMTP id e37mr7511685yba.104.1254636277327; Sat, 03 Oct 2009 23:04:37 -0700 (PDT) Received: from coign.google.com (adsl-71-133-8-30.dsl.pltn13.pacbell.net [71.133.8.30]) by mx.google.com with ESMTPS id 15sm1687398gxk.4.2009.10.03.23.04.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Oct 2009 23:04:36 -0700 (PDT) To: "Paul Edwards" Cc: Subject: Re: i370 port - constructing compile script References: <200909251516.n8PFGPYn014618@d12av02.megacenter.de.ibm.com> <4F1842D6879348899E3A1999066969F5@Paullaptop> <4AC39435.8010902@redhat.com> <36D486ECFFC04FBD8318DFDD333FD206@Paullaptop> <7AE4510479514D0E9B72A9B827275199@Paullaptop> <77AE26D4B4604E1EB60B7B6152EA9FD4@Paullaptop> From: Ian Lance Taylor Date: Sun, 04 Oct 2009 06:04:00 -0000 In-Reply-To: <77AE26D4B4604E1EB60B7B6152EA9FD4@Paullaptop> (Paul Edwards's message of "Sun\, 4 Oct 2009 16\:14\:20 +1100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true X-IsSubscribed: yes 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/msg00073.txt.bz2 "Paul Edwards" writes: >>>> * Copy header files and libraries from the host (MVS). >>> >>> That's fine. And use the --with-root option of configure to get >>> them used? >> >> --with-sysroot, yes. > > I have been trying combinations of --prefix and --with-sysroot, and > --with-build-sysroot, but it is still insisting that I have an > fputs_unlocked etc, despite pointing all those things to a > directory that has no such thing in it, and just has my C90 > headers. The --with-sysroot option tells gcc where to find header files and libraries for the target. The --with-build-sysroot option tells gcc where to find header files and libraries for the target while building gcc itself. fputs_unlocked is called by gcc itself, not by target code; therefore, what matters for whether fputs_unlocked is supported is the host header files and libraries, not the target header files and libraries. So using --with-sysroot is never going to affect whether gcc itself uses fputs_unlocked. The case where that should work if you configure gcc using --with-sysroot to point to C90 headers and libraries, and you use that gcc to build another gcc. That is, configure gcc as a cross-compiler to a system which happens to be very similar to the host system, and then use that cross-compiler to build a new compiler, in what is effectively a same-system Canadian Cross. The second gcc should not use fputs_unlocked in that case. >> Similarly, getrlimit and getrusage are entirely optional. They are >> used if available, otherwise not. > > Right. I'm having trouble getting it to ignore the ones that are installed > on the build system, and to switch to the directory given with > --with-sysroot. When talking about this kind of thing, you have to distinguish the build system and the host system. The header files on the build system are irrelevant. The header files on the host system are what matter. Normally the build system and the host system are the same, but this is not true when building with a cross-compiler. > Also, for the long term, it would be better to > distinguish the headers that I use on the build system, to the > headers used when cross-compiling. As I mentioned, I happen > to be in a position where I can use the same ones on MVS, on > Linux (and some other platforms too), so I can get away with > forcing it to the C90 headers immediately. gcc has no confusion between the headers on the host system and the headers on the target system. I don't know precisely how to map that onto your comment about the build system and the headers used when cross-compiling. > There's not much I can do about the non-acceptance of the mods, > but the one thing I can do is keep my modification footprint low. > That's why I believe that 20 lines somewhere in the configuration > scripts are probably enough to get what I want, without upsetting > the existing structure. Maybe eventually those 20 lines will be > accepted as a non-default option, but that is beyond my control. If you can demonstrate that 20 line configure script change, then we can certainly discuss it. I personally am rather skeptical that you can rewire gcc's build process in 20 lines. Ian