Hi Ulrich.

I'll try out some of those things.  I have some initial
comments.

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;

Probably too many of them.  Just like open() etc in GCC main.
I'll see what can be faked up, now that I know those object files
are basically mandatory.

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

Ok, thanks.

Your MVS version might be just a dummy that always fails.

Ok.

Even better would be a version that actually works; in this
case all the "single-exectuable" hacks would become superfluous.

Having a single executable, especially in my environment where
only assembler code is ever generated, has its own merits even if
a working system() can be done in the future.

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?

I don't have a working system that can execute another C program
yet.  Note that C90 leaves the behaviour of system() as
"implementation defined".  Well, on my system, I can do a system()
to call some simple programs that clear the screen.  In one
environment on my system, anyway.  :-)

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.

Yes, I have all 3 specified, with --build of i686-linux.  Now that I
know that the generator files are meant to be built with the i686
gcc, I'll try to find out where it's picking that up from.

BFN.  Paul.

Reply via email to