From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4150 invoked by alias); 22 Oct 2009 18:03:22 -0000 Received: (qmail 3916 invoked by uid 22791); 22 Oct 2009 18:03:21 -0000 X-SWARE-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_00,KAM_VIAGRA3,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.17.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Oct 2009 18:03:15 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n9MI3Age015364 for ; Thu, 22 Oct 2009 18:03:12 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9MI34vK3395774 for ; Thu, 22 Oct 2009 20:03:10 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n9MI34ou012487 for ; Thu, 22 Oct 2009 20:03:04 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n9MI33he012461; Thu, 22 Oct 2009 20:03:03 +0200 Message-Id: <200910221803.n9MI33he012461@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 22 Oct 2009 20:03:03 +0200 Subject: Re: i370 port - constructing compile script To: mutazilah@gmail.com (Paul Edwards) Date: Thu, 22 Oct 2009 19:26:00 -0000 From: "Ulrich Weigand" Cc: Ulrich.Weigand@de.ibm.com (Ulrich Weigand), gcc@gcc.gnu.org In-Reply-To: <97E4D5A416C642019A7BA7A7DAA48820@Paullaptop> from "Paul Edwards" at Oct 22, 2009 05:57:13 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00453.txt.bz2 Paul Edwards wrote: > Hi Ulrich. I've had considerable success in this process. I've > now reached the point where I seem to have a correctly > generated config.h in libiberty and correct auto-host.h in gcc, > which is one of the aims in order to get an eventual link on > MVS. OK, good to hear you're making progress! > Any suggestion on how to make this less intrusive? Or > perhaps is it logical to have a generic "trap at compile > time instead of link time" configure option for other > environments also? Maybe we could have two variables, > a BEFORE_AC_FUNC and AFTER_AC_FUNC which > are defined in all those tests, and can be set to open > comment and close comment + includes to achieve > the above effect. Well, this is generated from the AC_CHECK_FUNCS macro in gcc/configure.ac. This macro is implemented by the autoconf infrastructure and appears to always use link tests (most GCC-specific tests seem to be compile-only tests, fortunately). I guess it might be interesting to see whether this can be replaced by compile-time tests, either by using a different mechanism in gcc/configure.ac, or else by overriding the AC_CHECK_FUNCS implementation in GCC's aclocal.m4 macro set ... Unfortunately, I'm not really an autoconf expert either. Maybe someone else on the list is able to help with this. > I was thinking that maybe what I should do is in the fake > linker, see what the output executable is. If the output > executable is a conftest, then do a scan of the VCONs > (external references) in the assembler making sure they > are all C90. But that seems to be the wrong approach to > me. If there's going to be a list of C90 functions and > variables it should probably be in configure.ac I think. This might also be an option. I guess in principle your "fake linker" might even be able to look at the target libraries (either directly, or via a list of exported symbols that is provided by some other tool) ... > Speaking of which. When I was putting in the intrusive > code, I saw things like newlib and Vxworks which had > explicit mention and explicit settings for various things. > Perhaps I should be doing something like that too rather > than faking things to get them through? That would lower > the barrier for an arbitrary and possibly complicated target > with no extensions. I don't see this is the main gcc/configure. However, some of the target libraries, in particular libiberty, do have hard-coded results for certain platforms. This might not really be a bad idea ... > A stack of C files in libiberty failed to compile, because they > have extensions in them. E.g. make-temp-file.c calls > access(). I've never noticed them before because I've never > included them in my links, because they are not required > on MVS. Even totally unrelated things like pex-unix.c are > being compiled. So what is the best way of switching the > source code to compile? Hmmm, the access() use probably needs to be guarded by a configure check. Or else you might provide a MVS-specific implementation of "access" (if that is possible), and compile it into libiberty by providing an EXTRA_OFILES setting in a host makefile fragment; in 3.4 these are set in config.table: case "${host}" in rs6000-ibm-aix3.1 | rs6000-ibm-aix) frag=mh-aix ;; *-*-cxux7*) frag=mh-cxux7 ;; *-*-freebsd2.1.*) frag=mh-fbsd21 ;; *-*-freebsd2.2.[012]) frag=mh-fbsd21 ;; i370-*-opened*) frag=mh-openedition ;; i[34567]86-*-windows*) frag=mh-windows ;; esac As to the pex-unix.c, you certainly should provide a MVS-specific version of the PEX callbacks. They are selected in configure.ac: # Figure out which version of pexecute to use. case "${host}" in *-*-mingw* | *-*-winnt*) pexecute=pex-win32.o ;; *-*-msdosdjgpp*) pexecute=pex-djgpp.o ;; *-*-msdos*) pexecute=pex-msdos.o ;; *-*-os2-emx*) pexecute=pex-os2.o ;; *) pexecute=pex-unix.o ;; esac Your MVS version might be just a dummy that always fails. Even better would be a version that actually works; in this case all the "single-exectuable" hacks would become superfluous. Note that e.g. pex-msdos.c implements the required callbacks solely in terms of the C99 "system" routine. If you at least have this facility available on MVS, you might be able to just use the msdos version? > Finally, even with this in place, the build process stopped at > the next roadblock. The file "genmodes.c" couldn't be > compiled. I was surprised to see that it was being compiled > with i370-mvspdp-gcc. The genmodes "needs" to be run on > Unix still. It's only the source code that IT generates that > needs to be cross-compiled. If this happens, then something went very wrong during configure. Did you make sure to use the proper build / host / target flags? In particular, the --build= configure argument must be present and refer to the build architecture. This is used to determine which architecture to build the generator programs for. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com