* Configure gcc as a cross-compiler.
So this would not be considered a Canadian Cross after all,
and with configure I only change the target, not the host?
The end result is a Canadian Cross, but the first step in a typical
build of a Canadian Cross is a cross-compiler.
Ok.
* Write a cross-assembler and cross-linker.
Sure, and that's what I'm trying to avoid. I have a perfectly working
assembler and linker on MVS already. It's been working for several
decades.
There are many advantages of a cross-assembler and cross-linker, but,
whatever.
One of them is not "you can leverage into all the existing work
of the existing-and-working-fine IFOX00 and IEWL".
* Copy header files and libraries from the host (MVS).
That's fine. And use the --with-root option of configure to get
them used?
--with-sysroot, yes.
I have been trying combinations of --prefix and --with-sysroot,
and --with-build-sysroot, but it is still insisting that I have an
fputs_unlocked etc, despite pointing all those things to a
directory that has no such thing in it, and just has my C90
headers.
(Note that you mention fork, but as you probably know the gcc code
never actually calls fork. It calls the pexecute routines in
libiberty. Those routines have been ported to several different
hosts, including MS-DOS. If you port them to MVS, then you don't have
to worry about fork.)
I spent several minutes going through the config.h looking at the
"detected" functions to find a good example. Maybe I should I
have getrlimit or getrusage or fputs_unlocked instead.
fputs_unlocked is only used for systems which provide it. On systems
which don't, gcc uses fputs.
Similarly, getrlimit and getrusage are entirely optional. They are
used if available, otherwise not.
Right. I'm having trouble getting it to ignore the ones that are installed
on the build system, and to switch to the directory given with
--with-sysroot. Also, for the long term, it would be better to
distinguish the headers that I use on the build system, to the
headers used when cross-compiling. As I mentioned, I happen
to be in a position where I can use the same ones on MVS, on
Linux (and some other platforms too), so I can get away with
forcing it to the C90 headers immediately.
I've been discussing this under the assumption that you want to
contribute your port back to gcc. If you don't, then I think I will
step out. You can pursue whatever path you like.
I do want it to be in the mainline gcc. But the requirements for
reversing the 2004 deletion of the i370 target (which can be done
with two svn commands) are too onerous to be met for likely
years. I personally think it's strange that we had an i370 target
that didn't meet those requirements from 1993 to 2004, but now
it isn't, regardless of the fact that it now works better than ever
before (not suprising after more than 5 years of effort by multiple
people). But there's not much I can do about that.
Way back In 1998 I was talking to someone from GCC (not ecgs)
about getting some mods in to support MVS (I wasn't aware of
other MVS activity on the ecgs side). The computer with the
conversation was stolen, so I don't know who that was. Whoever
it was, I think they had plans to rewrite the i370.md themselves
(but that obviously didn't happen). My changes were all outside that.
Basically I needed those small mods to create a single executable
plus some other minor mods (similar to what I posted here recently).
I don't recall if any of it was accepted or not (I just gave the patches,
and no longer have those to see if they got in). I know the
single-executable mods didn't get in, because I know what to
look for, and it isn't there.
There's not much I can do about the non-acceptance of the mods,
but the one thing I can do is keep my modification footprint low.
That's why I believe that 20 lines somewhere in the configuration
scripts are probably enough to get what I want, without upsetting
the existing structure. Maybe eventually those 20 lines will be
accepted as a non-default option, but that is beyond my control.
But regardless of whether it is accepted or not, I want to be able
to demonstrate it working first.
Where "working" doesn't mean "write my own cross-assembler
and cross-linker and change MVS to be posix instead of MVS
and get the entire test suite working", but rather "work the same
way that gccmvs 3.2.3 works (ie bootstrapping works), except
get the JCL and auto-host to be automatically generated instead
of manually constructed for each release".
It takes several days of effort to manually construct those files
and debug the problems with them, when I suspect that with the
right config command-line and a little bit of intrusive code, plus
some external support scripts (that are no skin off anyone's
nose), the whole thing can be automated.
Anyway, I'll keep plugging away. I resorted to renaming
/usr/include, but that triggered off other problems. I suspect it
will come down to one line of code or one extra configure
parameter, but it'll probably take days of experimentation
to find that.
BFN. Paul.
