bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnu utilities for MVS and CMS


From: Paul Edwards
Subject: Re: gnu utilities for MVS and CMS
Date: Mon, 2 Feb 2009 01:06:26 +1100

All of the @ characters are designed to be replaced by running the
Makefile produced by the ./configure script.  Are you able to run that
script?  If not, can you at least post the resulting config.log to show
how far it got?

I can't run configure.  The target is the mainframe, not the
compiler I have on my PC.

The ./configure script works for cross-compilation cases, if you use the
right --build and --host flags.

Ok, I couldn't see any obvious list of builds, and I would have
been surprised to see MVS on the list anyway.  The INSTALL
file suggests looking at config.sub, but I don't see one of those.

I thought that maybe just specifying a guess would come
back with a list of valid options, but didn't get very far:

c:\devel\m4x>bash ./configure --build mvs
configure: error: cannot find install-sh or install.sh in build-aux "."/build-aux

I have asked before whether configure could have an option
to generate for a theoretical C89 compiler rather than
inspecting the current system, and was told no.

In a cross-compilation scenario, the configure script examines the
characteristics of the cross-compiler, not the current system, making
pessimistic guesses (which you can override if necessary via cache
variables) for the few tests that can only be resolved by running an
executable.

Ok, but it'd be a whole lot easier for someone like me if there was
C89 code sitting there after an extraction and all I had to do was
organize a C89 compiler.  For people with Unix-like systems, the
option would still exist to run configure which would delete all
the generated c89 files and replace them with whatever it is that
configure thinks is a better idea than C89.

There's a replacement for fcntl.h?

For every file named lib/*.in.h, yes, gnulib provides a replacement header
which tries to provide a more modern environment built around the limited
capabilities of the machine that it is being ported to.

Sorry, not sure how I missed that.

fnm is fpucw.h
warning - converting x'C3' to space
warning - converting x'A8' to space
fnm is gl_list.h
warning - converting x'C2' to space

Yes, some gnulib files use UTF8 characters in comments.  Since it is only
in the comments, and not in the source itself, these characters should be
ignored by the preprocessor.  The fact that your preprocessor warns about
them is annoying, but warning-free compilation for old compilers is not a
prerequisite for our development.

It's not the preprocessor - it hasn't got that far yet.  I was just
transferring them to the mainframe and the mainframe doesn't
know how to do an ASCII to EBCDIC conversion for a non-ASCII
character.

Like you said - no big deal.

BTW, this particular C89 mainframe environment is fairly new.  Technically,
this exact one with these capabilities (GCC 3.2.3 MVS 6.0) is only a few
days old.  The prior versions weren't C89-compliant.  It took me 15 years
to get a C89 library on MVS.  Another thing of interest is that GCC 4
dropped the i370 environment that this is dependent on, so while the
exercise remains to get to GCC 3.4.6 level, we can't go beyond that.
Another point of interest is that we don't have anyone available on MVS
anymore who is able and willing to fix the compiler bugs, so we have
a few compiler bugs that we have to live with.  GCC is able to recompile
itself on MVS now, so the bugs aren't so common we can't do our
work, but it is annoying having to work around the bugs when they
come up.  I'm pretty happy we got as far as we did though.  That's been
another decades-long effort by multiple people.  It's a pity those
old-timers aren't around to polish it off.  I've enquired with the GCC
people whether anyone could assist with that but didn't get any
response.  For your interest, this is the last free version of MVS that
we are working on.  While the last free version of MVS was only 24-bit
(16 MB) which isn't enough to run GCC, an interesting change was
made to allow 31-bit programs to run under the 24-bit operating system,
so GCC was fully unleashed.

BTW, I appreciate your patience in trying to see if m4 can be targetted
to this system.  Normally I'm used to people saying that MVS is an
unsupported target and of no interest.  These old (but upgraded) MVS
systems allow us to develop software targetted to the modern z/OS
system.  People are in fact able to use something like the GCCMVS
executables right out of the box on z/OS, even though I don't have direct
access to such a system to see if it works (it does - got feedback).

BFN.  Paul.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]