Re: i370 port - constructing compile script

["Ulrich Weigand" <uweigand@de.ibm.com>]

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