From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13108 invoked by alias); 13 Nov 2009 12:18:04 -0000 Received: (qmail 13094 invoked by uid 22791); 13 Nov 2009 12:18:02 -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; Fri, 13 Nov 2009 12:17:57 +0000 Received: by pwi2 with SMTP id 2so2081835pwi.16 for ; Fri, 13 Nov 2009 04:17:55 -0800 (PST) Received: by 10.115.133.38 with SMTP id k38mr2594167wan.120.1258114675451; Fri, 13 Nov 2009 04:17:55 -0800 (PST) Received: from Paullaptop (203-158-49-56.dyn.iinet.net.au [203.158.49.56]) by mx.google.com with ESMTPS id 23sm2262706pxi.5.2009.11.13.04.17.52 (version=SSLv3 cipher=RC4-MD5); Fri, 13 Nov 2009 04:17:54 -0800 (PST) Message-ID: From: "Paul Edwards" To: "Ulrich Weigand" Cc: "Ralf Wildenhues" , "Ian Lance Taylor" , References: <200911131201.nADC1meQ019515@d12av02.megacenter.de.ibm.com> In-Reply-To: <200911131201.nADC1meQ019515@d12av02.megacenter.de.ibm.com> Subject: Re: i370 port - constructing compile script Date: Fri, 13 Nov 2009 12:18: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/msg00381.txt.bz2 >> Next, a stack of libiberty files were not compiled - strcasecmp, >> vasprintf, asprintf, getpagesize, strdup. I don't know why this >> would be the case, because e.g. HAVE_STRCASECMP is >> not defined. Anyway, I added them to the source list manually, >> and with a script, awk and m4, I was able to produce my >> traditional compile script (which is a stepping stone for doing >> the same thing on MVS). > > The libiberty configure process attempts to detect which functions > need to be built via link tests by default. As you don't have a > cross-linker, something may be going wrong here. As an alternative, > you can hard-code which functions to use in libiberty's configure.ac. The thing is, I already know it has detected that I don't have strcasecmp. That's why it doesn't have HAVE_STRCASECMP defined in the config.h. You are right that I don't have a linker, but the compile with error-on-no-prototype is working fine - I can see the result in config.h. >> Oh, one other change I made - I normally define PREFIX in a >> common header file. However, this caused a conflict between >> prefix.c and regex.c which both try to use this keyword. It >> would be good if this define was made unique within the >> source base. I realise there are different ways around this, >> but it would still be good to be unique. For now I just updated >> prefix.c to use "" as a default prefix if none is provided. That's >> neater than any immediate alternative I can think of. > > Why would you define this by hand? The usual make process will > define PREFIX while building prefix.c, using the appropriate > value determined at configure time ... Because when my assemble and compile jobs start running on MVS, I would first of all need to put in a special define for that in the compile step for prefix - the only exception in fact. Secondly, I am running close to the 100-character limit of the PARM statement already, with the things I was forced to add: //ST2CMP PROC GCCPREF='GCC',MEMBER='', // PDPPREF='PDPCLIB', // COS1='-Os -S -ansi -pedantic-errors -remap -DHAVE_CONFIG_H', // COS2='-DIN_GCC -DPUREISO -o dd:out -' Having another define, just to define an empty string, seems very ugly indeed, even assuming it comes in under 100 characters. By the way - that previous discussion we had about the potential for the MVS version to one day be able to do a system(). Even if it works for MVS eventually, which it probably will, it won't work for MUSIC/SP in batch. It's tragic, because I wanted to use exactly that to issue a "/file" for dynamic file allocation similar to how the CMS port does. I only have one other option - maybe the DYNALLOC call will work under MUSIC/SP, which would be nicer than doing a "/file" anyway. I will be trying that in the days ahead, but regardless, I need gcc to be a single executable on that environment if I want to run in batch. And yes, I want to run my compiles in batch! :-) BFN. Paul.