From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29962 invoked by alias); 4 Oct 2009 05:14:47 -0000 Received: (qmail 29949 invoked by uid 22791); 4 Oct 2009 05:14:45 -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 05:14:39 +0000 Received: by pxi29 with SMTP id 29so2185697pxi.14 for ; Sat, 03 Oct 2009 22:14:37 -0700 (PDT) Received: by 10.114.163.26 with SMTP id l26mr6532935wae.173.1254633277266; Sat, 03 Oct 2009 22:14:37 -0700 (PDT) Received: from Paullaptop (124-170-16-182.dyn.iinet.net.au [124.170.16.182]) by mx.google.com with ESMTPS id 23sm514881pzk.4.2009.10.03.22.14.34 (version=SSLv3 cipher=RC4-MD5); Sat, 03 Oct 2009 22:14:36 -0700 (PDT) Message-ID: <77AE26D4B4604E1EB60B7B6152EA9FD4@Paullaptop> From: "Paul Edwards" To: "Ian Lance Taylor" Cc: References: <200909251516.n8PFGPYn014618@d12av02.megacenter.de.ibm.com><4F1842D6879348899E3A1999066969F5@Paullaptop><4AC39435.8010902@redhat.com><36D486ECFFC04FBD8318DFDD333FD206@Paullaptop><7AE4510479514D0E9B72A9B827275199@Paullaptop> In-Reply-To: Subject: Re: i370 port - constructing compile script Date: Sun, 04 Oct 2009 05:14: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/msg00072.txt.bz2 >>> * Configure gcc as a cross-compiler. >> >> So this would not be considered a Canadian Cross after all, >> and with configure I only change the target, not the host? > > The end result is a Canadian Cross, but the first step in a typical > build of a Canadian Cross is a cross-compiler. Ok. >>> * Write a cross-assembler and cross-linker. >> >> Sure, and that's what I'm trying to avoid. I have a perfectly working >> assembler and linker on MVS already. It's been working for several >> decades. > > There are many advantages of a cross-assembler and cross-linker, but, > whatever. One of them is not "you can leverage into all the existing work of the existing-and-working-fine IFOX00 and IEWL". >>> * 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. >>> (Note that you mention fork, but as you probably know the gcc code >>> never actually calls fork. It calls the pexecute routines in >>> libiberty. Those routines have been ported to several different >>> hosts, including MS-DOS. If you port them to MVS, then you don't have >>> to worry about fork.) >> >> I spent several minutes going through the config.h looking at the >> "detected" functions to find a good example. Maybe I should I >> have getrlimit or getrusage or fputs_unlocked instead. > > fputs_unlocked is only used for systems which provide it. On systems > which don't, gcc uses fputs. > > 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. 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. > I've been discussing this under the assumption that you want to > contribute your port back to gcc. If you don't, then I think I will > step out. You can pursue whatever path you like. I do want it to be in the mainline gcc. But the requirements for reversing the 2004 deletion of the i370 target (which can be done with two svn commands) are too onerous to be met for likely years. I personally think it's strange that we had an i370 target that didn't meet those requirements from 1993 to 2004, but now it isn't, regardless of the fact that it now works better than ever before (not suprising after more than 5 years of effort by multiple people). But there's not much I can do about that. Way back In 1998 I was talking to someone from GCC (not ecgs) about getting some mods in to support MVS (I wasn't aware of other MVS activity on the ecgs side). The computer with the conversation was stolen, so I don't know who that was. Whoever it was, I think they had plans to rewrite the i370.md themselves (but that obviously didn't happen). My changes were all outside that. Basically I needed those small mods to create a single executable plus some other minor mods (similar to what I posted here recently). I don't recall if any of it was accepted or not (I just gave the patches, and no longer have those to see if they got in). I know the single-executable mods didn't get in, because I know what to look for, and it isn't there. 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. But regardless of whether it is accepted or not, I want to be able to demonstrate it working first. Where "working" doesn't mean "write my own cross-assembler and cross-linker and change MVS to be posix instead of MVS and get the entire test suite working", but rather "work the same way that gccmvs 3.2.3 works (ie bootstrapping works), except get the JCL and auto-host to be automatically generated instead of manually constructed for each release". It takes several days of effort to manually construct those files and debug the problems with them, when I suspect that with the right config command-line and a little bit of intrusive code, plus some external support scripts (that are no skin off anyone's nose), the whole thing can be automated. Anyway, I'll keep plugging away. I resorted to renaming /usr/include, but that triggered off other problems. I suspect it will come down to one line of code or one extra configure parameter, but it'll probably take days of experimentation to find that. BFN. Paul.