This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: i370 port - constructing compile script
- From: "Paul Edwards" <mutazilah at gmail dot com>
- To: "Ralf Wildenhues" <Ralf dot Wildenhues at gmx dot de>
- Cc: "Ulrich Weigand" <uweigand at de dot ibm dot com>, "Ian Lance Taylor" <iant at google dot com>, <gcc at gcc dot gnu dot org>
- Date: Fri, 13 Nov 2009 22:43:11 +1100
- Subject: Re: i370 port - constructing compile script
- References: <200910191419.n9JEJcvD023336@d12av02.megacenter.de.ibm.com> <FDF702F29EAC4C559392D016844AFCF5@Paullaptop> <20091112200557.GB25110@gmx.de>
Ok, now I have some results from the auto-compile-script-generation.
I got it to work, but it required some manual corrections.
First of all, I got link errors, because sched-ebb etc were trying
to call various functions, but those functions were not being
compiled in because INSN_SCHEDULING was not defined
(that's my quick analysis, anyway). So I just grepped those
files out of the "source list".
Next, a stack of libiberty files were not compiled - strcasecmp,
vasprintf, asprintf, getpagesize, strdup. I don't know why this
would be the case, because e.g. HAVE_STRCASECMP is
not defined. Anyway, I added them to the source list manually,
and with a script, awk and m4, I was able to produce my
traditional compile script (which is a stepping stone for doing
the same thing on MVS).
Oh, one other change I made - I normally define PREFIX in a
common header file. However, this caused a conflict between
prefix.c and regex.c which both try to use this keyword. It
would be good if this define was made unique within the
source base. I realise there are different ways around this,
but it would still be good to be unique. For now I just updated
prefix.c to use "" as a default prefix if none is provided. That's
neater than any immediate alternative I can think of.
But anyway, the short story is that things are looking great,
and it is looking like I have managed to slot into the existing
build process with fairly minimal intrusive code, which bodes
well for a future GCC 4 port attempt. :-) The remaining work
I know of doesn't require any more intrusive code.
BFN. Paul.