gcov-iov creates a gcov-iov.h which has a version number
which changes when I change MVS versions. So I am
thinking of updating gcov-iov.c so that when the target is
MVS, it generates a more fixed format.
I don't see how the generated number depends on the MVS
version ... It is supposed to depend solely on the *GCC*
version string of the compiler currently being built.
Mostly yes. However, it still grabs the full version string,
which includes the text "MVS 0.X" (which I added, to identify
the sub-version of 3.4.6 on MVS (note that for 3.2.3 I am
up to MVS 7.6 there's been so much activity). And basically
I don't want that GCOV header file to change between
MVS releases. Anyway, in the build scripts (ie outside the
normal configure/make process, so no-one needs to see it)
I just overwrite the header, and I didn't notice any ill-effect.
gengtype-yacc.c & .h gets created with my new version of bison.
I just want to use the one that came with 3.4.6 instead of
having it regenerated. Do I need to hide my bison to stop
that from happening?
Well, it's just a make step -- the files will get rebuilt if
and only if the gengtype-yacc.y file is more recent than the
gengtype-yacc.c and .h files. In the default 3.4.6 tarball
this is not the case. Did you somehow modify file timestamps
while unpacking / copying the files?
Yes, I imported everything into CVS and that presumably changed
all the timestamps. I wasn't aware of that. Anyway, I got around
that problem by making dummy changes to the .c and .h and
then reversing them out. So that is fixed now, thanks.
gencheck.h is being generated as an empty file, which doesn't
work well on some environments. I want it to at least have a
comment saying "/* empty file */". I can put that in as part of
the build script too.
Well, adding a comment should be trivial at the place in the
Makefile.in where gencheck.h is generated (s-gencheck).
Ok, I decided it was better to keep it outside the common files.
In any case, more recent GCC versions no longer refer to this
file at all.
And I don't even need to revisit that decision for GCC 4 it seems. :-)
So I've basically finished doing what I wanted for 3.4.6 now. I'm
not going to spend time doing niceties like putting the generated
files generation onto MVS so that mainframe users can upgrade
the machine definition without needing a non-MVS machine. I
have that nicety already for 3.2.3 and I may look into it again
for 4.x.
There's still one last thing for 3.4.6, although it's not really 3.4.6,
I'm doing it for 3.2.3, but will have to incorporate that change into
3.4.6. And that thing is the MUSIC/SP port. I have managed to
get dynamic allocation to work, which changes the whole look
of the port, so I'm working through that, which I expect will take
a couple of weeks. So that will be 3 nicely-working EBCDIC
platforms. 4 if you count USS, but I don't use or test that, so
don't know whether it works there currently.
I should be starting the GCC 4 port in a matter of days, while
using my Unix machine.
Thanks everyone for helping get it to this point.
BFN. Paul.
