From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8931 invoked by alias); 14 Nov 2009 11:28:44 -0000 Received: (qmail 8889 invoked by uid 22791); 14 Nov 2009 11:28:40 -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-pz0-f203.google.com (HELO mail-pz0-f203.google.com) (209.85.222.203) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 14 Nov 2009 11:27:46 +0000 Received: by pzk41 with SMTP id 41so2701899pzk.0 for ; Sat, 14 Nov 2009 03:27:44 -0800 (PST) Received: by 10.114.54.34 with SMTP id c34mr1157107waa.47.1258198064818; Sat, 14 Nov 2009 03:27:44 -0800 (PST) Received: from Paullaptop (203-158-49-56.dyn.iinet.net.au [203.158.49.56]) by mx.google.com with ESMTPS id 23sm337033pxi.13.2009.11.14.03.27.41 (version=SSLv3 cipher=RC4-MD5); Sat, 14 Nov 2009 03:27:44 -0800 (PST) Message-ID: <9E6ED228B5B54ABE8DDC726531C6884E@Paullaptop> From: "Paul Edwards" To: "Ralf Wildenhues" Cc: "Ulrich Weigand" , "Ian Lance Taylor" , References: <200911131257.nADCvpjn024342@d12av02.megacenter.de.ibm.com> <3FAFF5DABCFE4E2481AF2B69337626F4@Paullaptop> <20091114104817.GI27368@gmx.de> In-Reply-To: <20091114104817.GI27368@gmx.de> Subject: Re: i370 port - constructing compile script Date: Sat, 14 Nov 2009 11:28: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/msg00392.txt.bz2 >> LIBOBJS includes a strcasecmp.s$U.s >> >> That suffix is certainly strange-looking though. I checked in >> config.log and I can see that it automatically detected that >> my "object code" has a ".s" extension, which is basically >> correct given that I forced the "-S" option. > > Why do you pass -S in the compiler script? configure sort of expects > that neither -S nor -c are passed automatically. The only thing the compiler is capable of doing is generating assembler code. Just getting that to work has been a 20 year effort. So what I have done is get the compiler to fail on any missing prototype. I think perhaps we need to have a generic gcc or autoconfigure option called "config by prototype". MVS is just one instance where you might wish to do it this way. Other ports in their infancy may not have working cross-assemblers and linkers either. It worked out quite well. > that strncmp does not work. It uses the cache variable > ac_cv_func_strncmp_works, which you can set if you need to override the > decision, e.g.: > ac_cv_func_strncmp_works=yes > export ac_cv_func_strncmp_works Ok, thanks, I've added that, and can confirm that it did the trick. > A more permanent solution would be to set this correctly based upon > $host in libiberty/configure.ac and regenerate libiberty/configure with > autoconf. Ok, that's what a lot of this exercise is about - finding out what needs to be changed in the long term in GCC 4 if MVS is to be supported. >> And then I changed ac_libobjs to stop putting that $U in there as >> well, and I finally got my strcasecmp. > > Why does that $U hurt you? It should get expanded to nothing later on. > (It is a remainder from some ansi2knr scheme.) Ok, I put it back in, and indeed, it does work. I must have been confused by an unrelated failure. >> Note that I also seem to be getting strerror. It's on the list >> of "required files", even though it isn't required or wanted. >> configure correctly detected that I already had strerror. >> I manually excluded that from my list of files and now things >> are looking good again - including strcasecmp being >> automatically selected in the build process. :-) > > Again, rather than hacking the generated configure script, I think you > should start modifying the input files, configure.ac in this case, for > permanent solutions to your build issues. As above, that is certainly on the cards. However, I'm trying to flesh out the issues that exist before seeing if we can get agreement for changes in GCC 4. E.g. what do you think of the generic "configure by prototype rather than link" facility? Personally I'd like a "configure by standard" option, where autoconfigure knows what to do based on me just telling it that the compiler is C90 (or C99 as another option) compliant, so that I don't even need to provide headers. But I think the header file option is also useful, so both should be selectable. > Even if you're only changing > a few lines, doing it each time you want to build a different GCC > version is an unnecessary burden. Man, I really wish that was even 1% of the issues that needed to be sorted out going from GCC 3.4.6 to GCC 4.x. :-) I'd be happy to do it for the rest of my life. :-) While the amount of intrusive code is relatively small, it's still quite widespread. ie more than 80 files. And that's just the intrusive code. There's all the separate port files that need to be taken care of. :-) There's a good reason it took 20 years to get to this point. :-) BFN. Paul.