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?
I tried using the MSDOS version and it had non-C90 compile
errors. But provding a dummy pex-mvs is fine.
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.
Ok, perhaps this error was because when I hit errors in intl,
which I've never used before, I just went to the gcc directory and
did a make.
Regardless, I added a stack of touch xxx.o in the intl directory
after the failure of the first make, which allowed me to do a second
make, and then it was satisfied with the intl directory and moved
on to the gcc directory, where it did in fact invoke the correct
gcc rather than the cross-compiler.
The next thing I hit was that genmodes didn't compile because
there were conflicts between the strsignal function in the
Linux include files and the system.h. Looking at the system.h,
it was including things in because it thought that the prototypes
didn't exist. Which would have been true for the cross-compiler,
but isn't true for a native gcc. How are those two different things
meant to be reconciled?
Thanks. Paul.
