From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1745 invoked by alias); 4 Oct 2009 06:50:22 -0000 Received: (qmail 1736 invoked by uid 22791); 4 Oct 2009 06:50:21 -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 06:50:15 +0000 Received: by pxi29 with SMTP id 29so2214927pxi.14 for ; Sat, 03 Oct 2009 23:50:13 -0700 (PDT) Received: by 10.115.132.9 with SMTP id j9mr6599031wan.210.1254639013385; Sat, 03 Oct 2009 23:50:13 -0700 (PDT) Received: from Paullaptop (124-170-16-182.dyn.iinet.net.au [124.170.16.182]) by mx.google.com with ESMTPS id 23sm1732043pzk.0.2009.10.03.23.50.09 (version=SSLv3 cipher=RC4-MD5); Sat, 03 Oct 2009 23:50:12 -0700 (PDT) Message-ID: <01EDD002E9184163A5A91409025429D6@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><77AE26D4B4604E1EB60B7B6152EA9FD4@Paullaptop> In-Reply-To: Subject: Re: i370 port - constructing compile script Date: Sun, 04 Oct 2009 06:50: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/msg00074.txt.bz2 >>>>> * 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. But that's the first step in what I'm doing, isn't it? > fputs_unlocked is called by gcc itself, not by target code; As such, I am in a position where I can point it to my C90 libraries. I have everything I need to create the xgcc as a single executable on Linux that produces i370 assembler. That's what I already have with gcc 3.4.6. With 3.4.6, I have a script called "compile", which looks like this: call stdcomp alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp bb-reorder.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp bitmap.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp bt-load.c %1 %2 %3 %4 %5 %6 %7 %8 %9 ... gcc -s -nostdlib -o gccmvs.exe *.o ../../pdos/pdpclib/pdpwin32.a -lkernel32 The Windows version is simpler, but I have the equivalent for Linux. I call it gccmvs instead of xgcc. That's my cross-compiler. That was sort of hand-constructed (I actually selected stuff from the output of a normal make on Linux, skipping stuff that was used to produce the generator files (genrecog etc). I believe that a simple script like above can be *generated* with a few lines of changes to an appropriate makefile. That's why I mentioned before that I'm after a makefile target that only lists the object code that would go into a stage 1 executable. > 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. Well even with --with-build-sysroot I don't seem to be able to steer it away from my system's header files. But this is a more minor aspect to what I'm interested in. I think I'll just rename my system header files and copy in the C90 headers. > 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. This comment has me confused. I already have gcc 4.4 installed as a native compiler. I am now trying to build on Linux, to produce a Linux-to-i370 cross-compiler. Therefore the first thing I want to do is build a cross-compiler, right? Or does the build process want to force me to compile gcc 4.4 as a native compiler *again*? I was expecting it to just use what I already have, which coincidentally happens to be gcc 4.4. Can I skip that step then? I (used to) sometimes use a different compiler, such as Watcom or Borland, on Windows, in order to build the windows-to-i370 cross. >>> 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. In my case, I intend to run the cross-compiler on Linux to make sure it works. On Linux I also want to generate the compile script, and to generate the JCL. Once I have all those things (on the best system for gcc tools), I then want to package it all up and move to Windows. There I will run the compile script (shown above), and make sure that it also produces a single executable. I will use gcc 3.4.4 for that task, because it comes by default with Cygwin. I may choose to use Borland etc instead, but unlikely. At this stage I will be confident that I have a single C90-compliant executable, and the challenge becomes whether I can reproduce that on MVS. So I run a slightly different script, compmvs, which looks like this: call stdcompm alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcompm alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcompm attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcompm bb-reorder.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcompm bitmap.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcompm bt-load.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcompm builtins.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcompm caller-save.c %1 %2 %3 %4 %5 %6 %7 %8 %9 stdcompm.bat: gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CONFIG_H -DIN_GCC ... Once I have the assembler code, I zip it up, then use my Linux-generated JCL and pass it all over to MVS to see if it can assemble a stage 1 executable, which is how I have a 3.4.6 MVS executable. >> 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. Ok, I'm lost even further up the process now. I'm not sure whether to call MVS a target or host. >> 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. It's about 20 lines of intrusive code to combine GCC into a single executable, bypassing the need for a system() or similar call. Why would this be any different? The gcc build process *already* compiles each module. All I need to do is restrict the list of modules, and add the "-S" option, and then tell it to not complain about the ".o" not being generated, because I produced a ".s" instead. Doesn't sound like a lot of work if I can figure out where to put it, and the "-S" and a touch of ".o" can go into an external script to even eliminate that intrusion! :-) BFN. Paul.