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).
The libiberty configure process attempts to detect which functions
need to be built via link tests by default. As you don't have a
cross-linker, something may be going wrong here. As an alternative,
you can hard-code which functions to use in libiberty's configure.ac.
The thing is, I already know it has detected that I don't have
strcasecmp. That's why it doesn't have HAVE_STRCASECMP
defined in the config.h. You are right that I don't have a linker,
but the compile with error-on-no-prototype is working fine - I
can see the result in config.h.
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.
Why would you define this by hand? The usual make process will
define PREFIX while building prefix.c, using the appropriate
value determined at configure time ...
Because when my assemble and compile jobs start running on
MVS, I would first of all need to put in a special define for that
in the compile step for prefix - the only exception in fact. Secondly,
I am running close to the 100-character limit of the PARM
statement already, with the things I was forced to add:
//ST2CMP PROC GCCPREF='GCC',MEMBER='',
// PDPPREF='PDPCLIB',
// COS1='-Os -S -ansi -pedantic-errors -remap -DHAVE_CONFIG_H',
// COS2='-DIN_GCC -DPUREISO -o dd:out -'
Having another define, just to define an empty string, seems very
ugly indeed, even assuming it comes in under 100 characters.
By the way - that previous discussion we had about the potential
for the MVS version to one day be able to do a system(). Even
if it works for MVS eventually, which it probably will, it won't
work for MUSIC/SP in batch. It's tragic, because I wanted to
use exactly that to issue a "/file" for dynamic file allocation
similar to how the CMS port does. I only have one other
option - maybe the DYNALLOC call will work under MUSIC/SP,
which would be nicer than doing a "/file" anyway. I will be trying
that in the days ahead, but regardless, I need gcc to be a
single executable on that environment if I want to run in batch.
And yes, I want to run my compiles in batch! :-)
BFN. Paul.
