From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5006 invoked by alias); 21 Nov 2009 13:40:37 -0000 Received: (qmail 4995 invoked by uid 22791); 21 Nov 2009 13:40:35 -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-pw0-f57.google.com (HELO mail-pw0-f57.google.com) (209.85.160.57) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 21 Nov 2009 13:39:38 +0000 Received: by pwi2 with SMTP id 2so2760510pwi.16 for ; Sat, 21 Nov 2009 05:39:36 -0800 (PST) Received: by 10.114.186.37 with SMTP id j37mr3889350waf.36.1258810776604; Sat, 21 Nov 2009 05:39:36 -0800 (PST) Received: from Paullaptop (203-158-49-56.dyn.iinet.net.au [203.158.49.56]) by mx.google.com with ESMTPS id 20sm1617069pxi.15.2009.11.21.05.39.32 (version=SSLv3 cipher=RC4-MD5); Sat, 21 Nov 2009 05:39:34 -0800 (PST) Message-ID: From: "Paul Edwards" To: "Ulrich Weigand" Cc: "Ralf Wildenhues" , "Ian Lance Taylor" , References: <200911191425.nAJEPtOT029233@d12av02.megacenter.de.ibm.com> In-Reply-To: <200911191425.nAJEPtOT029233@d12av02.megacenter.de.ibm.com> Subject: Re: i370 port - constructing compile script Date: Sat, 21 Nov 2009 13:40: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-11/txt/msg00594.txt.bz2 >> gcov-iov creates a gcov-iov.h which has a version number >> which changes when I change MVS versions. So I am >> thinking of updating gcov-iov.c so that when the target is >> MVS, it generates a more fixed format. > > I don't see how the generated number depends on the MVS > version ... It is supposed to depend solely on the *GCC* > version string of the compiler currently being built. Mostly yes. However, it still grabs the full version string, which includes the text "MVS 0.X" (which I added, to identify the sub-version of 3.4.6 on MVS (note that for 3.2.3 I am up to MVS 7.6 there's been so much activity). And basically I don't want that GCOV header file to change between MVS releases. Anyway, in the build scripts (ie outside the normal configure/make process, so no-one needs to see it) I just overwrite the header, and I didn't notice any ill-effect. >> gengtype-yacc.c & .h gets created with my new version of bison. >> I just want to use the one that came with 3.4.6 instead of >> having it regenerated. Do I need to hide my bison to stop >> that from happening? > > Well, it's just a make step -- the files will get rebuilt if > and only if the gengtype-yacc.y file is more recent than the > gengtype-yacc.c and .h files. In the default 3.4.6 tarball > this is not the case. Did you somehow modify file timestamps > while unpacking / copying the files? Yes, I imported everything into CVS and that presumably changed all the timestamps. I wasn't aware of that. Anyway, I got around that problem by making dummy changes to the .c and .h and then reversing them out. So that is fixed now, thanks. >> gencheck.h is being generated as an empty file, which doesn't >> work well on some environments. I want it to at least have a >> comment saying "/* empty file */". I can put that in as part of >> the build script too. > > Well, adding a comment should be trivial at the place in the > Makefile.in where gencheck.h is generated (s-gencheck). Ok, I decided it was better to keep it outside the common files. > In any case, more recent GCC versions no longer refer to this > file at all. And I don't even need to revisit that decision for GCC 4 it seems. :-) So I've basically finished doing what I wanted for 3.4.6 now. I'm not going to spend time doing niceties like putting the generated files generation onto MVS so that mainframe users can upgrade the machine definition without needing a non-MVS machine. I have that nicety already for 3.2.3 and I may look into it again for 4.x. There's still one last thing for 3.4.6, although it's not really 3.4.6, I'm doing it for 3.2.3, but will have to incorporate that change into 3.4.6. And that thing is the MUSIC/SP port. I have managed to get dynamic allocation to work, which changes the whole look of the port, so I'm working through that, which I expect will take a couple of weeks. So that will be 3 nicely-working EBCDIC platforms. 4 if you count USS, but I don't use or test that, so don't know whether it works there currently. I should be starting the GCC 4 port in a matter of days, while using my Unix machine. Thanks everyone for helping get it to this point. BFN. Paul.